[SOLVED]cryptsetup: Check kernel for support for the aes-cbc

[buggybunny]

Hey ho,

ich versuche gerade eine Partition mit Cryptsetup / LUKS zu verschlüsseln.

Dabei halte ich mich strikt an dieses Howto aus dem gentoo-wiki: http://de.gentoo-wiki.com/DM-Crypt#Cryptsetup

"Eigentlich" sieht das ja recht einfach aus:

Die Optionen für DM-Crypt:

Device Drivers --->
Multi-device support (RAID and LVM) --->
[*] Multiple devices driver support (RAID and LVM)
< > RAID support
<M> Device mapper support
<M> Crypt target support

Das ist bei mir auch im Kernel:

[*] Multiple devices driver support (RAID and LVM) │ │
│ │ <*> RAID support │ │
│ │ <M> Linear (append) mode │ │
│ │ <M> RAID-0 (striping) mode │ │
│ │ <M> RAID-1 (mirroring) mode │ │
│ │ <M> RAID-10 (mirrored striping) mode (EXPERIMENTAL) │ │
│ │ <M> RAID-4/RAID-5/RAID-6 mode │ │
│ │ [*] Support adding drives to a raid-5 array │ │
│ │ <M> Multipath I/O support │ │
│ │ <M> Faulty test module for MD │ │
│ │ <M> Device mapper support │ │
│ │ [ ] Device mapper debugging support │ │
│ │ <M> Crypt target support

Natürlich brauchen wir noch eine Crypto-API:

Cryptographic options --->
--- Cryptographic API
<M> SHA256 digest algorithm
<M> LRW support
<M> Blowfish cipher algorithm
<M> Twofish cipher algorithm
<M> Serpent cipher algorithm
<M> AES cipher algorithms

Bis auf LRW ist bei mir alles drin:

< > MD4 digest algorithm │ │
│ │ <*> MD5 digest algorithm │ │
│ │ <M> SHA1 digest algorithm │ │
│ │ <M> SHA256 digest algorithm │ │
│ │ <M> SHA384 and SHA512 digest algorithms │ │
│ │ < > Whirlpool digest algorithms │ │
│ │ < > Tiger digest algorithms │ │
│ │ < > GF(2^128) multiplication functions (EXPERIMENTAL) │ │
│ │ <M> ECB support │ │
│ │ <M> CBC support │ │
│ │ <M> PCBC support │ │
│ │ < > LRW support (EXPERIMENTAL) │ │
│ │ < > Software async crypto daemon │ │
│ │ <*> DES and Triple DES EDE cipher algorithms │ │
│ │ < > FCrypt cipher algorithm │ │
│ │ <M> Blowfish cipher algorithm │ │
│ │ <M> Twofish cipher algorithm │ │
│ │ <M> Twofish cipher algorithms (i586) │ │
│ │ <M> Serpent cipher algorithm │ │
│ │ <M> AES cipher algorithms │ │
│ │ <M> AES cipher algorithms (i586)

Sieht ja soweit alles gut aus.

Nun mache ich wie im Howto:

Code: Select all

modprobe dm-crypt
modprobe sha256
modprobe blowfish 
modprobe aes

Läuft durch.

Aber dann:

Code: Select all

cryptsetup -c aes-cbc-essiv:sha256 -y -s 384 luksFormat /dev/sda7

ergibt:

Code: Select all

WARNING!
========
This will overwrite data on /dev/sda7 irrevocably.

Are you sure? (Type uppercase yes): YES 
Enter LUKS passphrase: 
Verify passphrase: 
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda7 contains at least 383 sectors.
Failed to write to key storage.
Command failed.

Aber sha256 ist geladen:

Code: Select all

lsmod | grep sha
sha256                 11008  0

Daran, das ich LRW nicht im Kernel habe, dürfte es ja nicht liegen, oder?

Danke für jeden Tip......

[sirro]

Daran, das ich LRW nicht im Kernel habe, dürfte es ja nicht liegen, oder?

LRW braucht man nur für aes-lrw-*

Hast auch das cbc-modul geladen?

[buggybunny]

Hi,

ich hab jetzt einfach um diese Fehlerquelle auszuschließen __alles__ geladen was unter

Code: Select all

/lib/modules/2.6.22-gentoo-r2/kernel/crypto/

liegt:

Code: Select all

 ls -al /lib/modules/2.6.22-gentoo-r2/kernel/crypto/
total 284
drwxr-xr-x 2 root root  4096 Sep 30 14:29 .
drwxr-xr-x 9 root root  4096 Sep 30 14:29 ..
-rw-r--r-- 1 root root 19637 Sep 30 14:29 aes.ko
-rw-r--r-- 1 root root  4082 Sep 30 14:29 arc4.ko
-rw-r--r-- 1 root root  7514 Sep 30 14:29 blkcipher.ko
-rw-r--r-- 1 root root 11461 Sep 30 14:29 blowfish.ko
-rw-r--r-- 1 root root 22360 Sep 30 14:29 cast5.ko
-rw-r--r-- 1 root root 23516 Sep 30 14:29 cast6.ko
-rw-r--r-- 1 root root  5987 Sep 30 14:29 cbc.ko
-rw-r--r-- 1 root root  4282 Sep 30 14:29 crc32c.ko
-rw-r--r-- 1 root root  5219 Sep 30 14:29 deflate.ko
-rw-r--r-- 1 root root  5064 Sep 30 14:29 ecb.ko
-rw-r--r-- 1 root root  4574 Sep 30 14:29 michael_mic.ko
-rw-r--r-- 1 root root  6300 Sep 30 14:29 pcbc.ko
-rw-r--r-- 1 root root 21138 Sep 30 14:29 serpent.ko
-rw-r--r-- 1 root root  4626 Sep 30 14:29 sha1.ko
-rw-r--r-- 1 root root 13136 Sep 30 14:29 sha256.ko
-rw-r--r-- 1 root root 11804 Sep 30 14:29 sha512.ko
-rw-r--r-- 1 root root  5544 Sep 30 14:29 tea.ko
-rw-r--r-- 1 root root 10480 Sep 30 14:29 twofish.ko
-rw-r--r-- 1 root root 50907 Sep 30 14:29 twofish_common.ko

