[dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

Christoph Anton Mitterer christoph.anton.mitterer at physik.uni-muenchen.de
Tue Jul 27 16:15:10 CEST 2010

On Tue, 2010-07-27 at 10:46 +0200, Milan Broz wrote:
> This thread is going crazy... :)
Well... what about me... my last crypto lectures are already some years
ago, and it seems I've forgotten most of it ;)

> 1) Facts about using plain IV generator:
> - "plain" IV is 32bit only, supported by all kernels
> - you should avoid using it for >2TB devices
> - it will remain this way because of backward compatibility (howgh:-)
> - "plain64" is fully 64bit, available since kernel 2.6.33
> - for device < 2TB it produces the same output as "plain"
> => use plain64 for new devices if you want to use tweakable encryption
> mode like XTS (or LRW), e.g. cryptsetup -c aes-xts-plain64
Clear so far... (hadn't LRW some weaknesses?)
So with plain64 we're always safe (at least until I invent my ZB-devices
and get rich ^^)

We're also safe with that limit on the block size, as our blocks are
much smaller than that 2^20 mentioned by Arno, right?

Last but not least the issue mentioned by Mario... the overall amount of
written data, when someone is able to take snapshots in between.
As far as I understand this may become a problem after several hundreds
of TBs written,... right? Guess it allows some probability attacks or
Is there any way to avoid this? Or only to re-encode the device
regularly with another key (btw: is it with LUKS possible to do this on
the fly?)?
But I guess that issue is not limited to XTS, is it?

> 2) crypsetup should have always safe defaults.
> It is aes-cbc-essiv:sha256 with 256bit key currently.
*Still suggesting to replace this some day with xts, at least if it
mitigates some attacks, as mentioned before here*

> 3) For the resize - we cannot catch all situations, someone can
> dd LUKS disk to another bigger volume without "resize" command.
> Tools will suggest using plain64 but it cannot force it.

> > So you guess the the 1TB limit could be actually ...
> Forgot about 1TB limit, it is different XTS only problem.
> We mixed up two unrelated problems here.
Uhm,.... and which one is it then?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3387 bytes
Desc: not available
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20100727/df9bdb90/attachment.bin>

More information about the dm-crypt mailing list