I was just curious if someone had a high level overview of how a system like LUKS worked for full disk encryption, aka. how it stores keys and how those keys are verified, and if data is de-crypted by a wrapper for all standard i/o. I found a brief description of how LUKS hooks into the init process here Full System encryption with LUKS on headless server - unlock with dropbear and busybox. How?

  • Are you able to give some more detail about why you need to know this, ie what are you trying to achieve? Commented Aug 1, 2016 at 5:52
  • I'm wondering for purely academic reasons. I have no plans to modify/achieve anything.
    – fritz
    Commented Aug 1, 2016 at 13:03
  • 1
    maybe asking this on security.stackexchange.com would be a good idea. -- for now this may answer your question partly: security.stackexchange.com/questions/39306/… Commented Aug 2, 2016 at 5:59
  • Welcome to Ask Ubuntu! I agree that security.SE would probably give you better answers that AU, nevertheless the question is on topic here as well and it's also an interesting one. +1 :) Commented Aug 2, 2016 at 23:25

1 Answer 1


Luks is an encryption layer on a block device, so it operates on a particular block device, and exposes a new block device which is the decrypted version. Access to this device will trigger transparent encryption/decryption while it's in use.

It's typically used on either a disk partition, or a LVM physical volume which would allow multiple partitions in the same encrypted container.

LUKs stores a bunch of metadata at the start of the device. It has slots for multiple passphrases. Each slot has a 256 bit salt that is shown in the clear along with an encrypted message. When entering a passphrase LUKS combines it with each of the salts in turn, hashing the result and tries to use the result as keys to decrypt an encrypted message in each slot. This message consists of some known text, and a copy of the master key. If it works for any one of the slots, because the known text matches, the master key is now known and you can decrypt the entire container. The master key must remain unencrypted in RAM while the container is in use.

Knowing the master key allows you access to all the data in the container, but doesn't reveal the passwords in the password slots, so one user cannot see the passwords of other users.

The system is not designed for users to need to know or interact with the master key, and this key can't be changed without re-encrypting. The use of password slots means that passwords can be independent of the encryption key: they be changed without re-encrypting the entire container, and there can be multiple password slots.

  • Awesome, accurate summary! I've been researching LUKS and it turns out there's not great technical overviews about it. Am trying to write a blog post right now..
    – joonas.fi
    Commented Jul 11, 2017 at 10:56
  • @joonas.fi have you finished your blog post? :) I'd appreciate a good overview Commented Aug 15, 2019 at 10:22
  • 2
    @CiprianTomoiagă unfortunately no, it's still a draft. I can show you the draft but bear in mind that it's unfinished. It might contain errors and not be understandable enough :) Here: gist.github.com/joonas-fi/b6bfc564a1a7f3d6b120728db5d48b61
    – joonas.fi
    Commented Aug 16, 2019 at 10:56
  • Fantastic writeup, @joonas.fi. Thank you :)
    – user1847
    Commented Sep 10, 2021 at 6:26
  • The ability to change passwords without re-encrypting is a convenience feature. It means you're not stuck with the same password forever, and that you can change it without decrypting and re-encrypting everything. If your master key was compromised at any time, you're screwed no matter what. If your old password was compromised but the attacker never gained access to the encrypted data at the time, then they won't be able to gain access after either, unless they come across an old version of the encrypted data. Commented Oct 25, 2021 at 12:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .