By googling I found a lot of mention of backing up a LUKS header with a simple dd command (ie dd if=/dev/hda2 of=luksheader count=1032), as well as discussions on plausible deniability issues because of the existence of the header. This presented me with two questions: 1. According to http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq it seems like it should be easy for a user who has legitimate access (ie his own password) to the LUKS device to backup the header, that way, when his key is revoked he can simply put the old header back to regain access. Wouldn't that defeat the whole purpose of key management / password revocation? How do you avoid this? 2. I know that that same LUKS FAQ page warns severely against managing your own header file, as it is very hard to keep it off of managed magnetic medium and maintain control of the physical token, but given proper care it seems like this could effectively solve the plausible deniability problem as well as, potentially, header backups. I, however, don't see any easy way to create this system right now. Is there a way to use the luksFormat to output the header to a file or something? (Is this what the --key-file is for? It kind of seems like this uses a pre-existing key, and does not create a new header...) In other words I would like to call luksFormat, but rather than prepend the header to the beginnning of the device it puts it somewhere user specified (preferably piped through gpg). Then I can reopen the device via something like "gpg --decrypt ./root-key.gpg 2>/dev/null | cryptsetup luksOpen /dev/sdx7 root" (as mentioned on the FAQ) and entering a password (while still up to 8 passwords work). Should I just create a LUKS device like I normally would then manually wipe the header (before backing it up)? That seems tedious, insecure, and unnecessary, especially if piping a luksHeader to cryptsetup will already allow it to open a device. I apologize if this is a newbish question, I just didn't find any tutorials on how to do it right off... Thanks, -Clay http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2005-12/msg00042.html http://clemens.endorphin.org/weblog/archives/2006-03.shtml#e2006-03-30T19_26_01.txt http://osdir.com/ml/kernel.device-mapper.dm-crypt/2006-05/msg00033.html
