On Thu, Jul 19, 2012 at 11:36:53AM -0700, Two Spirit wrote: > Hello world, > > I'm a heavy believer in the backup mantra "2 is 1 and 1 is none", and start > to feel comfortable when I have 3. Luckily I had backups to handle my > recent data loss with LUKS, but I had to suffer a long restore time as the > capacities get larger. > > Are there backup headers/superblocks/metadata (whatever you call it) within > the LUKS container so that if the header > is somehow corrupt, I can utilize the backup copy from within the container > like file systems have. Not at this time. It is a wish-list item for the future, but its secuurity-implications are not quite clear at this time. For example, it compromises the easy way to wipe the header that you have at the moment. > (I understand there is still a question > of pre-decryption / post decryption. Not really. The problem is more that the header is relatively large and that the second copy decreases the anti-forensic properties. Just copying th existing header may not be the right approach. > Since these are usually long running > file servers, I've found lots of discussions about passphrase recovery > while the systems are still running and not luksClosed). I did google > around for LUKS recovery procedures, but there were lots of bad long > involved processes out there that didn't work or I couldn't get to work. > > I now see the luksHeaderBackup and luksHeaderRestore commands.(My excuse > is that I don't recall them when I first learned about cryptsetup many > years ago.) They are also explained in the FAQ, with a special warning right at the beginning. Reading documentation from time to time can decrease your risk and effort. > but it sounds like I have (or some sysadmin has) to make my own > backups of this information else if I don't, I'm screwed if I get > corruption in the LUKS header so it is almost a mandatory procedure -- > something I think lot of people would also not have done. Not quite. First you have to decide about the security trade-off. And then, if you want, you can make a header-backup. Or not. > Yes, I have seen a seasoned sysadmin run #rm -rf * from root on a > production server, so I could forsee someone doing something to > mess up the LUKS headers. It happens, as the mailing-list archives show. But the protection against that and other things is the data backup, not a header backup. The header backup is something convenient that decreases security and as such should not be there by default. "Those that sacrifice security for convenience shall neither have security nor convenience", so to say. The thing is that the header backup does not replace a normal backup you need anyways. And a header-backup to the same device does not protect you against a disk failure. There really is no good way to do this except to explain the issue to the user and have them decide what they want to do. Encryption is not something you can do without understanding what you do. And until you understand what you do, there will occasionaly be things that would have been easy with the required knowlegde but are hard without it. But you did it right, it just took a long time to restore, you did not permanently lose you data. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
