It seems that one of the weak points in LUKs encryption is that the LUKs header can be a single point of failure if you do not create a backup header for it.

My question is: What methods of securing your backup LUKs header do you take to ensure it is not recovered by someone else?

Possible options that come to mind for me:

  1. Hiding them in a safe location or leaving it with a trusted third party

  2. Encrypting them

  3. Using stenography to hide them

A combination of all three?

2 Answers 2


The threat from a backup LUKS header is that an attacker who obtains a copy of it and the password for one of the key slots can access the volume's data even if you subsequently change that password. However, they can also do this if they gain access to the encrypted volume itself.

Basically, protect the backup header in the same way you would protect the encrypted volume, and don't worry too much. This isn't a major attack vector.

  • How would they be able to do this with the encrypted volume itself?
    – P0LYmath
    Nov 5, 2014 at 7:15
  • The LUKS header backup is just a copy of the header area of the encrypted volume. If the attacker gets access to the volume, they can perform a backup of the header without needing to know any of the passwords, or they can just work with the volume's header area directly.
    – Mark
    Nov 5, 2014 at 9:27
  • When you say gains access to the encrypted volume, you mean after it's been unencrypted and opened right? Or do you mean that the header can be recovered from a currently encrypted volume?
    – P0LYmath
    Nov 5, 2014 at 16:47
  • 1
    The header can be recovered from a currently encrypted volume. Note that most of the header (key slots, master key, etc.) is itself encrypted, so there's no security risk from this.
    – Mark
    Nov 5, 2014 at 20:52

Although @Mark has answered this to the extent I'd consider acceptable, it remains unmarked so I would just add as an alternative explanation to the same point being conveyed:

Point of "Failure"

It seems that one of the weak points in LUKs encryption is that the LUKs header can be a single point of failure if you do not create a backup header for it.

First and foremost, to clarify the LUKS header being "a single point of failure" specifically refers to being able to access your data by way of entering a correct password and having the data decrypted. It is not necessarily a single point of failure in terms of security in and of itself.

Therefore preventing this point of failure in the sense that there's a fair chance the header could be corrupted either by way of accidentally writing data to the beginning of a block on a particular drive as part of a format or data transfer of some sort or a power failure that occurs when beginning to read from the drive and corrupting it that way. In either case, there's not a great need for concern of someone else recovering a backup of your LUKS header. With the header alone it doesn't give them access to your data, they would still need the password to the header and that's where greater concern should be placed: making a high entropy passphrase to be used.

My question is: What methods of securing your backup LUKs header do you take to ensure it is not recovered by someone else?

None, if any. Your focus should be on securing your encrypted drive when it's not in use or if it's left unattended while unlocked on any given system.

A backup header by itself is useless and could only serve one 'usefulness' to an adversary if it's even considered useful when considering the "possibility" it enables. Which is, to run brute force attacks on trying to guess your password. Assuming you use a password longer than 8 characters with a fair amount of randomness and otherwise high enough entropy that it doesn't contain just one simple word that can be guessed but a fair mix of symbols, numbers, lower case, and uppercase; they could run that brute force for more than a century (with today's computing power) and still never figure out the password simply due to the sheer number of possible combinations it would be required to cycle through all the possible passwords that exist out there.

So, moral of the story, worry more about securing your data than securing a backup copy of your header and you'll be able to "secure it" in plain and clear sight, just so long as you put enough energy into a complicated, difficult to guess, password.

And if there's anything you should be doing to ensure you can actually use that backup, is to make sure you don't store it on the same encrypted drive it's meant for, because to replace a corrupted header, you'll need access to it and if it's in the drive that's encrypted and that won't open because you don't have access to the backup header to replace the corrupted one, should be obvious that it is self-defeating.

So, where to put the backup if not needing to hide them but you still want to anyway?

Well, you can still "hide" it if you want by creating an empty partition on any given device, such as a USB drive, an SD card, or an unformatted partition at the end of your drive (after the encrypted partition or before, doesn't matter except somewhere that it won't be accidentally written to) and write the header to that partition itself so it's hiding in clear and plain site. When backing up the header, you're no longer limited by the filesystem layer and can directly write the header to an empty partition space so that it just appears like an unformatted partition rather than a file that can be found by browsing through your various folders or whatnot... Kind of like, hidden in clear and plain sight .

You must log in to answer this question.

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