Messages in this thread | | | Date | Wed, 3 Mar 2004 00:35:07 -0800 (PST) | From | dean gaudet <> | Subject | Re: dm-crypt, new IV and standards |
| |
On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:
> Well, CTR mode is not recommended for encrypted file systems because it is very > easy to corrupt single bits, bytes, blocks, etc without an integrity check. > If we add a MAC, then any mode of operation except ECB can be used for > encrypted file systems.
what does "easy to corrupt" mean? i haven't really seen disks generate bit errors ever. this MAC means you'll need to write integrity data for every real write. that really doesn't seem worth it...
it seems like a block is either right, or it isn't -- the only thing the MAC is telling you is that the block isn't right... it doesn't tell you how to fix it. that's a total waste of write bandwidth -- you might as well return the bogus decrypted block.
> [3] Why not use IV == block number or IV == firstIV + block number? > Certain modes of operation (like CTR) begin to leak information about the > plaintext if you ever use the same Key-IV pair for your data. > The IV will need to be updated every time you update the block. > The IV generation does need not be from a cryptographicly strong PRNG, > it need only be different from the previous IV. > So incrementing the IV by 1 mod 2^128 every time you write to the block will > suffice.
is CTR the only mode which is weak with simple IV / block number relationships?
if you absolutely need this IV update for every write then you should consider a disk layout which mixes IV (or IV+MAC) blocks so that they are grouped near their data blocks, to reduce seek overhead.
i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by IV+MAC, followed by 15 data...
-dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |