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? – thomasrutter Aug 1 '16 at 5:52
  • I'm wondering for purely academic reasons. I have no plans to modify/achieve anything. – fritz Aug 1 '16 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/… – DJCrashdummy Aug 2 '16 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 :) – Andrea Lazzarotto Aug 2 '16 at 23:25

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 be able to see the master key while in operation, and this key can't be changed without re-encrypting. The use of password slots, however, means that passwords can be changed without re-encrypting the entire container, and allows for use of multiple passwords.

  • 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 Jul 11 '17 at 10:56
  • @joonas.fi have you finished your blog post? :) I'd appreciate a good overview – Ciprian Tomoiagă Aug 15 '19 at 10:22
  • 1
    @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 Aug 16 '19 at 10:56

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.