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

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

[Ralf Ramsauer]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

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

[Milan Broz]

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?

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

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

[Ralf Ramsauer]

[-- Attachment #1.1: Type: text/plain, Size: 3656 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 7224 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

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

[Milan Broz]

On 09/26/2012 05:17 PM, Ralf Ramsauer wrote:
> 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....

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)

> 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

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

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

[Ralf Ramsauer]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

On 09/26/12 17:59, Milan Broz wrote:
> On 09/26/2012 05:17 PM, Ralf Ramsauer wrote:
>> 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....
> 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.
>
>> 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 :-)
>  
>> 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)
>
>> 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
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]