Conversion to Key-Based Luks
 

Is there a utility anywhere that would allow me to convert an existing Luks password-based whole disk encryption system over to a key-based system? Can I
just luksAddKey, luksKillSlot 0, updateramfs to kill the passphrase? (I got lots of irreplaceable stuff in them. I'll right after next tar-czf.)

Is there advantage to trying to do this one step at a time? Do the luksAddKey then use it for a week, etc.

I'm getting tired of memorizing all these darn passwords and phrases. I have too many systems for too many flavors of work and play. I think I'll just use a couple thumbdrives and specify them in the crypttabs (if this can work).

I noticed that Macs can do something similar. They can convert on-the-fly an entire disk system over to a passworded disk.

But keyfiles are way simpler!

I'm currently experimenting with luks/cryptsetup too. Personally I wouldn't kill the password slot just yet. In case you manage to mess something up you'll no longer have access to the partition, if you wipe the pw slot.

Although I haven't managed to setup my system yet, I've read a number of docs for cryptsetup/crypttab. Accordingly you need to setup a keyscript in the crypttab to read a keyfile from a usb thumb drive. At least on debian-based systems you would modify the crypttab with proper parameters and then invoke "update-initramfs -u" as root.

The keyscripts on my system (debian wheezy) are located in /lib/cryptsetup/scripts. I think there was a script that waits for a specific device to appear, then read something from it and pass that to cryptsetup to unlock the partition.

Here's an example of a doc I found on google:
http://binblog.info/2008/12/04/using...ks-passphrase/
Although this uses a custom keyscript I'd try to reuse existing scripts.


Be careful though, if you lose your thumb drive, you lose all access (make backups). Not to mention whoever finds the device will have full access to all of your devices secured in this manner.

Thanks displace. Your webpage helped.
I've been using the following pages off Google:
http://madduck.net/docs/cryptdisk/ and
https://www.martineve.com/2012/11/02...le-passphrase/
I did a simplified step 1 and step 4 from the www.martineve site just to set up an external disk using an internal keyfile. I used /dev/random not urandom . I wonder why he suggested urandom?

I think I might try adding a keyfile right on the boot disk (test try) on an installed system that doesn't matter if I lose it (so much). I'll play in that sandbox before going to the real thing.

And I agree about the "where not to store keyfiles" problem. I really just want this for the thief with physical access when I'm gone or sleeping or whatever. I'll store a tiny MMC SSD in my wallet and/or deposit box. Then I can forget passphrases...which get forgotten with non-use anyway.

This assumes that the "slots" are each alternate ways into the machine. I had thought if you had two slots (a passphrase and a keyfile), you needed to supply BOTH to get in. If you're sure about that, then I'll go ahead.

And i don't think a backup thumbdrive would help unless you can guarantee mounting on exactly the same /dev/name or exactly the same UUID. What if your (init) ramfs space won't look at the badkup?
ttyl

If you're talking about multiple active LUKS slots then you only have to open up one slot to access the data. If there are mulitple active slots this means you can unlock the encrypted partition multiple ways. This is why I suggested you do not wipe the password slot. In case you messed up the keyfile slot you'll still be able to access the data by using the password slot.

Playing in a sandbox is a good idea, I'm doing essentially the same thing. I have a spare laptop where I'm experimenting with luks/cryptsetup and trying to setup two-factor boot authentication with limited success. With two-factor or multi-factor authentication you need *all* credentials to access the disk, unlike LUKS. The setup I'm working on is a simple keyfile + passphrase. The boot partition, the bootloader and the keyfile will be located on an external USB thumbdrive where the PC will boot from. The system data will be fully encrypted on the HDD and of course I will hold the last part (the password) in my brains.


A backup is a must. Even if your computers don't look for this backup device you'll at least still be able to manually unlock the data. But this should not happen - the initramfs should be setup to look on multiple devices for keyfiles - you don't have to set it up to search by UUID, you can use device paths (/dev/sdb1) or filesystem labels instead.

thanks again, I gonna give you a SOLVED