[dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt
Mario 'BitKoenig' Holbe
Mario.Holbe at TU-Ilmenau.DE
Tue Jul 27 17:45:02 CEST 2010
Christoph Anton Mitterer <christoph.anton.mitterer at physik.uni-muenchen.de> wrote:
> (hadn't LRW some weaknesses?)
> 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
This depends on your attack model and whether you believe in forensic
magic. If your attacker cannot snapshot your encrypted data, the size of
your encrypted disk equals the amount of encrypted data an attacker can
get. If your attacker can snapshot your encrypted data, you are right.
For example, if you like to protect against disk theft your attack model
doesn't include snapshots. If you like to protect against spying your
attack model very likely includes snapshots.
Note, that if your attack model doesnt allow your attacker to snapshot
your encrypted data, you are pretty safe with CBC-ESSIV anyways. Lots of
the attacks XTS can but CBC-ESSIV cannot withstand require on-the-fly
access to encrypted data as well (well, malleability doesn't).
Btw... Arno: w.r.t. Gutmann and off-track-forensics: I usually avoid
replying just to say "Please mind the smiley", but here is a good place
to mention it :) No, I don't believe in off-track-forensics on todays
hard disks, but cryptsetup does: luks/keymanage.c:wipe().
Btw.2... Just in case somebody gets this wrong because I'm hammering on
the difference between 1T disks and 1T encrypted data, 1T limits and
whatever: I'm personally feeling pretty well with aes-xts-plain 256
(i.e. AES-128 - there's a nice whitepaper by Seagate on AES-128 vs.
AES-256) on 1.5T disks. The reason I'm insisting on such differences is
that it is my deep belief that there are no "safe defaults" on security
(well, there is a pathologically one). You always have to understand
what's your goals and what you do.
> Is there any way to avoid this? Or only to re-encode the device
> regularly with another key
Yep that's your way to go :)
> (btw: is it with LUKS possible to do this on the fly?)?
Nope. Not yet. It's possible to code it, though :)
> But I guess that issue is not limited to XTS, is it?
> On Tue, 2010-07-27 at 10:46 +0200, Milan Broz wrote:
>> Forgot about 1TB limit, it is different XTS only problem.
I'm not intending to mention that I have any deeper understanding of the
Rogaway 2004 paper, but as far as I understand it, this limit holds at
least for all XOR-Encryption(XE)-based tweakable block ciphers.
The secret that the NSA could read the Iranian secrets was more
important than any specific Iranian secrets that the NSA could
read. -- Bruce Schneier
More information about the dm-crypt