ubuntuusers.de

Weil dort wegen der Härte die Hashes länger brauchen und man daher weniger braucht. Entweder mehr Zeit pro Hash oder man braucht mehr Hashes pro Zeiteinheit. 😉 Am Ende kommt in beiden Fällen 1s raus.

Verstehe ich das dann richtig, dass man keinen exorbitanten Sicherheitsgewinn hat, wenn es sowieso auf 1s gehashed wird? Wozu dann sowas wie SHA512, Whirpool und SHA256 in LUKS?

NeuerNutzer schrieb:

Verstehe ich das dann richtig, dass man keinen exorbitanten Sicherheitsgewinn hat, wenn es sowieso auf 1s gehashed wird?

Ja, keinen exorbitanten... es geht darum Bruteforce teurer zu machen und das machen alle, mehr oder weniger.

Wozu dann sowas wie SHA512, Whirpool und SHA256 in LUKS?

Damit man ein paar Wahlmöglichkeiten hat. Du könntest genausogut fragen, wozu es drölfzig Dateisysteme gibt wenn doch eines genausogut reicht.

Und wer weiß, vielleicht findet morgen ja doch noch jemand eine schwerwiegende Schwachstelle in einem Cipher. Dann kannst du direkt auf einen anderen umsteigen ohne erst 3 Jahre warten zu müssen bis jemand eine Alternative implementiert.

PS: Ansonsten, weil cryptsetup hier eine Library verwendet (libgcrypt) und diese Library eben alle möglichen Hashes unterstützt. https://www.gnupg.org/documentation/manuals/gcrypt/Available-hash-algorithms.html#Available-hash-algorithms

Auch solche die man normalerweise nicht in Verbindung mit LUKS sieht.

# cryptsetup benchmark -h ...
# Tests are approximate using memory only (no storage IO).
PBKDF2-tiger      830884 iterations per second
PBKDF2-stribog512  171112 iterations per second
PBKDF2-gostr3411_94  143561 iterations per second

Haha, stimmt 😉

Ist halt alles immer sehr verwirrend, weil viele Tools und teilweise auch Firmen sowas wie SHA2+ oder eben Whirpool empfehlen und eher von SHA1 in diesem Kontext abraten.

Das hier habe ich noch gefunden:

http://hideandhack.blogspot.de/2013/05/do-not-use-sha-1-luks-disk-encryption.html

Ja, der hat halt Ahnung oder ihm gehts ums Prinzip. ☺

Er schreibt auch daß man den Hash nicht nachträglich ändern kann und dafür alles neu verschlüsseln muss - was auch nicht stimmt.

Gut, danke. Kann von mir aus geschlossen werden.

Sorry, wenn ich das Thema noch mal hochleben lasse, aber der VeraCrypt Entwickler hat was interessantes dazu gesagt:

Also, the statement that the underlaying hash function doesn't matter is completely false because there are security requirements that must be fulfilled by the hash function in order to the key derivation to be secure. Otherwise, there will be no need for cryptography and we can stick with 30 years old hash functions like MD4!! Anyway, in such security topics, one must carefully check any statement or information before endorsing it or using it. There are many out there who mislead people either on purpose or because they are ignorants of cryptography basics.

Absolut argumentenlose allgemeine Übervorsicht bis Panikmache ohne Berücksichtigung der dir gegebenen Erläuterungen. Falscher Kontext, wie gesagt. Manchmal auch nur Produktwerbung wie Ghz-Protzerei ohne Nutzen für die briefeschreibende Oma.

Das kann sehr gut sein. Wie gesagt: Ich bin weder Mathematiker, noch ein Experte auf diesem Gebiet. Es interessiert mich nur sehr.

Hier der Link aus dem dazugehörigen Thread. Sind Argumente drin enthalten.

http://sourceforge.net/p/veracrypt/discussion/general/thread/82add23d/?limit=25#dd8d/c382

Grüße

Vorsicht. Daß der Hashalgorithmus keine Rolle spielt, hat niemand behauptet. Hier gings um SHA-1 und weiter oben schreibt er ja auch: " I can't say that SHA-1 use is insecure. "

Das ist das gleiche was ich auch gesagt habe... natürlich kannst du trotzdem SHA-512 nehmen wenn du willst, aber einen konkreten Grund das Standardsetting zu ändern gibts derzeit halt nicht. Das kann man (aus Prinzip) machen, aber man muss es (noch?) nicht.

Wenn man es von der anderen Seite sieht, also man immer den neuesten/besten Hash nehmen sollte, dann müsste man vielleicht eher auf SHA-3/Keccak umsteigen. Nur ist das noch nicht implementiert (in cryptsetup / libgcrypt / ...). Und das neuste ist am Ende auch nicht immer das sicherste.

Und was die Iterationszeit angeht, irgendwo muss man eben die Grenze setzen. Natürlich kann man auf schnelleren Maschinen auch das Passwort schneller knacken. Das war und ist schon immer so. Aber die 1 Sekunde Einstellung hat dazu geführt daß mit jeder neuen Computergeneration auch LUKS ohne zutun höhere Iterationszahlen verwendet hat. Andere Lösungen haben das nicht gemacht und sind daher auf den 1000-2000 Iterationen sitzen geblieben. Von daher nicht die schlechteste Entscheidung.

Man kann die Iterationszeit auch beliebig hochsetzen, nur muss es ja auch praktikabel bleiben. Es dauert eine Sekunde bis der LUKS-Container offen ist, und das auch nur wenn das Passwort auch das erste ist; man kann bei LUKS ja bis zu 8 Passwörter vergeben, sind die alle belegt und nimmt man das 8. Passwort wartet man dann schon 8 Sekunden, da ja eins nach dem anderen durchprobiert wird obs passt. Und eine halbe Stunde warten bis der Rechner bootet will auch niemand.

Hinzu kommt daß in den allermeisten Setups die Schwachstellen sowieso ganz woanders liegen. Kein Mensch knackt verschlüsselte Platten per Bruteforce. Das macht man mit Keyloggern, Malware oder mit dem guten alten Schraubenschlüssel http://xkcd.com/538/

Danke.

Beeinflussen die Hashes die Geschwindigkeit des Systemes oder ist es nur der Cipher?

An der Verschlüsselung der Daten an sich ist nur der Cipher beteiligt. Wenn du den Master Key kennst, kannst du mit dmsetup das Ding unter Umgehung von LUKS aufmachen. Siehe 'dmsetup table' bzw. 'dmsetup table --showkeys', die crypt-Einträge sind alles was du brauchst.

Was mir gerade auffällt. Eigentlich müsste man sich, was Bedenken angeht, viel mehr Sorgen um Truecrypt machen, weil bei der FDE auch nur mit Ripemd-160 gehashed wird und das mit viel, viel weniger Iterations.

o_o

Da muss das Brute Forcen ja deutlich schneller gehen. Dami swollte man doch viel schneller an die Daten kommen.