Re: dm-crypt, new IV and standards

[dean gaudet]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/