SSD verschlüsseln Software/Hardwareverschlüsselung nutzen ?

Canna

Junior Member
Hallo,

ich habe mir eine SSD zugelegt welche folgendes unterschtüzt: AES 256-Bit-Datenverschlüsselung, Hardware Encryption

Nutzt ihr persönlich bei euren Festplatten die Hardwareverschlüsselung ?( Ich möchte übrigends die gesamte Systempartition verschlüsseln)

Kann man beides kombinieren, sprich TrueCrypt + Hardwareverschlüsselung und haltet ihr es für Sinnvoll ?

Wie sieht es mit Geschwindigkeitseinbußen aus ?

Vielleicht sagt ihr auch "TrueCrypt reicht!"

Ich freue mich über euer Meinung :)


Gruß Canna
 
Es kommt immer auf deine SSD an.
Die neueren (guten wie z.B. Samsung Pro Versionen) haben keine großen Einbußen in der Geschwindigkeit. Kommt aber auch auf das Gesamtsystem an, da eine Verschlüsselung immer CPU Ressourcen in Anspruch nimmt.
Die Herstellerseitige Verschlüsselung ist meist schneller, aber für mich persönlich keine Alternative.

Ich würde dir entweder Truecrypt 7.1a empfehlen (Support eingestellt aber durch Audit verifiziert) oder den "Nachfolger" Veracrypt, der auf Truecrypt aufbaut.
Und Truecrypt/Veracrypt reicht eindeutig ;) Da beißen sich selbst FBI/CIA die Zähne aus, wenn man es richtig anstellt.
 
Die AES TCG Opal Verschlüsselung von Samsung und Co kannst du getrost in die Tonne kloppen, da ist mit Sicherheit ein "unabsichtlicher Bug" drin und auch von der Bedienung her ist das mehr als umständlich. Die einzige Gratissoftware, mit der man diesen Quatsch benutzen kann ist Bitlocker... mehr muss ich nicht sagen.

Bleibt also nur eine ordentliche Softwarelösung und hier ist Veracrypt konkurrenzlos! Veracrypt ist der beste Fork von Truecrypt und hat sehr viele kleine und große Bugs (teils sicherheitsrelevant) in Truecrypt behoben. Die Software wird aktiv weiterentwickelt und ist definitiv eine Spende an den Hauptentwickler und Gründer Mounir wert!

Sofern du lediglich deine SSD mit AES verschlüsselst und deine halbwegs potente CPU AES-Support hat, wird die Geschwindigkeit um die 30% bei den sequenziellen Transfers verlangsamt, die IOPS brechen massiv ein. Meine Samsung SSD 840 Evo ist gefühlt trotzdem noch sau schnell und die Geschwindigkeitseinbußen sind im Alltag ganz ehrlich nicht zu merken. Du kannst auch ruhig die gesamte SSD bzw Partition verschlüsseln und musst keine 10% frei lassen, wie es oft angeraten wird. Moderne SSDs haben genug Reserve an Zellen, um bei einer voll beschriebenen SSD Wear-Leveling zu nutzen.

Hier siehst du meinen Benchmark mit der Samsung Magician Software:

SSD840.jpg
 
@Canna kann dir den Beitrag von @Black empfehlen.
Unsere Beiträge sind ziemlich identisch. Wofür du dich entscheidest ist deine Sache, ich hab derzeit alles noch mit Truecrypt verschlüsselt. Irgendwann werde auch ich zu Veracrypt wechseln.

Wobei ich persönlich trotzdem immer ca 10% auf der SSD frei lasse. Müssen musst du es nicht.
 
Ich habe mich jetzt für die softwarebasierte Variante enschieden. Weiß jemand von euch wie viel Zeit man circa benötigt, um eine 500 GB SSD Systempartition zu verschlüsseln ? (AES 256 Bit)
 
Weiß jemand von euch wie viel Zeit man circa benötigt, um eine 500 GB SSD Systempartition zu verschlüsseln ? (AES 256 Bit)

Meine 480'er SSD hat neulich etwa 4 Stunden mit Veracrypt benötigt. Ist aber auch kein Problem, wenn du die Kiste zwischendurch ausschaltest oder neu startest. Das fängt dann einfach dort an wo du aufgehört hast.
 
