Ik dacht dat TrueCrypt niet meer veilig was, blijkt dus niet zo, als er zo veel moeite voor gedaan moet worden.

Ja, dat heet normaal forensisch handelen. Je wilt ook na afloop van je onderzoek nog een origineel exemplaar hebben. Voor bijvoorbeeld contra-expertise.


En geen mens weet wat die USB-stick nog meer doet.

Peter

TrueCrypt IS lek. The evil maid attack kun je daarop uitvoeren. Daarom is er tegenwoordig veracrypt. De fork ervan.

Huh, doel je op dat het gebruik icm windows niet veilig is?

In principe zijn alle soorten schijversleuteling, die slechts van een wachtwoord gebruik maken, lek voor een Evil Maid attack (https://en.wikipedia.org/wiki/Evil_maid_attack) - ook Veracrypt. Een "evil maid" kan immers het toetsenbord zodanig aanpassen dat deze het wachtwoord van de gebruiker opslaat (of draadloos verzendt).

Een fysieke sleutel die ongevoelig is voor replay attacks kan dit soort aanvallen blokkeren. Blijft het probleem dat als iemand fysieke toegang tot jouw computer heeft gehad, er fysiek vanalles in veranderd kan zijn (t/m de complete vervanging van het moederbord) waardoor die aanvaller alsnog bij jouw gegevens kan zodra jij jouw computer hebt unlocked.

Daarnaast weet je, noch van TrueCrypt, noch van Veracrypt, noch van andere schijfversleutelingssoftware, of de specifiek door jou geïnstalleerde software geen achterdeurtje heeft.

Genoemde risico's zijn, voor doorsnee gebruikers, zo klein dat zij die gerust kunnen verwaarlozen - in tegenstelling tot het risico dat een niet versleutelde (of niet van een fatsoenlijk wachtwoord voorziene of in slaapstand ontvreemde) computer in verkeerde handen valt.

Een computer in hybernate met een encrypted disk die mounted is? Dat klinkt als een forse misser van de gebruiker...

Weet iemand of dit veilig is? https://www.howtoforge.com/tutorial/how-to-encrypt-a-linux-partition-with-dm-crypt-luks/

Bepaalde versies cq. configuraties van Windows 10 zet je computer in slaapstand als je hem "uitzet".
Naast dat je dus wachtwoorden in geheugen kunt hebben, worden ook updates waar een echte reboot voor nodig is, niet uitgevoerd.

Daarnaast heeft de gemiddelde gebruiker geen idee dat zijn wachtwoord in het geheugen achter kan blijven.
"Ik tik het in, de schijf wordt versleuteld. Waarom bewaart de ccomputer het wachtwoord dan nog?"

Het feit dat een wachtwoord in het geheugen blijft, is dus eerder een forse misser van de ontwikkelaar van de applicatie.

Ik kan me applicaties herinneren waar wachtwoorden na enkele seconden gewist werden uit het geheugen. Dat is de manier waarop dat aangepakt moet worden. Gebruikers hebben de technische kennis niet om dit soort keuzes te maken.

Peter

Het is opensource. Dus dat argument vervalt wat mij betreft. Zou dat wel waar zijn, was dat al lang geleden duidelijk geworden. Zou je zoiets niet vertrouwen van je repo/website, kun je dat altijd 'even' doorlezen en zelf compilen ;)

Edit: verder heb je natuurlijk gelijk als het gaat om aanpassingen aan de hardware. Maar zoals je zelf ook al zei, is die kans klein.

Bij cryptografische algoritmen ligt dit toch net wat moeilijker. Als je daar als leek naar kijkt dan weet je eigenlijk nog niks. Eigenlijk kan alleen een cryptoloog evt. cryptografische zwaktes of backdoors vaststellen. En dan nog met moeite waarschijnlijk.

Inderdaad, dan heb je geen enkele sleutel nodig om de handel te lezen, enkele open poorten zijn genoeg.

Daarom zijn er ook audits waarbij experts kijken naar zwaktes. Als er dan een audit op een open source project wordt gedaan is dat vrij goede verzekering dat er geen backdoors in zitten.

Klopt. En daarnaast zul je, na controle van de sources, zelf moeten compileren en linken (met een hopelijk betrouwbare compiler, linker en libraries; zie: reflections on trusting trust). En bij elke eventuele update dat proces herhalen.

Ik denk dat Bitwiper met 'de specifiek door jou geinstalleerde software' doelde op het probleem om zeker genoeg te zijn dat jouw specifieke installatie van de software de originele versie is , en geen custom versie met backdoor.

De technische middelen zijn daar wel voor (signed hashes van well known sites met TLS etc ) , maar vrij weinig gebruikers hebben de operationele discipline (en kennis) om dat allemaal telkens weer te checken.

En als je bedenkt dat een serieuze targeted attack zich ook via andere software zou kunnen richten op het backdooren van de encryptie software is het zeker lastig.
(denk aan trojaned update voor heel andere software, die als payload heeft het vervangen van je veracrypt door een veracrypt-met-backdoor)

