ubuntuusers.de

Hi,

bin grad am rumexperimentieren mit dm-crypt und cryptsetup. Läuft alles soweit so gut, hätte nur ein paar Fragen.
bei der Option "-c" schreiben einige "aes-xts-plain" andere hängen da noch was dran "aes-xts-plain:sha256", zumindest im Header den man sich anzeigen lassen kann ändert sich nichts außer das was bei "cypher mode" steht, allerdings kann man auch zB "aes-xts-plain:baumhaus" hinschreiben und alles bleibt beim alten.
Desweiteren ist die option "-h" anscheinend nicht funktionsfähig. Sollte eigentlich den Hash angeben, ich dachte man kann z.B. sha2 oder sha 512 angeben. jedoch ändert sich auch hier der Wert "Hash spec" im Header nicht. Der bleibt bei sha1. Ich wöllt aber gern sha2 verwenden.

mfg
mo0on

mo0on hat geschrieben:

Desweiteren ist die option "-h" anscheinend nicht funktionsfähig. Sollte eigentlich den Hash angeben, ich dachte man kann z.B. sha2 oder sha 512 angeben. jedoch ändert sich auch hier der Wert "Hash spec" im Header nicht. Der bleibt bei sha1. Ich wöllt aber gern sha2 verwenden.n

--hash, -h
specifies hash to use for password hashing. This option is only relevant for the "create" action. The hash string is passed to libgcrypt, so all hashes accepted by gcrypt are supported.

Ich habs nicht getestet, aber du könntest cryptsetup ohne Luks nutzen, virll. klappt es dann? Laut man page gibt es --hash nicht für Lu7ks:

luksFormat <device> [<key file>]
initializes a LUKS partition and set the initial key, either via prompting or via <key file>.
<options> can be [--cipher, --verify-passphrase, --key-size]

nun, aex-xts-plain:sha256 ist auch keine gültige Angabe. Die Spezifikation eines Hashes macht nur im essiv-Mode Sinn; Ansonsten wird sie ignoriert. Wenn schon dann aes-xts-essiv:sha256.
Aber überhaupt ist der xts-mode nicht dazu gedacht im essiv mode betrieben zu werden, der ist eigentlich für cbc .
Also besser aes-xts-plain (aber natürlich "funktioniert" auch aes-xts-benbi oder anubis-cbc-essiv:md5,... 😉 )
Und die -h Option funktioniert auch nicht mit der Luks-Erweiterung, sondern nur, wenn du cryptsetup ohne Luks verwendest. Das steht auch so in der manpage,...

Danke euch beiden, das kommt davon wenn man die man page nicht komplett durchließt. \^^

Mhh wie gesagt ich habs erstmal ausprobiert mit dem Hash und da ich im Internet relativ häufig die Angabe ":sha256" beim "plain" mode entdeckt habe hab ich gedacht das es funktioniert. Naja theoretisch sollte sha1 auch noch sicher sein, wenn nicht grad ein Supercomputer nichts zu tun hat. 😉

Kann man eigentlich bei cryptsetup irgendwie den Header sichern? Hab schon ein wenig gesucht aber nichts in der Richtugn gefunden. Denn Falls der Header durch, was auch immer, beschädigt/unlesbar wird. Wäre es gut wenn man ihn zurückspielen könnte.

mo0on hat geschrieben:

Naja theoretisch sollte sha1 auch noch sicher sein, wenn nicht grad ein Supercomputer nichts zu tun hat. 😉

Es wird ja nicht nur einmal "gehasht", sondern wiederholt,...
Um mal aus der Manpage zu zitieren:

LUKS uses PBKDF2 to protect against dictionary attacks ( see RFC 2898 ). LUKS will always use SHA1 in HMAC mode, and no other mode is supported at the moment. Hence, -h is ignored.

Kann man eigentlich bei cryptsetup irgendwie den Header sichern? Hab schon ein wenig gesucht aber nichts in der Richtugn gefunden. Denn Falls der Header durch, was auch immer, beschädigt/unlesbar wird. Wäre es gut wenn man ihn zurückspielen könnte.

http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1
Oder alternativ den Master-Key speichern und an sicherer Stelle aufbewahren:
dmsetup table --show XXXXXX | gpg -e -r ........ >masterkey.backup

Also ich finde es aber ziemlich ärgerlich, dass cryptsetup-LUKS nur sha-1 unterstützt, denn Wikipedia sagt über SHA-1 folgendes:

http://de.wikipedia.org/wiki/Secure_Hash_Algorithm schrieb:

Grundsätzlich sollte SHA-1 daher nicht mehr in neuen Entwicklungen als sicherer Hash-Algorithmus vorgesehen werden.

😲

Hoffentlich wird das in einer der neueren Versionen unterstützt werden! Bis dahin bleibe ich lieber noch bei TrueCrypt: http://www.truecrypt.org/

Pik-9 schrieb:

Also ich finde es aber ziemlich ärgerlich, dass cryptsetup-LUKS nur sha-1 unterstützt, denn Wikipedia sagt über SHA-1 folgendes:

http://de.wikipedia.org/wiki/Secure_Hash_Algorithm schrieb:

Grundsätzlich sollte SHA-1 daher nicht mehr in neuen Entwicklungen als sicherer Hash-Algorithmus vorgesehen werden.

in cryptsetup wird sha-1 nicht eingesetzt, um ein Dokument zu signieren, sondern um durch iterierte Anwendung aus dem Salt und Passwort einen Key zu berechnen - also als Schlüsselableitungsfunktion.

Kollisionsangriffen und Co., über die Wikipedia berichtet, sind vor allem dann eine Schwachstelle, wenn der Algorithmus eingesetzt wird, um Prüfsummen zu berechnen (und selbst dort bisher nur eher theoretisch). Wird sha-1 innerhalb Schlüsselableitungsfunktionen eingesetzt, sind solche Schwäche weitaus weniger relevant.

Hoffentlich wird das in einer der neueren Versionen unterstützt werden! Bis dahin bleibe ich lieber noch bei TrueCrypt: http://www.truecrypt.org/

Wenn du dir dadurch erhoffst sicherer zu sein, liegst du vermtulich falsch. Zum einen, weil die Schwäche von sha1 in diesem Kontext sowieso weniger relevant ist, zum anderen weil cryptsetup in der Regel einen höhere Iterationszahl als Truecrypt benutzt ( kannst du einstellen,.. ). Iterationszahl ist möglicherweise bedeutender als die Wahl eines anderen Hash-Algorithmuses,...