Moin moin,

Bei meiner SSD 840 von Samsung sagt mir Veracrypt ,das meine Partition mit Guidtabelle (GPT) und nur Unterstüzung mit MBR funzt

Hat jemand eine Idee ohne das ganze Betriebsystem Win 10 neu zu machen .

Grüße
 
Ich habe vor gut 3 Jahren begonnen alle meine Festplatten inkl. Systemplatte voll zu verschlüssen. Dabei habe ich diese Erfahrungen gemacht:

1.) Bitlocker: Die Systeme laufen trotz SSD mit deutlich merkbarem Leistungsverlust. Tastatureingaben mit Zeitverzögerung. Ich hatte damals manuell auf AES 256 hochgestellt. Fazit: Nicht empfehlenswert, System wird ausgebremst und nicht vertrauenswürdig.

2.) TrueCrypt: Mit SSD kein spürbarer Leistungsverlust feststellbar. Booten verzögert sich um 8 Sekunden. Sehr zu empfehlen, wenn man nichts zu verbergen hat aber auf Datenschutz aus ist. Ist immer noch für den Normalanwender ausreichend sicher denke ich.

3.) VeraCrypt: Nachfolger von TrueCrypt, etwas sicherer weil z.B. SHA 512 auswählbar usw. Nachteil: Booten dauert ca. 70 Sekunden länger, weil dadurch Brute Force vermieden werden soll. Bei laufenden Betrieb kein Leistungsabfall spürbar.

Gesamturteil:
Verwende einfach TrueCrpyt mit mind. 20-stell. Passwort und wenn es sehr sicher sein soll (muss) VeraCrypt.

Anleitung:
(http://www.drwindows.de/windows-8-a...nvertieren-funktioniert-mbr-installieren.html )
- Mit RUFUS USB-Stick erstellen: https://rufus.akeo.ie/
- Partitionschema: MBR Partition mit BIOS ohne UEFI
- Image laden
- USB Stick erstellen
- im BIOS: alles mit SecureBoot ausschalten und zusätzlich bei der SSD schauen, dass nicht UEFI SSD ausgewählt wurde. Da gibts nen paar Optionen im Bios.
 
Last edited:
1.) Bitlocker: Die Systeme laufen trotz SSD mit deutlich merkbarem Leistungsverlust. Tastatureingaben mit Zeitverzögerung. Ich hatte damals manuell auf AES 256 hochgestellt. Fazit: Nicht empfehlenswert, System wird ausgebremst und nicht vertrauenswürdig.

Das überrascht mich etwas. Ich selber nutze FileVault auf MacOS und merke kaum Speedverlust. Ich hätte angenommen, dass dies unter Windows ähnlich wäre. Oder kann es sein, dass deine CPU keine AES unterstützt? Welche CPU hast du im Rechner? Und wann hast du das zuletzt getestet?

2.) TrueCrypt: Mit SSD kein spürbarer Leistungsverlust feststellbar. Booten verzögert sich um 8 Sekunden. Sehr zu empfehlen, wenn man nichts zu verbergen hat aber auf Datenschutz aus ist. Ist immer noch für den Normalanwender ausreichend sicher denke ich.


Da sollte man aber sagen was man nimmt, da TC ja nicht nur AES kann, sondern auch Serpent, Twofish und sogar dir Kombination. Ausserdem spielt ja auch die Bits eine gewisse Rolle. AES128 ist sicherlich um einiges schneller als AES256.
Ich persönlich würde eh bei Festplatten immer zu AES128 raten. Gerade bei SSD's ist der Speed schon entscheidend und AES128 ist ja nun auch nicht so in 5 Minuten geknackt, ganz im Gegenteil ;)
 
2.) TrueCrypt: Mit SSD kein spürbarer Leistungsverlust feststellbar. Booten verzögert sich um 8 Sekunden. Sehr zu empfehlen, wenn man nichts zu verbergen hat (Jeder hat etwas zu verbergen!!!) aber auf Datenschutz aus ist. Ist immer noch für den Normalanwender ausreichend sicher denke ich.

