On 07/27/2010 05:45 PM, Mario 'BitKoenig' Holbe wrote: > 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. Well, the discussion here is about encryption modes etc - I guess probably one of the stronger part of the chain. But you mention attack models where you can do snapshots or spying... - in most situations it means that attacker have physical access to machine There are many other attacks then which are simpler (memory scan, installing hw keylogger, installing malware - in all levels from bios to kernel, various power measures, injecting intentional hw malfunctions etc) - if attacker have unprivileged account on machine with running encryption, there are cache attacks on aes implementation ... just examples, threat model depends on real usecase So, knowledge of encryption mode security and proper use limits is surely important but we must analyse the whole system and its connections outside. And usually there are weaker parts elsewhere (...which are also people obviously http://xkcd.com/538/ :) If possible encryption mode scares you, you can still use stacking of various ciphers - like Truecrypt does. If one is broken, there is still another level. It is easy to do it with cryptsetup also (IOW LUKS over LUKS). When mentioning TC - their requirements and precautions applies to cryptsetup as well http://www.truecrypt.org/docs/?s=security-requirements-and-precautions ... > 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(). (Neither me :), it doesn't work for SSD/Flash drives at all, but once it is there why remove it? It should not harm:-) >> 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 :) Maybe one day it will be there but probably as part of LVM (which will use libcryptsetup for key management for encrypted logical volumes). It is possible to encode some simple function to reencode disk in-place. But I would like to have something better, LVM already provides most of infrastructure for such block device operations. (beware: I am also lvm developer:) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