Het is natuurlijk niet het wachtwoord wat in het geheugen zit, maar de van het wachtwoord (en andere zaken)
afgeleide encryptie key op low level.
Dat dit onthouden wordt is geen misser van de ontwikkelaar, maar (bij afwezigheid van een aparte module die de
encryptie doet en de sleutel veilig opslaat) een keiharde noodzaak.

Plus, het maakt niet zoveel uit wat de gebruiker wel of niet doet, op security.nl heet het toch wel dom of een fout.
Net zoals veel software "lek" heet en de volgende versie "goed". Tot je een forward van een jaar doet, dan heet
die ook weer "lek". En de gebruiker die die gebruikt "dom".

Juridische vraag: Is medeplichtig zijn aan computervredebreuk, of wetenschap hebben van een mogelijke computervredebreuk en dat niet melden, ook strafbaar? Of moet dat nog bedacht worden?

Goede software ben er erg tevreden over. Heel wat keren gebruikt!

Wat ik bedoelde is het risico dat je een backdoored binary installeert die is ondertekend met een (private key horend bij een public key in een) vervalst certificaat, of die met de hulp van één of meer van de feitelijke ontwikkelaars is ondertekend met dezelfde sleutel als gebruikelijk.

Redenen: als je weet dat er bij Yahoo! e-mail sprake was van een backdoor waar zelfs het hoofd van de beveiliging niets van wist (althans, zei er niks van te weten), en Juniper netwerkapparatuur met een backdoored en dus niet echt CSPRNG van de NSA werd uitgeleverd (die notabene door een onbekende derde partij werd gehijacked), ben je naïef als je denkt dat dit soort druk niet op ontwikkelaars van cryptosystemen wordt uitgeoefend en hun code 100% betrouwbaar is.

Voor zover ik weet is nog steeds niet bekend wie de ontwikkelaars van TrueCrypt waren. Als ik bij een inlichteningendienst zou werken, zou ik ook adviseren om zo'n product in de markt te zetten. De vraag is onder welke omstandigheden zo'n dienst gebruik maakt van zo'n backdoor, want het risico is groot dat dan uitlekt dat het product gebackdoored is. De kans op gebruik van dat soort backdoors is vermoedelijk het grootst in de spionagesfeer, en niet bij de eerstvolgende Robert M. Tenzij je shaken (not stirred) Martini's drinkt, lijkt het risico dus erg laag.

Het verleden heeft echter uitgewezen dat ook geheime diensten niet al hun geheimen geheim weten te houden. Ook is het maar de vraag of iemand, die zegt namens een geheime dienst druk uit te oefenen, daadwerkelijk in opdracht van die geheime dienst handelt. Als je geen 007 bent maar wel over bedrijfsgeheimen of andere waardevolle informatie beschikt, is het ook verstandig om wat voorzichtiger te zijn dan de familie Doorsnee (die vermoedelijk weinig tot niets te vrezen heeft op dit gebied).

https://www.startpage.com/do/dsearch?query=dm-crypt+luks+vulnerabilities&cat=web&pl=opensearch&language=nederlands

Werkelijk alles op Crypto vlak kan tegenwoordig pn*wed zijn. Lambda generator staat gewoon online.
#sockpuppet

@ Bitwiper,

In het geval dat jij gelijk hebt en ik heb geen enkele reden nog gezien bij je bijdragen
om daar maar de geringste twijfel over te hebben,
dan is verificatie van files of ze wel "the Real McCoy" zijn, toch wel buitengewoon belangrijk.

"Bij certificering, hoe check je dat dan dit meest effectief?" is mijn vraag aan jou.
"Is een VT validatie voldoende of loop je dan alleen maar achter de muziek aan?".

Juiste graad van file-hash validatie, op de juiste manier gesigneerd. OK.
Doch tegen staatsacteurs, die je zelfs "one service holed-up updates" kunnen laten installeren,
daar is natuurlijk weinig tegen uit te richten en daar scoor je ook niet mee als je het aankaart,
zoals in het geval van Kaspersky bij NSA wrought advanced malcode or of known hand in foot attempts".

Die het aankaart is verwerpelijk. Immers de (vermeende) daders moeten hun gang kunnen blijven gaan.

En wat wordt er al niet aan data gecontroleerd en doorgespeeld aan de diensten op sites
als deze hier door bijvoorbeeld https://ssl.google-analytics.com/ga.js,
dat ik als 3rd party script maar heb geblokkeerd?

Dan zie ik nog jQuery library low risk issues op de pagina,
waarin ik nu een reactie geplaatst heb:
.

Vrijwel niemand kijkt naar de eventuele consequenties van zulke kwetsbaarheden via retire.js,
dat in mijn browser draait. Ik wel, maar ondergetekende is weer die vreemde uitzondering.

En ook Erlend Oftedal doet dit. Hij heeft hiervoor een specifieke online scansite: retire.insecurity.today/#
Lees over brute-forcen https://www.owasp.org/images/0/02/Owasp-appsensor-guide-v2.pdf

Maar voor sommige op PHP gebaseerde CMS varianten is zo'n zwakheid fnuikend of kan dat zijn.

#sockpuppet