I have a disk containing (only) a LUKS encrypted volume. That was created on a bare drive with no partition table using cryptsetup v.1.6.1. When unlocked, I can check the size of the decrypted volume, compare it to the whole disk, and see that the difference is exactly 2MB. When I back up the header, on the other hand, using:

cryptsetup luksHeaderBackup /dev/sda --header-backup-file <filename>

I get a file that is 30kB less than 2MB. Using dd to dump the first 2MB of the disk and comparing it to the backed up header, I see that the 30KB is missing from the end and contains all 0's. Oddly, I have backups of various (other) LUKS headers using cryptsetup 1.4.1 and 1.4.3, and they are all exactly 2MB. This is consistent with section 6.2 of the cryptsetup FAQ, which says header size should be 2MB.

Could someone help me understand what this 30KB is? (I would like to overwrite the header with random data as I've put it on a separate device, and want to make sure I know what I'm doing.)

Also as a more general issue, is there an easier/automated way, using the output of luksDump perhaps, to tell exactly where the header is located on a disk? (Both offset and size.) I have read the cryptsetup FAQ, but the result certainly doesn't just drop out.

And, is there a better way to overwrite the header, than using dd?

cryptsetup luksHeaderRestore <file_with_random_data>

doesn't work, because cryptsetup does some idiot checks to see if any already present header matches in master key size and offset.

1 Answer 1


It turns out the 30k is unused space, but the header data's been aligned to 1MB. The whole 2MB were included when backing up with earlier versions of cryptsetup, but later versions leave it out.

By using the payloadOffset output of cryptsetup luksDump (a number of 512B sectors), it's possible to see the offset where the encrypted volume begins; so you can wipe manually up to there. Or, since cryptsetup 1.6.4, you can use cryptsetup luksErase to overwrite all active keyslots. The remaining visible header with metadata is the first 4KB of the disk, so that would have to be wiped manually.

[Thanks to Milan, one of the cryptsetup dev's, at cryptlab!]

You must log in to answer this question.

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