Assuming there is a LUKS volume that uses a keyfile and the keyfile is autogenerated before opening the volume and deleted after use, does changing the keyfile prevent it from being stolen from the RAM in this scenario?

Creating the LUKS volume using a keyfile:

  1. Create a keyfile using an OTP algorithm, like HOTP with a secret key and counter
  2. Store the counter value
  3. Create the LUKS volume and assign the keyfile
  4. Securely delete the keyfile

Using the volume:

  1. Recreate the keyfile using the secret key + counter
  2. Open LUKS volume via: cryptsetup --key-file keyfile luksOpen /dev ..
  3. Increment the counter
  4. Create a new keyfile with the new counter value
  5. Add the new keyfile to the LUKS volume via: cryptsetup --key-file keyfile luksAddKey /dev newkeyfile
  6. Remove the old key from the container via: cryptsetup --key-file newkeyfile luksRemoveKey /dev keyfile
  7. Securely delete keyfile and newkeyfile

What I want to know is that if the system memory was probed after step 7 and while the volume is still mounted, would it be possible to recover the volume masterkey, or the key used to open the volume in step 2, or the new key assigned to the volume in step 5?

  • There is two opposed question between title and would it be possible to recover the volume masterkey... (My no answer to second question, not to title... Anyway... ;-) Dec 2, 2013 at 17:50
  • No matter what the master key can be recovered by root while the filesystem is opened. This must be the case because the key is needed to actually encrypt/decrypt the disk data. No need for a memory scan, 'dmsetup table --showkeys VOLUMENAME' will spit out the master key. There is no way to recover the password itself after it is used to open the drive however. Dec 10, 2014 at 8:17

1 Answer 1


Shortly no.

If you've strongly flushed ram and securely deleted your keyfile, there seem not exist a way for retriving previous keys **.

Even if step 6 was not done, on LUKS metadata you will only find hash of them : the key isn't store in cleartext:

cryptsetup  luksDump /dev/sde2

Will show all keys in detailed form.

** (HOTP: Hack Only Transform the Problem)

But, with this method, you are not really more protected than using unchanged password: If an used key was dicovered, (by keylogger, camere or direct vue on your keyboard), next time you hit them, this will be easy to see where are differences and how the two key differ.

h.o.t.p. but the problem stay same...

Good method

Anyway, the procedure seem correct.

I use LUKS on live-persistent partitions on my Debian live USB key.

In my mind, for having such a transportable key, using strong security. I generate a luks key with 10 strong passphrases, (to be stored in my powerfull brain) and each time I use a suspect environment, I delete the last used key, before continuing to use running session.

No matter about memory, if the key is dropped from luks header, I only have to use one of the other, next time.

With 5 different secret passphrases, I could work a lot of time

  • My prefered desktop stay my laptop.
  • Mostly when I use my key, it's on hardware I work on (openned and without keylogger)
  • There are extremely rare operation I do in really suspect environment.

(Next 6 month, I've dropped only 1 key, and I'm not sure this was really required).

But your procedure could become usefull for strong operations against the whole key list... maybe.

  • So LUKS uses the keyfile to decrypt the volume masterkey from the volume header, and a live memory scan would only reveal the masterkey then?
    – pwnd
    Dec 2, 2013 at 22:27
  • Wow, sorry not sure (now) about how the masterkey is protected. This may have to become another question! But for the use of the key, you are right. The key isn't used to decrypt datas and is securely driven to not stay in ram after use. Dec 2, 2013 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.