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 so? 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. Nice. > > 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? Thanks, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
