Ik gebruik hiervoor Truecrypt (op Windows 8) omdat Veracrypt bij mij problemen gaf met decrypten. Het scherm bij het opstarten bleef telkens hangen, wat bij Truecrypt nooit gebeurde.

Met Truecrypt kun je gewoon instellen dat de tweede schijf gedecrypt word als je de eerste schijf decrypt. In principe is encryptie op een SSD geen probleem. Met full disk encryption is je schijf altijd vol dus de SSD is wat trager, maar voor de rest is t geen probleem. Bij containers moet je er rekening mee houden dat alles wat op je schijf stond voordat je het in een encrypted container stopte mogelijk nog ergens op de schijf staat.

Ik gebruik al een tijd DiskCryptor (https://diskcryptor.net/wiki/Main_Page). Zeer flexibele bootloader en andere voordelen tov True/VeraCrypt.

5,5TB encrypted en nooit problemen.

Dat is een niet altijd nodige (1), ongewenste (2) en waarschijnlijk tijdelijke (3) bijwerking.

(1) De meeste FDE (full disk encryption) software versleutelt ook "ongebruikte" sectoren (meestal blokken van 512 bytes) van een schijf, omdat daar vertrouwelijke informatie uit gewiste (tijdelijke) bestanden in kan staan. Met "ongebruikte" bedoel ik sectoren die geen onderdeel uitmaken van bestanden of metadata in een filesystem (partitie). Een gloednieuwe schijf bevat natuurlijk nog geen vertrouwelijke informatie.

Een probleem kan zijn dat niet alle fysieke sectoren van een SSD worden versleuteld tijdens initialisatie; een SSD heeft namelijk aanzienlijk meer fysieke dan "zichtbare" (van buitenaf bereikbare, bijv. met een diskeditor maar ook de FDE software) sectoren - om de levensduur te vergroten. Ik weet niet of er FDE software bestaat die meteen na het versleutelen van ongebruikte sectoren, middels het TRIM commando, aan de schijf meedeelt dat die sectoren opnieuw ongebruikt zijn. Het zo laag mogelijk houden van het aantal daadwerkelijk in gebruik zijnde sectoren van een SSD draagt bij aan een zo lang mogelijke levensduur.

(2) Elke keer dat je bij een SSD een sector overschrijft, neemt de levensduur van die sector, en daarmee uiteindelijk de hele SSD, iets af.

(3) Zodra bestanden naar de schijf geschreven en vervolgens weer gewist zijn, zal het besturingssysteen middels het TRIM commando de bijbehorende sectoren vrijgeven, dus ongeacht of de FDE software het TRIM commando kent.

Klopt, denk daarbij ook aan (al dan niet gewiste, dus voormalige) bestanden in temp mappen, maar ook hibernate en swap files. Als je op een laptop met vertrouwelijke bestanden werkt en er een aannemelijke kans is dat die laptop gestolen wordt door iemand die geïnteresseerd is in die informatie, zou ik voor FDE kiezen.

Zie voor SSD's en FDE: http://beaukey.blogspot.nl/2013/10/performance-loss-with-fde-on-ssds.html. Hierin wordt beschreven hoe de entropie van de FDE (symmetrische encryptie) algoritmes de levensduur van de SSD extra bekort.

Opmerkingen:
- SSD Self Encrypting Drives (SED) zijn al versleuteld (bijv. Samsung EVO). Je hebt alleen aparte software nodig (bijv. Wave) om de 'unlock' van het volume met een password (vingerafdruk of Smartcard) te activeren. SSD SEDs hebben bovendien minder last van Wear & Tear
- Bij gebruik van TrueCrypt of VeraCrypt is het prestatieverlies op PCs met CPU die AES-NI ondersteunen verwaarloosbaar.
- Er zijn diverse methodes om een tweede partitie al dan niet met SSO te mounten.

Kun je mij uitleggen waarom de entropie van FDE-data een groter probleem zou zijn dan entropie als gevolg van compressie van niet versleutelde bestanden (mp3, films, docx, installers, "gewone" zip files etc)?

SWFDE frustreert de interne SED SED opslag en encryptie optimalisatie processen (bijv. data compressie *voor* encryptie, per block versleuteling en garbage collection).

Volgens mij staat dit niet standaard aan toch op de Samsung EVO drives?

Bij Hardware Based Full Disk Encryption staat encryptie *altijd* aan. Hierdoor is alle data (op de magnetische schijven of in de flash chips) altijd versleuteld. De encryptie (meestal AES-128 of AES-256) gebeurd in hardware en is in real-time.

Het enige wat je "aan" zet (en waarvoor je dus SED management software nodig hebt) is of de gebruiker zich moet authenticeren tijdens het opstarten van de PC met een SED.

Merk op dat het "aan" zetten van SED authenticatie in een minuutje geconfigureerd is. Vergelijk dat met de duur van de initiele encryptie van SWFDE (1-n uur). Ander voordeel van HWFDE is dat de C: schijf niet eens "zichtbaar" is als drive opstart. De drive er dus even uithalen, image maken en terugzetten (Evil Maid attack) heeft dus geen zin bij SEDs.

Waar je met Hardware Based FDE van de harddrive wel aan moet denken is dat je BIOS HDD-password ondersteund. Deze moet namelijk het wachtwoord doorgeven aan de disk waarnaar het gedecrypt wordt. Niet elke BIOS heeft dit en als je het niet hebt, dan is hardware based FDE niet mogelijk.

Dit is weer niet nodig bij BitLocker en inderdaad mogelijk meer slijtage. Ik heb dat naast mij neergelegd en voor BitLocker gegaan.

Meer info kan hier gevonden worden: http://superuser.com/questions/847350/impact-on-ssd-when-encrypted-with-bitlocker

Dit is niet waar. Alle SEDs die voldoen aan de Trusted Computing Group's OPAL standaard (dat is 99% van alle SEDs vandaag de dag) werken correct zonder enige BIOS ondersteuning. Reden is dat de SED zelf een Pre Boot Area (PBA) heeft waarvan de computer boot om de SED authenticatie mogelijk te maken (bijv. toetsenbord, beeldscherm en eventueel smartcard ondersteuning).

Uhm, ik kan daar niks over entropie, levensduur e.d. Alleen een niet gedocumenteerde test waarin je een forse performance loss claimt voor de een of andere software gebaseerde full disk encryptie, en veel promotie van self encrypting drives .

Ik kan me eigenlijk alleen performance loss voorstellen bij een model wat een filesystem binnen een (aantal ?) containerfiles op een ander FS doet - nog onafhankelijk van de vraag of je daartussen dan nog encryptie doet.

Als je dat vergelijkt met iets wat rechtstreeks benaderbare blocks heeft kan ik me wel wat performance issues voorstellen ja, juist bij random access.

Ik betwijfel of een FS binnen containerfiles het enige / of noodzakelijke model is voor software full disk encryption , en ik verwacht een block gebaseerde SW FDE erg vergelijkbare snelheden moet halen als SED drives.
(omdat de encryptie snelheid van een CPU met AES extensies ruim boven de snelheid van een SSD drive ligt).

SWFDE is block-based encryptie en (in principe) OS/FS onafhankelijk. Encrypted containers (TrueCrypt, VeraCrypt, BitLocker to Go etc.) zijn File System based. Merk op dat AES-NI zowel block-based als container based encryptie kan werken.


Misschien heb je deze opmerkingen hierboven over het hoofd gezien:

Typo, of terminologie ? Ik reserveer de term filesystem based wanneer de files op/door het FS gecrypt worden.
Ik beschouw een implementatie waarbij een FS binnen containerfiles gebruikt wordt (met onderweg encryptie) nog steeds als een vorm van FDE (full volume encryptie , feitelijk).
container files zijn wat dat betreft alleen yet another layer, net zoals je een vmware disk device in een guest (kunt) baseren op een set van files op het filesystem van de host.

Ik schreef de door jou gequote regel omdat ik speculeer dat het grote prestatie verlies wat je claimt op je blog primair is omdat je een container gebaseerde SWFDE testte.


Tsja, maar wat moeten we dan met de URLs die je gaf naar je blog ?
Je verwees ernaar in relatie met afnemende levensduur van SSDs bij gebruik van SWFDE . Daarover kon ik niks vinden in de links, en wat er wel staat over veel slechtere prestatie bevat weinig details - en , zoals ik schreef en jij ook, is het niet te verwachten dat een CPU met AES extensies leidt tot prestatie verlies.

De vraagsteller wil geen geld uitgeven dus dit is vast geen oplossing!