Geladen durch:

Code: Select all

modprobe aes arc4 blkcipher blowfish cast5 cast6 cbc crc32c deflate ecb michael_mic pcbc serpent sha1 sha256 tea twofish twofish_common

Leider immer noch der gleiche Fehler.........

[buggybunny]

So,

Problem ist gelöst.

Leider war das Ganze ein Fehler im wiki der mir jetzt gerade erst aufgefallen ist:

Diese Partition wird nun initialisiert, in diesem Fall habe beträgt Verschlüsselungstiefe 256bit, also -s 256 und den Chiffriermodus AES und LRW-BENBI gewählt. Dabei muss man ein Passwort angeben, mit dem man später die Partition öffnen kann. Natürlich ist eine Verschlüsselung unnütz, wenn man Standardpasswörter aus anderen Bereichen verwendet. Mehr zu Thema sichere Passwörter lesen sie hier

/bin/cryptsetup -c aes-lrw-benbi:sha256 -y -s 384 luksFormat /dev/sda1

Es wird von -s 256 gesprochen, im code-Schnippsel steht aber -s 384.

"Eigentlich" einfach zu erkennen, allerdings nicht wenn man die ganze Zeit davon ausgeht, das es an einem fehlendem Modul liegt....

Hab's mal entsprechend korrigiert im wiki, sprich statt:

Code: Select all

/bin/cryptsetup -c aes-lrw-benbi:sha256 -y -s 384 luksFormat /dev/sda1

Code: Select all

/bin/cryptsetup -c aes-lrw-benbi:sha256 -y -s 256 luksFormat /dev/sda1

[BlueSkyDriver]

Du bist Dir sicher das es so korrekt ist?

In dem Wiki steht nämlich auch ...

Für die Verwaltung von LRW werden 128 bit benötigt, das heißt dass zur Schlüssellänge vom gewählten Algorithmus 128 bit dazu addiert werden. Im Falle von AES wären 256, 320 und 384 bit möglich.

[misterjack]

Ich habe die Änderung rückgängig gemacht, da die Schlüsselgröße im Beispiel sich auf das sichere LRW bezieht und nicht auf CBC.

[tamiko]

Korrekt.

Die maximale Schlüssellänge bei *-cbc-* beträgt (je nach Algorithmus) insbesondere bei aes-cbc-* und serpent-cbc-* 256 bit.

Beim Blockmodus lrw kommen nocheinmal 128bit hinzu. Damit wird für jeden Block der verschlüsselt wird ein zufälliger neuer Schlüssel für die symmetrische Verschlüsselung simuliert.

D.h:

Code: Select all

-c aes-lrw-benbi -s 384
-c aes-cbc-essiv:sha256 -s 256

Wobei ich mich gerade ernsthaft Frage, warum im Wiki so ein Quark an:

Code: Select all

-c aes-lrw-benbi:sha256

steht?

Das :sha256 ist (wenn mich jetzt nicht alles täuscht) doch nur bei -cbc-essiv ein Parameter der ausgewertet wird, da die -essiv-Option den initialization vector bei cbc aus dem Hash (mit sha256, bzw. dem angegebenen Hash-verfahren ) der Blockpostition berechnet.

Der Wiki-Eintrag kommt mir ansonsten generell schon ein bisschen überarbeitungsbedürftig vor.
Mal sehen, ob ich das nächste Wochenende mal Zeit habe, mich daran etwas zu vergreifen

/edit:
Und welcher Troll hat sich denn da mit dem XTS-Eintrag verewigt? (siehe dazu [1])
Und überhaupt: Diese ganze "Mit Abstand der sicherste Verschlüsselungsalgorithmus"

Vergleichen lassen sich Verschlüsselungsalgorithmus in meinen Augen eh nur bedingt. (Gut nach Leistung schon eher )
Entweder man hat bis jetzt noch keine Schwachstelle gefunden, oder man hat eine Schwachstelle gefunden - und dann sind Verschlüsselungsalgorithmen in meinen Augen (und vieler Leute, die darin forschen) gebrochen.
So ist von ECB, und CBC abzuraten (auch wenn -essiv bei CBC die größten Probleme behebt.)

/edit2:
Ich habe mich mal kurz nach der Schwäche in LRW (betreffend den XTS-Troll) umgeschaut:
Es geht tatsächlich darum, dass wenn der 128bit-Schlüssel für den LRW-Modus selbst abgespeichert und mit dem selben Schlüssel verschlüsselt wird, es möglich ist diesen zu extrahieren.
Da man auch diesen Angriffsvektor in Zukunft gerne ausschließen will, hat man die aktuelle Version von LRW durch eine ersetzt bei der der 2. Schlüssel für den LRW-Modus nicht mehr in dieser Hinsicht gefährdet ist. Dieser Modus ist im Grunde auch wieder ein LRW-Modus - das Kind wurde allerdings XTS getauft . [2] fand ich von den unzähligen Mails, die ich mal schnell überflogen hatte am informativsten


[1] http://www.mail-archive.com/cryptograph ... 07139.html
[2] http://www.mail-archive.com/cryptograph ... 07116.html