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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
