From: Milan Broz <gmazyland@gmail.com>
To: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Initialization Vector using plain aes-cbc
Date: Wed, 26 Sep 2012 17:59:27 +0200 [thread overview]
Message-ID: <5063265F.6000206@gmail.com> (raw)
In-Reply-To: <50631C9E.8030903@ramses-pyramidenbau.de>
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
next prev parent reply other threads:[~2012-09-26 15:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-26 13:17 [dm-crypt] Initialization Vector using plain aes-cbc Ralf Ramsauer
2012-09-26 13:56 ` Milan Broz
2012-09-26 15:17 ` Ralf Ramsauer
2012-09-26 15:59 ` Milan Broz [this message]
2012-09-26 17:02 ` Ralf Ramsauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5063265F.6000206@gmail.com \
--to=gmazyland@gmail.com \
--cc=dm-crypt@saout.de \
--cc=ralf@ramses-pyramidenbau.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.