3.) VeraCrypt: Nachfolger von TrueCrypt, etwas sicherer weil z.B. SHA 512 auswählbar usw. Nachteil: Booten dauert ca. 70 Sekunden länger, weil dadurch Brute Force vermieden werden soll. Bei laufenden Betrieb kein Leistungsabfall spürbar.

Gesamturteil:
Verwende einfach TrueCrpyt mit mind. 20-stell. Passwort und wenn es sehr sicher sein soll (muss) VeraCrypt.

Punkt 3 ist falsch, bei Veracrypt gibt es schon seit mehreren Versionen die PIM-Funktion, mit der man die Zahl der Iterationen fast frei belegen kann, wenn das PW größer als 20 Zeichen ist, kann man sogar fast auf das unsichere Niveau von TC zurück. Heutzutage TC zu empfehlen ist fahrlässig und unsinnig, VC hat viele kritiche Bugs gefixt.

Da sollte man aber sagen was man nimmt, da TC ja nicht nur AES kann, sondern auch Serpent, Twofish und sogar dir Kombination. Ausserdem spielt ja auch die Bits eine gewisse Rolle. AES128 ist sicherlich um einiges schneller als AES256.
Ich persönlich würde eh bei Festplatten immer zu AES128 raten. Gerade bei SSD's ist der Speed schon entscheidend und AES128 ist ja nun auch nicht so in 5 Minuten geknackt, ganz im Gegenteil ;)

Falsch! Selbst bei einer 10 Jahre alten CPU ohne AES-Support reicht die Leistung für eine mit VC AES 256bit verschlüsselte SSD aus (selbst getestet)! Es gibt heutzutage keinen, aber auch gar keinen Grund, AES 128bit statt 256bit zu nutzen! Weder auf dem Smartphone noch auf dem PC. Bitte "empfehle" so etwas nie mehr, Frank.

Was bei SSDs in Bezug auf Verschlüsselung bremst ist der Overhead. Diskcryptor kann deutlich flotter mit SSDs und AES arbeiten als TC/VC. Ich habe Mounir (VC) bereits ein paar Optimierungsvorschläge für SSDs gemacht, die Umsetzung hat aber verständlicherweise keine Priorität.
 
Im Endeffekt gibts aber auch Null Grund von AES 128 bit abzuraten.
Meine Tests mit TC sind schon einige Jahre her und da war AES128 deutlich schneller ;)
 
Im Endeffekt gibts aber auch Null Grund von AES 128 bit abzuraten.
Meine Tests mit TC sind schon einige Jahre her und da war AES128 deutlich schneller ;)

Na dann sind deine Tests aber schon über 10 Jahre her, ich habe gerade eine 11 Jahre alte Mittelklasse AMD-CPU ohne AES-Support hier, die einen Durchsatz von über 220 MB/s schafft! Klar, dann ist die CPU komplett ausgelastet, aber jede halbwegs aktuelle CPU langweilt sich mit AES 256 Bit zu Tode! Mit meinem i7-5820k kann ich theoretisch 7 GB/s ver- und entschlüsseln, das bedeutet jede alte Low-End CPU schafft locker die 1-3 GB/s!

Wenn es keinen Grund gibt, das Mehr an Sicherheit nicht zu nutzen, dann gibt es einen Grund, es zu nutzen! (deep, ich weiß) Obwohl es recht unwahrscheinlich ist zeigt die Vergangenheit, dass in vermeintlich sicheren Kryptoalgorithmen bisher unbekannte Schwachstellen die Sicherheit gegen Bruteforce dramatisch reduzieren können und ein für die nächsten 40 Jahre als sicher eingestufter Algorithmus plötzlich nur noch einen Bruchteil der Bruteforcedauer bei gleichbleibender Rechenleistung benötigt.

Es gibt also sehr wohl Gründe für AES 256 Bit:

1. Ungewisse Zukunft bezüglich Bruteforce in Kombination mit dem technologischen Fortschritt
2. Bisher unbekannte Schwachstellen, die den Algorithmus leicht bis erheblich schwächen, sodass man mit 256 Bit eine Reserve gegenüber 128 Bit oder 192 Bit hat
3. Bei einer CPU mit AES-Support kein Geschwindigkeitsverlust, wieso also nicht die Reserve mitnehmen

