Ist die Migration von TrueCrypt zu VeraCrypt ausreichend?

[Snoopy69]

Habe gestern mit VC herumexperimentiert und ein Laufwerk zum Test von TC zu VC migriert.

Der VC-Header hat nun die Standard-PIM von 485...
Ist das Laufwerk mit diesem Header nun sicherer? Denn an der Verschlüsselung der Daten selbst wurde ja kein Bit verändert.

Und wie wichtig ist der Verschlüsselungsalgorithmus selbst, wenn das Passwort sehr stark ist (64-stellig mit Sonderzeichen). Reicht AES oder sollte es schon Serpent-Twofish-AES sein? Die Verschlüsselung der Daten kann ich ja im Nachhinein nicht mehr ändern (nur den Header)

Im Übrigen könnte ich das Laufwerk wieder zurück zu TC migrieren und mounten, da ich den TC-Header gesichert hatte. Im Netz stand davon aber nichts.

[lumines]

Ich habe keine Ahnung von TrueCrypt oder VeraCrypt, aber das sind so meine Einschätzungen:

Hier kann man über das PIM-Feature lesen: https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20(PIM).html

Es scheint ein Parameter der KDF (Key Derivation Function) zu sein. Damit kann man sogenanntes Key Stretching durchführen. Ein Angreifer muss dann für jeden Versuch die jeweilige Funktion eine gewisse Anzahl Iterationen durchlaufen, was je nach Parameter die Versuche massiv verlangsamen kann. Scheinbar ist dieser Parameter bei VC dynamisch und abhängig von der Länge des Passworts. Für "kurze" Passwörter scheint VC mehr Iterationen zu erzwingen, was sich eigentlich ganz sinnvoll anhört.

64 Zeichen mit Sonderzeichen ist übrigens absoluter Overkill und bringt keinen nennenswerten Sicherheitsgewinn. Eher reduziert das die Sicherheit, weil du dir das sehr wahrscheinlich niemals merken können wirst, was man für manche Passwörter aber vielleicht können will.

Reicht AES oder sollte es schon Serpent-Twofish-AES sein?

"Schon" gibt es in dem Kontext eigentlich nicht. Wenn irgendein göttliches Wesen AES mit 256 Bit Schlüssellänge einfach so brechen kann, dann werden Serpent und Twofish davon wahrscheinlich auch betroffen sein.

Viel interessanter als die eigentliche Cipher ist in dem Kontext übrigens der Betriebsmodus, der bei allen Ciphers von VC XTS zu sein scheint. Hier kannst du ein bisschen über diesen Betriebsmodus lesen: https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Das TL; DR ist für dich nicht relevant, weil du keine wirkliche Wahl hast, aber XTS ist ein ziemlicher Kompromiss. Eigentlich will man die Verschlüsselung auf Dateisystemebene haben. Moderne Dateisysteme wie ZFS bieten z.B. authentifizierte Betriebsmodi wie GCM an. Wahrscheinlich wirst du von AES-GCM schon einmal gelesen haben, weil das häufig für TLS / HTTPS benutzt wird.

Das muss dich aber nicht interessieren, weil es da bei VC nicht viel Auswahl gibt. Nimm einfach eine ausreichend lange Passphrase (und keine sinnlos lange), die du entweder per Diceware oder mit dem kryptografisch sicheren Zufallsgenerator deines Betriebssystems generierst (unter Windows dürfte dich pwgen oder ein beliebiger Passwortmanager interessieren). Für Diceware gibt es da praktischerweise ziemlich klare Empfehlungen für die Anzahl der Wörter (sechs oder mehr für Vollverschlüsselung): http://world.std.com/~reinhold/dicewarefaq.html#howlong

Für Diceware mit physischen Würfeln sollte man natürlich Würfel ohne eigenen Bias haben. Einige handelsübliche Würfel begünstigen z.B. eine 1 zu werfen, weil die 6 auf der Rückseite mehr Material hat und dadurch schwerer ist. Eventuell macht es da Sinn einmal in solche Casino-Würfel zu investieren.

Als Cipher nimmst du AES. Wenn dein Rechner AES-NI kann, gibt es keinen Grund etwas anderes zu nehmen. AES-NI beschleunigt nicht nur AES, sondern schützt auch vor bestimmten Seitenkanalangriffen. Google wird dir dazu viel ausspucken. Das ist für Vollverschlüsselung vielleicht nicht so relevant, aber AES ist bei VC schon die richtige Wahl.

