From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcMy23xwqMHV for ; Wed, 26 Sep 2012 17:59:32 +0200 (CEST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 26 Sep 2012 17:59:32 +0200 (CEST) Received: by bkwq16 with SMTP id q16so443136bkw.37 for ; Wed, 26 Sep 2012 08:59:31 -0700 (PDT) Message-ID: <5063265F.6000206@gmail.com> Date: Wed, 26 Sep 2012 17:59:27 +0200 From: Milan Broz MIME-Version: 1.0 References: <50630077.6000204@ramses-pyramidenbau.de> <50630996.1080803@gmail.com> <50631C9E.8030903@ramses-pyramidenbau.de> In-Reply-To: <50631C9E.8030903@ramses-pyramidenbau.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Initialization Vector using plain aes-cbc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ralf Ramsauer Cc: dm-crypt@saout.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