[dm-crypt] Initialization Vector using plain aes-cbc

Ralf Ramsauer ralf at ramses-pyramidenbau.de
Wed Sep 26 17:17:50 CEST 2012


On 09/26/12 15:56, Milan Broz wrote:
> On 09/26/2012 03:17 PM, Ralf Ramsauer wrote:
>> cryptsetup create asd ./foobar --cipher=aes-cbc-essiv:sha256 --key-file key
>> or
>> cryptsetup create asd ./foobar --cipher=aes-cbc
>> Enter Passphrase: ..........
> # cryptsetup create asd ./foobar --cipher=aes-cbc
> Enter passphrase: 
> device-mapper: reload ioctl on  failed: Invalid argument
> device-mapper: table ioctl on  failed: No such device or address
>
>> work fine.
> nope :)
> Which version you are using?
I'm using 1.4.3 and i double checked it. You are right, the second
command fails,
sorry, i probably mixed something up.

cryptsetup create asd ./foobar --cipher=aes-cbc-plain
works fine.
> First, for historic reasons, there are some shortcuts:
> "aes" and "aes-plain"  will translate to "aes-cbc-plain"
>
> but "aes-cbc" is not valid shortcut
> (and cbc mode require IV specification )
>
> If you are not sure, just run
> cryptsetup status <active device>
> and it will print full mode spec. of active device.
>
> FO scripts, please always use full specification, the above is just
> to provide compatibility with old cryptsetup.
>
> Format is
> <cipher>-<mode>-<IV/params>
Ah ok, now things are getting clearer.
> plain/plain64 IV is just sector number, so no dependence
> on passphrase/key. (If used with CBC mode, it is not secure.)
>
> For more info about available IV modes see
> http://code.google.com/p/cryptsetup/wiki/DMCrypt#IV_generators
>
> Milan
Ah I see.

Let's have a closer look at the mapping table example on that page:

0 417792 crypt aes-xts-plain64 e8cfa3dbfe373b536be43c5637387786c01be00ba5f730aacb039e86f3eb72f3 0 8:16 0
|    |     |    |   |     |                                 |                                   |  |   | 
start|     |    |  mode   IV                                |                                   |  |   offset
     size  |  cipher                                        |                                   |  device
         target                                        256bit-key                          IV offset

In this case 

In this case, the start sector is 0 and the IV offset is 0 as well.

Let's assume our IV generator is plain64 and we use a 256bit Key, AES
blocksize is 128Bit, so our IV has to be 16Bytes.

IV offset is defined as:
*iv_offset*: The IV offset is a sector count that is added to the sector
number before creating the IV.
It can be used to create a map that starts after the first encrypted sector.
Usually you'll set it to zero except your device is only partially
available or you need to configure some mode compatible with other
encryption system.

Plain64 is defined as:
*plain64*: the initial vector is the 64-bit little-endian version of the
sector number, padded with zeros if necessary.

As I understand it, the first encrypted block and the IV would overlap?
I'm sure that is a misunderstanding, but I don't get it....

The IV is just needed for decrypting the first Block. How is it exactly
generated?

The IV has not to be kept secret and is just used for decrypting the
first Block.
So why not filling up the IV with zeroes or wasting the first block by
filling it with random data?

Example:
if i generate a crypt-loopback device of 1MiB using aes-cbc-plain and a
32Byte Keyfile
then blockdev returns
#cryptsetup -d ./key -s 128 -c aes-cbc-plain create asd ./foo
#blockdev --getsz /dev/mapper/asd
    2048

2048 Blocks are exactly 1MiB. Ok, that's fine, no space is wastes, but
how did we generate the IV?
Sorry, i'm stucking a bit ;-)

Thanks a lot!

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20120926/5e0d7b6d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20120926/5e0d7b6d/attachment-0001.asc>


More information about the dm-crypt mailing list