![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||