Nach der Doku hier sollte man beim PIM wohl nur aufpassen, dass ab einer bestimmten Länge die Werte dynamisch runtergeregelt werden. Ein langes Passwort resultiert also in einem niedrigen PIM, ergo weniger Iterationen für die KDF (PBKDF2). Grundsätzlich gibt es aber keinen Grund, warum sich das gegenseitig ausschließen sollte. Man kann auch mit einem langen Passwort den PIM-Wert höher einstellen. Das resultiert dann nur in längerer Boot- und Mount-Zeit. Hier kann man sehen, wie die Iterationen aus dem PIM generiert werden: https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20(PIM).html

Dein Desktop kann ein paar mehr Iterationen sicher ganz gut stemmen. Unter 100.000 Iterationen sollte man da wahrscheinlich nicht gehen müssen. Ein PIM von 485 resultiert aber definitiv in einer sehr viel höheren Anzahl Iterationen als wahrscheinlich nötig sind, wenn ich das richtig sehe. Im Zweifelsfall würde ich einfach die Default-Werte lassen, auch wenn die ziemlich langsam sind.

Das kann übrigens alles Quatsch sein, was ich hier erzähle. Ich habe VC oder TC nie benutzt und mein Kryptografiewissen ist (gefühlt) minimal über Laienwissen angesiedelt.

[Leonidas]

... mein Kryptografiewissen ist (gefühlt) minimal über Laienwissen angesiedelt.


Sieht für mich aber nicht so aus.
+1 für vorherigen Beitrag

[digital-chaos]

a) Nur eine Idee von mir: Wer auf Nummer sicher geht, wählt als Hashverfahren anstatt von SHA-256 ein anderes Hashverfahren aus. SHA-512, Whirlpool oder Streebog sind gute Algos.

b) AES ist bei den letzten Versionen von Truecrypt und bei Veracrypt im XTS Modus verknüpft. Man hat ein 512 Bit Schlüssel welcher auf zwei mal AES-256 gesplittet wird. Das reicht dicke aus. In der Praxis hat man mit AES Hardwarebeschleunigung einen sehr hohen Datendurchsatz.

c) Wenn man die 63 Stellen bei dem Passphrase ausnutzt ist man wirklich sicher!

[lumines]

c) Wenn man die 63 Stellen bei dem Passphrase ausnutzt ist man wirklich sicher!

Ich lese das immer wieder, aber welchen Sicherheitsgewinn habe ich z.B. von einer zufälligen, alphanumerischen 32-Zeichen-Passphrase (nur ein Beispiel; wäre mir noch immer zu lang) zu einer mit 64 Zeichen?

Die möglichen Zeichen sind nicht wirklich dazu da, dass man sie komplett ausnutzt. Kann man. Muss man aber nicht. Viele Zeichen zur Verfügung zu haben kann z.B. für Diceware oder ähnliche Schemen interessant sein, aber bei alphanumerischen Passwörtern sollte man schon eine realistische Vorstellung davon haben, was überhaupt physisch möglich ist (und was nicht).

Ich würde mir mehr Sorgen um einen Evil-Maid-Angriff machen als über irgendwelche Szenarien, in denen eine 32-Zeichen-Passphrase geknackt werden kann, eine mit 64 Zeichen aber nicht. Wahrscheinlich ist es ressourcentechnisch überhaupt erst gar nicht möglich, dass das jemals zu einem realistischen Szenario wird.

a) Nur eine Idee von mir: Wer auf Nummer sicher geht, wählt als Hashverfahren anstatt von SHA-256 ein anderes Hashverfahren aus. SHA-512, Whirlpool oder Streebog sind gute Algos.

Ehrlich gesagt finde ich es schon ein bisschen seltsam, dass sie da überhaupt eine Wahl anbieten. Es gibt keine wirklichen Gründe da etwas selbst aussuchen zu wollen. Man nimmt einfach den Default und fertig. Wirklich interessant für den Nutzer ist ja nur, mit welchen Parametern die KDF genau gefüttert wird. Den Algorithmus dahinter will ich gar nicht selbst aussuchen. Ich wüsste auch nicht, was an SHA-2 so generell falsch sein soll.

