# [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:

 *Quote:*   

> Die Optionen für DM-Crypt:
> 
> Device Drivers  --->
> 
>   Multi-device support (RAID and LVM)  --->
> ...

 

Das ist bei mir auch im Kernel:

 *Quote:*   

> 
> 
>            [*] Multiple devices driver support (RAID and LVM)                                                                   │ │  
> 
>   │ │                                               <*>   RAID support                                                                                                   │ │  
> ...

 

 *Quote:*   

> Natürlich brauchen wir noch eine Crypto-API:
> 
> Cryptographic options  --->
> 
>   --- Cryptographic API
> ...

 

Bis auf LRW ist bei mir alles drin:

 *Quote:*   

>                < >   MD4 digest algorithm                                                                                           │ │  
> 
>   │ │                                               <*>   MD5 digest algorithm                                                                                           │ │  
> 
>   │ │                                               <M>   SHA1 digest algorithm                                                                                          │ │  
> ...

 

Sieht ja soweit alles gut aus.

Nun mache ich wie im Howto:

```
modprobe dm-crypt

modprobe sha256

modprobe blowfish 

modprobe aes

```

Läuft durch.

Aber dann:

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

ergibt:

```
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:

```

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......  :Wink: Last edited by buggybunny on Sun Oct 28, 2007 12:08 pm; edited 1 time in total

----------

## sirro

 *buggybunny wrote:*   

> 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 

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

liegt:

```

 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:

```

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:

 *Quote:*   

> 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....  :Wink: 

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

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

```
/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  ...

 *Quote:*   

> 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:

```
-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:

```
-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   :Very Happy: ) 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   :Very Happy: 

/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   :Very Happy: )

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   :Very Happy: . [2] fand ich von den unzähligen Mails, die ich mal schnell überflogen hatte am informativsten  :Very Happy: 

[1] http://www.mail-archive.com/cryptography@metzdowd.com/msg07139.html

[2] http://www.mail-archive.com/cryptography@metzdowd.com/msg07116.html

----------

