|
On 09/26/12 15:56, Milan Broz wrote:
I'm using 1.4.3 and i double checked it. You are right, the second command fails,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 addresswork fine.nope :) Which version you are using? sorry, i probably mixed something up. cryptsetup create asd ./foobar --cipher=aes-cbc-plain works fine. Ah ok, now things are getting clearer.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 I see.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 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 caseIn 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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