Wenn man auf Nummer sichergehen will, dann haut man einfach mehr Iterationen für die KDF rein. Das ist bedeutend wichtiger als ein anderes Hash-Verfahren zu benutzen.

Mal ganz davon abgesehen: Dir ist bewusst, dass auf moderner Hardware SHA-512 schneller als SHA-256 ist? Ich bin mir nicht so sicher, ob das so eine gute Eigenschaft für einen Passwort-Hash wie PBKDF2 ist. Aber darüber weiß ich nicht viel, ist mir nur gerade so eingefallen.

[Badesalz]

Ehrlich gesagt finde ich es schon ein bisschen seltsam, dass sie da überhaupt eine Wahl anbieten. Es gibt keine wirklichen Gründe da etwas selbst aussuchen zu wollen. Man nimmt einfach den Default und fertig."Methodenredundanz". Falls irgendwas vom Gebotenen doch platzen sollte, kann man sein Zeug umverschlüsseln, ohne auf ein Update warten zu müßen. So viel wird bei VC nicht geboten.

Mal ganz davon abgesehen: Dir ist bewusst, dass auf moderner Hardware SHA-512 schneller als SHA-256 ist? Ich bin mir nicht so sicher, ob das so eine gute Eigenschaft für einen Passwort-Hash wie PBKDF2 ist.Das ist eigentlich scharfsinnig überlegt. Hilft aber doch nicht so viel. Der Bruteforcer mit kleinerem Budget nimmt GPUs, was bis ~14 Zeichen noch einen zeitlichen Sinn ergeben könnte. Bei mehr als 20 spielt es keine Rolle mehr wie schnell der Hash performt.
Der Bruteforcer mit dem größeren Budget nimmt seine FPGAs. Auf denen läuft SHA-256 nicht langsamer als SHA-512 ;)

VeraCrypt steht hier diesjahr auf der Agenda. Da gibt es wohl noch einiges was genauer angesehen gehört. Auch, sozusagen, aus der social engineering Sicht der Dinge.

[Snoopy69]

BTW: Ist es bei VC momentan immer noch nicht möglich ein OS ohne PW, aber dafür mit einer Keydatei (zb auf einem USB-Stick) zu starten, wie bei Bitlocker?

Und weiß jmd zufällig, wie stark der Schlüssel der Keydatei bei Bitlocker ist? Kann man das in Anzahl der Stellen bzw. in Bit ausdrücken?

[Badesalz]

OS geht nicht. Ist aber auch immer einfach zu finden
https://www.veracrypt.fr/en/Keyfiles%20in%20VeraCrypt.html

[lumines]

"Methodenredundanz". Falls irgendwas vom Gebotenen doch platzen sollte, kann man sein Zeug umverschlüsseln, ohne auf ein Update warten zu müßen. So viel wird bei VC nicht geboten.

Die Idee ist besser bekannt als Crypto Agility. Bei Transportverschlüsselungen wendet man sich immer mehr davon ab. Dort geht man eher dazu über die Protokolle selbst zu versionieren und bei Bedarf eine neue Instanz aus einem formal bewiesenen Framework wie z.B. Noise zu erstellen, falls das jemals notwendig sein sollte. Hört sich vollkommen abstrakt und wie Zukunftsmusik an, aber nichts anderes wird z.B. bei TLS kommen.

Bei Vollverschlüsselungen sehe ich nicht einmal den Sinn dahinter. Du kannst doch jederzeit neu verschlüsseln, falls es notwendig sein sollte?

Das ist eigentlich scharfsinnig überlegt. Hilft aber doch nicht so viel. Der Bruteforcer mit kleinerem Budget nimmt GPUs, was bis ~14 Zeichen noch einen zeitlichen Sinn ergeben könnte. Bei mehr als 20 spielt es keine Rolle mehr wie schnell der Hash performt.
Der Bruteforcer mit dem größeren Budget nimmt seine FPGAs. Auf denen läuft SHA-256 nicht langsamer als SHA-512 ;)

Ich habe auch nie behauptet, dass die KDF von TC / VC besonders gut ist oder die Wahl zwischen SHA-256 oder SHA-512 irgendeine praktische Rolle spielt. Ich wollte eher zeigen, dass die Unterschiede zu subtil sind, als dass man als Laie dort informierte Entscheidungen treffen kann.

