Christoph Anton Mitterer <christoph.anton.mitterer@xxxxxxxxxxxxxxxxxxxxxx> wrote: > (hadn't LRW some weaknesses?) Yes. > 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. regards Mario -- 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