Das alles bezieht sich primär auf kryptografisch abgesicherte Massenspeicher! Bei Servern und Traffic hingegen macht es manchmal schon Sinn, die 40% weniger Rechenleistung und bessere Latenz mitzunehmen, wenn ohnehin nur unsensible Daten gestreamt werden und PFS die nachträgliche Entschlüsselung erschwert (Google macht das so). Aber auch dieser Aspekt fällt in spätestens 5 Jahren weg, weil der Vorteil einfach zu gering sein wird.
 
Gerade beim Server nutze ich dann doch lieber Twofish oder Serpent. Ist mir irgendwie lieber, als das zu nutzen was "jeder" nutzt :p Aber das sind dann eh nur Container, wo /home drin liegt...


Im Endeffekt sollte man bei so etwas aber nicht unbedingt in die Zukunft schauen, denn die ist eben eine ungewisse. AES128 und AES256 sind derzeit nicht zu knacken und das ist entscheidend. Was morgen ist, das weiss eh keiner. Ich persönlich glaube auch nicht daran das dioe Bruteforce-Methoden ein enstcheidendes Kritierium sind. Das bassiert auf reiner Rechenkraft und die ist eben nur schwer abschätzbar vorraus zu sehen. Ich persönlich glaube das es andere Angriffsmethoden geben wird, bevor diese Bruteforce-Methoden wirklich relevant werden.
Aus dieser Sichtweise gibt es für mich eben absolut keinen Mehrwert den privaten Rechner unbedingt auf AES256 zu nutzen. Da nehme ich doch lieber das leichtere AES128, gerade auf den mobilen Endgeräten, wo es auch um den Stromverbrauch geht(Laptop), der durch die höhere nötige Leistung unnötig geschröpft wird. Mag sein, dass das bei einem billigen Laptop der eh nur ne halbe Stunde durchhält, nicht ins Gewicht fällt. Wer aber was vernünftiges hat und auch mal 7 oder 8 Stunden ohne Strom arbeiten will, der sieht zu das er spart.
AES128 ist nach derzeitigem Stand nicht zu knacken(mit ordentlichem PW). Sollte sich das morgen ändern, dann wird die Platte entschlüsselt und was anderes eingesetzt. Aber ganz ehrlich: Selbst wenn AES128 geknackt würde, dann würde ich auch bei AES256 fix wechseln.


Schade das ich mich nicht mehr erinnern kann, aber irgendwas war mal vor zwei oder drei Jahren mit neuen Angriffsmethoden die sogar AES256 unsicherer als AES128 machen. Hatte glaube ich irgendwas mit Schlüsselexpansion zu tun. Ich bin da leider auch nicht so der 100 Prozent-Experte. Aber irgendwas hab ich da ganz dunkel im Gedächtnis.....
 
Gerade beim Server nutze ich dann doch lieber Twofish oder Serpent. Ist mir irgendwie lieber, als das zu nutzen was "jeder" nutzt

Oh je... das ist genau der falsche Weg! Desto bekannter ein Kryptoalgorithmus, desto geringer ist die Wahrscheinlichkeit einer Sicherheitslücke! Das macht AES ja auch so vermeintlich sicher. Es haben schon so viele Kryptoforscher draufgeschaut, dass eine kritische Lücke sehr unwahrscheinlich ist. AES ist auf Servern mit AES-NI-Unterstützung Twofish oder Serpent Lichtjahre in Sachen Performance voraus, vorallem in Sachen Latenz und Timing!

Im Endeffekt sollte man bei so etwas aber nicht unbedingt in die Zukunft schauen, denn die ist eben eine ungewisse.

Genau deswegen muss man ja eben mögliche Szenarien in der Zukunft in Betracht ziehen! Wie ich vorher schon schrieb geht es auch darum, dass eventuell AES nicht komplett geknackt werden wird, aber man wie bei 3DES die Schlüssellänge in einem Maße verkürzen kann, dass Bruteforce in absehbarer Zeit Erfolg hat! Und hier hat man mit 256 Bit einfach mehr Reserve.

