Eric Grejda wrote: > Using /bin/dd assumes that the systems in question is already booted up > and a root shell is available. It wouldn't be too difficult for an > attacker to run in, clock the user over the head, and hit ^C to stop the > overwrite to copy the contents of /home/* to removable media. This is always the case if the LUKS volume is decrypted, with or without the mechanism. So the mechanism is only for... what? Basically it needs a locked state and someone entering the destruct code. Bruteforce attacks will be done on copies, with a mechanism independant from your kernel's variant of LUKS, so the destruct sequence doesn't trigger. When being forced to unlock the system, such a mechanism could only remove the option to get away by unlocking it. If you have attacker that will beat you up for the contents, this leaves you with the worst case that you can also choose by refusing to unlock. If you need to wipe the LUKS header without the running system, you could also use livecd or dban for wiping. > One supposes it depends on how valuable you consider the information: > would it be better for no one to have the data at all, or for an > attacker to potentially have at least some of the data at risk? http://xkcd.com/538/ Yours, Uwe --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
