# [solved] LRW now in 2.6.20, supported by cryptsetup-luks?

## schwarzygesetzlos

It seems the 2.6.20 kernel finally gets the LRW block cipher encryption mode in addition to classic CBC.

Are there plans that cryptsetup or preferably cryptsetup-luks support this mode of operation for hard disk encryption?Last edited by schwarzygesetzlos on Sat Jul 07, 2007 5:02 pm; edited 1 time in total

----------

## rukka

I think it is already working.

Create a test container:

```

# dd if=/dev/zero of=luks.raw count=25 bs=1M

25+0 records in

25+0 records out

26214400 bytes (26 MB) copied, 0.262411 s, 99.9 MB/s

# losetup -v /dev/loop0 luks.raw

# losetup -a

/dev/loop/0: [0306]:912464 (luks.raw)
```

Test the new Liskov Rivest Wagner block cipher mode:

```

# cryptsetup --cipher twofish-lrw-benbi --key-size 256 luksFormat /dev/loop/0

WARNING!

========

This will overwrite data on /dev/loop/0 irrevocably.

Are you sure? (Type uppercase yes): YES

Enter LUKS passphrase: 

Verify passphrase: 

Command successful.

# cryptsetup luksDump /dev/loop/0

LUKS header information for /dev/loop/0

Version:        1

Cipher name:    twofish

Cipher mode:    lrw-benbi

Hash spec:      sha1

Payload offset: 2056

MK bits:        256

MK digest:      ed 38 a3 2b bd 21 01 e8 0f c9 8d 4f 30 a4 d4 a7 3a ef e6 9a 

MK salt:        94 ff 66 c0 3e 69 12 1c 68 d9 e4 e4 86 79 60 0c 

                85 64 a2 af 98 27 5e 4e 77 e0 38 a0 72 92 bb 87 

MK iterations:  10

UUID:           9c8980c7-bf8d-4540-928b-80cece14a3b6

Key Slot 0: ENABLED

        Iterations:             81709

        Salt:                   b3 cd 9a 15 d6 37 bb b1 aa 39 90 a6 39 2d f6 4b 

                                e6 e3 92 65 16 39 12 f5 70 fd d3 4d ae f4 0d 2e 

        Key material offset:    8

        AF stripes:             4000

Key Slot 1: DISABLED

Key Slot 2: DISABLED

Key Slot 3: DISABLED

Key Slot 4: DISABLED

Key Slot 5: DISABLED

Key Slot 6: DISABLED

Key Slot 7: DISABLED
```

The --key-size must be a value described in /usr/src/linux/crypto/Kconfig:

```

LRW: Liskov Rivest Wagner, a tweakable, non malleable, non movable

narrow block cipher mode for dm-crypt.  Use it with cipher

specification string aes-lrw-benbi, the key must be 256, 320 or 384.

The first 128, 192 or 256 bits in the key are used for AES and the

rest is used to tie each cipher block to its logical position.
```

-rukka!

----------

## schwarzygesetzlos

Thanks for the info! I think you are right - it is already working.

I just formatted a 20gig partition for test purposes:

```
cryptsetup -c aes-lrw-benbi -y -s 320 luksFormat /dev/sda2
```

It seems however, there is a problem regarding the size parameter. Size 256 and 320 work, but 384 does not.  Strangely formatting the partition with -s 384 actually works, but mounting it fails:

```
cryptsetup luksOpen /dev/sda2 sda2
```

gives me the following dmesg-output:

 *Quote:*   

> device-mapper: table: device /dev/sda2 too small for target
> 
> device-mapper: table: 254:1: crypt: Device lookup failed
> 
> device-mapper: ioctl: error adding target to table
> ...

 

Using a size of 256, or 320 works fine.

----------

## kernelOfTruth

it seems to work fine with 2.6.21-based kernel & system-state from today on ~x86 branch

----------

## lagalopex

I had the same problem and fixed it by using luks 1.0.5, which is not yet in portage... ebuild

I dont know, how its handled, when you use a shorter key... and if its compatible with upstream...

----------

## kernelOfTruth

 *lagalopex wrote:*   

> I had the same problem and fixed it by using luks 1.0.5, which is not yet in portage... ebuild
> 
> I dont know, how its handled, when you use a shorter key... and if its compatible with upstream...

 

this fixed it for me, too, otherwise I would have got "segmentation fault"

----------

## schwarzygesetzlos

 *kernelOfTruth wrote:*   

>  *lagalopex wrote:*   I had the same problem and fixed it by using luks 1.0.5, which is not yet in portage... ebuild
> 
> I dont know, how its handled, when you use a shorter key... and if its compatible with upstream... 
> 
> this fixed it for me, too, otherwise I would have got "segmentation fault"

 

I tried your ebuild, but unfortunately it didn't work.

```
Traceback (most recent call last):

  File "/usr/bin/ebuild", line 68, in ?

    if not portage.catpkgsplit(cpv):

  File "/usr/lib/portage/pym/portage_versions.py", line 290, in catpkgsplit

    raise InvalidData("Invalid category in %s" %mydata )

portage_exception.InvalidData: Invalid category in /cryptsetup-luks-1.0.5
```

But anyway, glad to hear that this issue is gone with v 1.05! At least if I am able to install it  :Smile: 

Compiling cryptsetup-luks diretcly from source didn't create the 'cryptsetup' binary, but only a few libs. Is this ok?

----------

## lagalopex

There must be a cryptsetup executable!

Doing "./configure --enable-static && make" will produce a cryptsetup in the src/ directory...

Where have you copied the ebuild? As it uses the "old" config file and start/stop scripts...

Put it in /usr/portage/sys-fs/cryptsetup-luks/ and run a "ebuild cryptsetup-luks-1.0.5.ebuild manifest".

Alternativly copy it to your local overlay in sys-fs/cryptsetup-luks, but you will have to copy the "old" files over...

----------

## schwarzygesetzlos

 *lagalopex wrote:*   

> There must be a cryptsetup executable!
> 
> Doing "./configure --enable-static && make" will produce a cryptsetup in the src/ directory...
> 
> 

 

Ok thanks! Now I can confirm it works - after manually copying the executable to /sbin/.

Seems a 

```
make install
```

 doesn't copy the cryptsetup executable to /sbin/ by itself.

Using the 1.05 from source compiled version cures the problem with key-sizes bigger than. 256

----------

## obrut<-

according to the aforementioned bug report version 1.0.5 is now in portage. it's named simply "cryptsetup" without the trailing "-luks"!

----------

## kernelOfTruth

 *obrut<- wrote:*   

> according to the aforementioned bug report version 1.0.5 is now in portage. it's named simply "cryptsetup" without the trailing "-luks"!

 

confirmed! and it works nice with baselayout-2   :Smile: 

----------