gerade auf den mobilen Endgeräten, wo es auch um den Stromverbrauch geht(Laptop), der durch die höhere nötige Leistung unnötig geschröpft wird

Da würde ich gerne Belege für sehen. Gerade bei AES-NI dürfte der Einfluss auf die Akkulaufzeit in einem vernachlässigbaren Bereich liegen!

Schade das ich mich nicht mehr erinnern kann, aber irgendwas war mal vor zwei oder drei Jahren mit neuen Angriffsmethoden die sogar AES256 unsicherer als AES128 machen. Hatte glaube ich irgendwas mit Schlüsselexpansion zu tun. Ich bin da leider auch nicht so der 100 Prozent-Experte. Aber irgendwas hab ich da ganz dunkel im Gedächtnis.....

Du meinst den related-key Angriff. Der ist aber, wie so viele Kryptoangriffe, nur in sehr speziellen Fällen anwendbar und bei korrekter Datenträgerverschlüsselung nicht von Belang. Eine sehr interessante Diskussion findet sich hier: https://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions

It turns out that the version of the key schedule for AES-128 seems quite stronger than the key schedule for AES-256 when considering resistance to related-key attacks. It is actually quite logical: to build a related-key attack, the cryptographer must have some fine control over the subkeys, preferably as independently from each other as possible. It seems natural that the longer the source master key, the more control over subkeys the cryptanalyst gets -- because the related-key attack model is a model where the attacker can somehow "choose" the keys (or at least the differences between the keys). In the extreme case of a 1408-bit master key which would simply be split into eleven 128-bit keys, the cryptanalyst would have all the independent control he could wish for. Therefore, an academic weakness relatively to related-key attacks should, generically, increase with the key size.

The apparent paradox of the decrease in academic security when the key size increases highlights the contrived nature of the related-key attack model.
AES 256 Bit ist in der Praxis also immer noch deutlich sicherer als AES 128 Bit.
 
Oh je... das ist genau der falsche Weg! Desto bekannter ein Kryptoalgorithmus, desto geringer ist die Wahrscheinlichkeit einer Sicherheitslücke! Das macht AES ja auch so vermeintlich sicher. Es haben schon so viele Kryptoforscher draufgeschaut, dass eine kritische Lücke sehr unwahrscheinlich ist. AES ist auf Servern mit AES-NI-Unterstützung Twofish oder Serpent Lichtjahre in Sachen Performance voraus, vorallem in Sachen Latenz und Timing!

Aus Wikipedia:

Serpent ist ein symmetrischer Verschlüsselungsalgorithmus, der von den Kryptographen Ross Anderson, Eli Biham und Lars Knudsen entwickelt wurde. Es ist eine Blockchiffre mit einer Blockgröße von 128 Bit und variabler Schlüsselgröße bis 256 Bit.

Serpent war ein Kandidat für den Advanced Encryption Standard (AES) und gehörte mit Twofish, Rijndael, MARS und RC6 zu den fünf Finalisten des AES-Ausscheidungsverfahrens.

Serpent scheint eine sicherere Architektur als Rijndael zu haben. MARS, Twofish und Serpent wurden als hoch-sicher eingestuft, während Rijndael und RC6 „nur“ als hinreichend-sicher eingestuft wurden. Rijndael wurde vor allem wegen seiner mathematischen Struktur, die möglicherweise zu Angriffen führen könnte, kritisiert. Im Gegensatz zu den beiden anderen als hoch-sicher eingestuften Kandidaten der letzten Runde, MARS und Twofish, wurde Serpent bezüglich seiner Sicherheit nicht kritisiert und es wurde angenommen, dass dieser der sicherste der fünf Finalisten sei.

Serpent weist außerdem bei Implementierung in Hardware, die als Pipelineerfolgen kann, die höchste Geschwindigkeit unter den Finalisten auf. Er ist jedoch bei Software-Implementierungen der Langsamste, während Rijndael sowohl in Hardware als auch in Software relativ schnell ist. Vor allem dieser Geschwindigkeitsvorteil dürfte bei der Entscheidung, Rijndael zum AES zu erklären, den Ausschlag gegeben haben.[1]

