Re: [cryptsetup] luksFormat - Welchen cipher?
Hallo Tobias,
On 29.07.2009, Tobias Nissen wrote:
> Ich bin tats�chlich davon ausgegangen, dass Du Blockgr��en meinst. AES
> ist ja relativ leicht auf andere Blockgr��en <256 Bit �bertragbar,
> daher dachte ich, du w�rdest das mit "AES-98 (theoretisch)" meinen.
> (Gut, 98 ist nur unter besonderen Bedingungen durch 8 teilbar
> [Voraussetzung f�r Blockgr��en], aber vielleicht schenkst Du mir die 2
> Bit noch, um auf 96 herunterzugehen.)
Die Vergleiche hinken etwas, weil es zunaechst etwas einfach und schnell
Verstaendliches sein sollte. Ich habe nicht damit gerechnet, dass die
Diskussion groesseres (und detaillierteres) Interesse hervorrufen wuerde.
Ich selber bin auch weder Kryptologe oder Mathematiker, sondern habe
irgendwann mal zum Plan gehabt, diverse Aufgaben (WPA2, WLAN) von
eigenen Programmen erledigen zu lassen, und habe mich dann notgedrungen
mit diesen Dingen beschaeftigt. Das Ergebnis waere letzendlich gewesen,
das Rad neu zu erfinden, und ich habe aufgegeben :-)
Wenn das Passwort weniger Entropie liefert als die Verschluesselung
benoetigt, dann verwenden Blockchiffren wie Blowfish oder auch AES
padding/stretching. Der Schluessel wird, je nach Implementierung,
z.B. via PBKDF2 aus dem Passwort erzeugt. Es wird also dafuer gesorgt, dass zum
einen bruteforcing erschwert wird (salting, iteration count) und auch dass der
Schluessel die erforderliche Groesse bekommt. Dabei wird es dann klar, dass
selbst ein Passwort, welches nur aus dem Buchstaben "A" besteht,
sowohl zur gewaehlten Schluessel- wie auch spaeter Blockgroesse fuehren wird.
ABER, und darauf wollte ich hinaus, wird es erheblich einfacher, die
Passphrase zu bruteforcen als den Key selber, wenn das
Passwort schwaecher ist als dieser, und deswegen sollte man beim Passwort
nicht sparen und Sorgfalt beim Erstellen walten lassen.
Beim Verschluesseln selber benutzt AES sog. "padding", da der Input (key,
Initialisierungsvektor plus zu verschl. Daten) immer ein Vielfaches
von 16 sein muss (bytes). Der Rest wird je nach Implementation
aufgefuellt mit spaces, Nullen, oder random data. Siehe dazu u.a.
die Definitionen von PKCS# und PKCS#5.
So habe ich die Dokumentation damals verstanden.
Korrigiere mich gerne, sollte ich mich irren (obwohl ich mittlerweile
mein Projekt aufgegeben habe und eigentlich am ganzen Crypto-Kram nicht
mehr besonders interessiert bin).
Gruss,
Heinz.
Reply to: