Initialization Vector using plain aes-cbc

[Ralf Ramsauer]

Hi!

Just a simple question:

If I do:
dd if=/dev/zero of=foobar bs=1M count=50
dd if=/dev/urandom of=keyfile bs=32 count=1

cryptsetup create asd ./foobar --cipher=aes-cbc-essiv:sha256 --key-file key
or
cryptsetup create asd ./foobar --cipher=aes-cbc
Enter Passphrase: ..........

work fine.

But if I do
cryptsetup create asd ./encrypted --cipher=aes-cbc --key-file key
I get
device-mapper: reload ioctl on failed: Invalid argument

For sure, cbc-essiv generates the initialization vector itself. But how
does the second command
get its IV?
cryptsetup create asd ./foobar --cipher=aes-cbc
Does it derive the IV from the passphrase?

And why does
cryptsetup create asd ./foobar --cipher=aes-cbc --key-file key
not work? (No IV for cbc?)

Thanks a lot!

Ralf Ramsauer

[Milan Broz]

Post by Ralf Ramsauer
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

Post by Ralf Ramsauer
work fine.

nope :)
Which version you are using?

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>

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

[Ralf Ramsauer]

Post by Milan Broz

Post by Ralf Ramsauer
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
device-mapper: reload ioctl on failed: Invalid argument
device-mapper: table ioctl on failed: No such device or address

Post by Ralf Ramsauer
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.

Post by Milan Broz
"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.

Post by Milan Broz
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

[Milan Broz]

*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....

Read how CBC mode works
http://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29

For full disk encryption, every sector (512 Bytes) is encrypted independently.

Inside that sector block cipher mode applies (size of cipher block is typically
16 bytes, so you have 512/16 chained blocks inside sector for the CBC mode.
If it helps, I tried to describe it here http://mbroz.fedorapeople.org/talks/DevConf2012/

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

plain64 == just sector number. IOW offset from the device start in sectors.

The IV has not to be kept secret and is just used for decrypting the first Block.

No. For CBC you should use ESSIV and not predictable IV.
(And you need separate IV for every sector, not one per device.)
(For other encryption modes, like XTS, predictable IV is ok.)

So why not filling up the IV with zeroes or wasting the first block by filling it with random data?

I think you missed the point. dmcrypt is transparent sector based device encryption,
size of plaintext = size of ciphertext, you have no extra space.

IV is generated, not stored anywhere.
For plain64 IV, it is just
iv = cpu_to_le64(sector_offset); (see dmcrypt code)

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

dmcrypt always uses 512 Bytes sized sectors, logical block is irrelevant here.
(block size is inherited from underlying device but encryption always run over 512 sectors.
No need to worry, dmcrypt handles this for you)

Please, if you are not sure how it works, use default mode, see cryptsetup --help.
(Which is currently aes-cbc-essiv:sha256, in next version we will switch to XTS mode though.)

Milan

[Ralf Ramsauer]

Post by Milan Broz

*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....

Read how CBC mode works
http://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-block_chaining_.28CBC.29
For full disk encryption, every sector (512 Bytes) is encrypted independently.
Inside that sector block cipher mode applies (size of cipher block is typically
16 bytes, so you have 512/16 chained blocks inside sector for the CBC mode.
If it helps, I tried to describe it here http://mbroz.fedorapeople.org/talks/DevConf2012/

Now it's clear :-)
So each sector uses it's own IV (in case of plain mode, the sector
number which padded up with zeroes).

Otherwise parts inside the block device couldn't be exchanged without
reencrypting the whole content beginning from that point.
Now it makes sense, didn't think about that.

Post by Milan Broz

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

plain64 == just sector number. IOW offset from the device start in sectors.

Ok, i got it :-)

Post by Milan Broz

The IV has not to be kept secret and is just used for decrypting the first Block.

No. For CBC you should use ESSIV and not predictable IV.
(And you need separate IV for every sector, not one per device.)
(For other encryption modes, like XTS, predictable IV is ok.)

So why not filling up the IV with zeroes or wasting the first block by filling it with random data?

I think you missed the point. dmcrypt is transparent sector based device encryption,
size of plaintext = size of ciphertext, you have no extra space.
IV is generated, not stored anywhere.
For plain64 IV, it is just
iv = cpu_to_le64(sector_offset); (see dmcrypt code)

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

dmcrypt always uses 512 Bytes sized sectors, logical block is irrelevant here.
(block size is inherited from underlying device but encryption always run over 512 sectors.
No need to worry, dmcrypt handles this for you)
Please, if you are not sure how it works, use default mode, see cryptsetup --help.
(Which is currently aes-cbc-essiv:sha256, in next version we will switch to XTS mode though.)
Milan

Milan, thanks a lot for your explanations, you really helped me!

Ralf