Davon abgesehen: Heute würde man einfach standardmäßig scrypt oder argon2 nehmen und nicht PBKDF2. Man würde auch einfach gar keine Wahl anbieten.

[Badesalz]

Die Idee ist besser bekannt als Crypto Agility.Geht so
https://www.cryptomathic.com/news-events/blog/what-is-crypto-agility

Solange ich im deutschen Forum über Methodenredundanz rede (was es eben ist) kann ich dafür locker die völlig zutreffende deutsch-lateinische Bezeichnung nutzen.

Bei Vollverschlüsselungen sehe ich nicht einmal den Sinn dahinter. Du kannst doch jederzeit neu verschlüsseln, falls es notwendig sein sollte?Kann ich. Muss aber entweder nicht sofort (Kaskade) oder ich kann es wie geschrieben aber auch umgehend tun, weil Alternativen bereits enthalten sind.
Wenn man die Kaskaden weglässt hat VeraCrypt auch keine kaum überschaubare Fülle von Methoden. Das waren 4 Stück, bis Kuznyechik aufgenommen wurde. Kleine Geste Richtung Osten. Wie Streebog. Bis dahin waren es auch nur 4 Hashalgos.

Für mich nichts weswegen man ungläubig mit dem Kopf schütteln könnte (oder sowas in der Art)

Ich habe auch nie behauptet, dass die KDF von TC / VC besonders gut ist oder die Wahl zwischen SHA-256 oder SHA-512 irgendeine praktische Rolle spielt. Ich wollte eher zeigen, dass die Unterschiede zu subtil sind, als dass man als Laie dort informierte Entscheidungen treffen kann.Deswegen ist es auch ok, daß wenn man nichts davon umstellt, man nichts falsch machen kann.
Einerseits ist einiges davon auch nur mit on board, weil es für Entschlüsseln oder Konvertierung von Altbeständen verfügbar sein sollte. Andererseits möchten die Macher, bei diesem traditionell flexiblen Projekt (mit seinen Wurzeln) vielleicht auch nicht unbedingt plötzlich als die absoluten Bestimmer auftreten. Belassen diesen Part also wie früher.

Ich sehe da nichts unsicheres. Selbst beim Ripemd-160, der beim Bootsystem schon nicht angeboten wird, sehe ich keine realen Probleme. Auch die Utah-realen nicht. Der Lack ist zwar mittlerweile leicht verblichen, Kratzer oder Beulen zeigten sich aber bis zum heutigen Tag noch nicht. Geschweige Rost. Ähnlich wie bei Cast-256 übrigens.

Davon abgesehen: Heute würde man einfach standardmäßig scrypt oder argon2 nehmen und nicht PBKDF2. Man würde auch einfach gar keine Wahl anbieten.Vielleicht
https://news.ycombinator.com/item?id=10258569

Sonst muß man immer schön aufpassen was man da für superben scrypt-code einbindet. Wenn das zu dolle läuft, ist es schlechter als PBKDF2 ;)
https://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

Argon2 wurde dagegen schon leicht abgekocht. Als Argon2i. Worauf v1.3 folgte. 2017. Was auch dem eigentlich Argon2, also Argon2id zugute kommt.
Es ist aber einfach weiterhin zu neu, um alles drauf umzustellen. Das muss erstmal weiter durch die Mühlen und das passiert hoffentlich bevor PKCS#5 v2 zum realen Problem werden kann.
"Heute" würde ich den Leuten das aber noch nicht direkt aufzwingen.

Ich stimme aber natürlich zu. "password storage" ist Welten wichtiger als das Geseier über die Stärken und Schwächen von AES, Serpent oder Camellia. Oder Ripemd-160 ;)
Diese Methodenhipsteritis der Angelesenen hat nichts mit der realen Sicherheit der Verschlüsselungslösung zu tun.

Das ist also ok, wenn dich PKCS #5 v2 nicht begeistert. Mich dagegen begeistert viel weniger XTS.
Ja wie? Das ist doch wie auch AES, NIST und so. Dann ist doch alles bestens damit. Oder?
https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/xts/collected_xts_comments.pdf