In Sachen Performance ist das mir auf dem Server noch relativ wumpe. Sind ja keine Server mit tausend Nutzern die auf /home zugreifen. ;) Bei einem anderen Verwendungszweck, wäre das sicherlich anders. Ich habe dort aber keine Messungen gemacht, da diese einfach irrelevant ist.
Im Endeffekt beisst sich deine Argumentation in Sachen Sicherheit ;)

AES 256 Bit ist in der Praxis also immer noch deutlich sicherer als AES 128 Bit.

Ich persönlich sehe das nicht so und scheine da auch nicht der Einzige zu sein:

Experten des Festplattenherstellers Seagate gehen in einem Whitepaper sogar soweit zu schreiben, dass AES-256 im Zusammenhang mit Festplattenverschlüsselung (FDE, Full Disk Encryption) nur auf dem Papier mehr Sicherheit verspricht. Die Experten führen aus, dass ein erfolgreicher Angriff den zugrunde liegenden Algorithmus angreifen müsste. In diesem Fall spielt die Schlüssellänge in der Tat keine Rolle, da solche Attacken auf die Grundlagen in immer der gleichen Zeit ans Ziel führen. Dass US-Regierungsbehörden für Material, dass als „Top Secret“ eingestuft wird, dennoch AES-256 vorschreiben, hat nach Ansicht der Whitepaper-Autoren einen einfachen Grund: Der Standard sieht 256 Bit lange Schlüssel vor, also sollten diese auch eingesetzt werden.

http://blogs.technet.com/b/germany/...aes-256-sicherer-oder-gen-252-gt-aes-128.aspx

Schade das der Whitepaper-Link nicht geht.

Im Endeffekt ist das Versteifen auf Bruteforce völlig irrelevant auf absehbare Zeit. Auch AES128 sollte in naher Zukunft eben nicht zu knacken sein und macht das damit vollkommen irrelevant. Aus meiner Sicht ist damit auch von einer "deutlich sicherer" zu sprechen schon falsch.

Was Energieverbrauch und Geschwindigkeit angeht, so habe ich leider keine Möglichkeit das wirklich effizient zu testen. Ändert aber auch nichts an der Tatsache das man AES128 uneingeschränkt empfehlen kann und AES256 derzeit maximal einen psychologischen Vorteil bietet. Wenn man in der Rechenkraft soweit ist, das AES128 mit Bruteforce in relevanter Zeit geknackt werden kann, dann kann man das anders sehen, aber davon sind wir noch sehr weit entfernt und so lange ist ein unbedingtes Nutzen von AES 256 einfach nicht gegeben.
 
Nachtrag:

Das ich auf meinem Server lieber Twofish oder Serpent einsetze, ist auch nichts negatives gegenüber von AES, sondern ist einfach weil ich darauf Bock habe und da dann einfach das Sicherste was zur Verfügung steht verwende. Einfach aus Spass an der Freud und weil mir die Nachteile dort echt Wurscht sind :D
 
Lieber etwas haben, was man nicht braucht, als etwas brauchen, was man nicht hat.

AES 256 Bit hat gegen Bruteforce und manche Schwächen im Algorithmus mehr Reserve, ist bei richtiger Implementierung nicht unsicherer als AES 128 Bit und verlangsamt bei AES-NI Support auch nicht die CPU oder nennenswert die Akkulaufzeit. Es gibt einfach keinen Grund für FDE auf die größere Schlüssellänge zu verzichten.

Wenn Performance keine Rolle spielt, sollte man ohnehin eine Kombination aus Algorithmen nutzen, ich habe meine SSD Systemplatte mit AES verschlüsselt und meine Datenplatten alle mit AES-Twofish-Serpent.

Bei Netzwerktraffic bietet sich AES 128 Bit mit PFS an und ist auch für höchst sensible Kommunikation vollkommen ausreichend.

Ich denke so kann man die gesamte Thematik gut zusammenfassen. D'accord?
 
Back
Top