If I use LUKS encryption provided --header=<file> option, will it be equivalent to using dm-crypt in terms of plausible deniability or will there still be a way to tell that the given partition is LUKS-encrypted, albeit doesn't contain the header?

  • 4
    IMO there is no such thing as "plausible deniability". Encrypted partitions stand out like a sore thumb due to the random data written to disk and who in their right mind is going to believe what you tell them is or is not on the partition ? See xkcd.com/538
    – Panther
    Jan 5, 2016 at 21:45
  • 1
    @AlexanderSolovets The only people who have a bunch of random bytes are smartasses who want to deny having encrypted data. So it doesn't work. Jan 5, 2016 at 23:25
  • 1
    As far as I studied from the archlinux wiki pages recently, I think the answer is YES := Plain dm-crypt equals to headerless LUKS. In Plain mode, it uses CBC and allows ESSIV also (but I do not know where it stores the IV, we need to specify it everytime when open?). So, given that we can configure both keys to the same value, the cipher text (the encrypted data) should be the same. Thus the encrypted bits (of the data-only) stored in the hard drive should be the same.
    – midnite
    Apr 9, 2019 at 3:56
  • 1
    "Encrypted partitions stand out like a sore thumb" - this is why you do this on a full-disk (no partition table or anything) that was securely wiped (or even just 1 pass of random data) beforehand, so you[r lawyer] can argue that you'd not used the disk since it was wiped / that you "already securely wiped the data" May 18, 2020 at 16:13
  • 1
    Hope you are still interested in this question. For the encrypted disk, yes, plain dm-crypt is identical to headless LUKS. You can simply verify it by dumping the master key of LUKS, then use it to encrypt another disk by plain dm-crypt. However, as I am currently researching on this topic, the present of header in Key USB of a headless LUKS setup makes it less secure than using plain dm-crypt properly. If attacker obtained a clone of the header in Key USB, the attacker can try to decrypt (verify passphrase) during the times before actually obtaining the encrypted disk.
    – midnite
    Jun 6, 2022 at 16:53

3 Answers 3


If you use --header then only data is written to the device. You can check that by creating a loop device and use luksFormat once with and once without --header. If you use that option then the encrypted device is not changed and the decrypted device is larger.

start cmd: # cd /tmp

start cmd: # dd if=/dev/zero of=luks.img bs=1M count=100

start cmd: # dd if=/dev/zero of=luksheader bs=1M count=10     

start cmd: # cryptsetup --force-password --header luksheader luksFormat /dev/loop0 

start cmd: # cryptsetup --header luksheader luksOpen /dev/loop0 luks

start cmd: # blockdev --getsz /dev/mapper/luks 

start cmd: # blockdev --getsz /dev/loop0

start cmd: # dd if=/dev/loop0 bs=1K count=1 | od
0000000 000000 000000 000000 000000 000000 000000 000000 000000

start cmd: # cryptsetup luksClose luks                         

start cmd: # cryptsetup --force-password luksFormat /dev/loop0                     

start cmd: # cryptsetup luksOpen /dev/loop0 luks               

start cmd: # blockdev --getsz /dev/mapper/luks                 

start cmd: # dd if=/dev/loop0 bs=1K count=1 | command od       
0000000 052514 051513 137272 000400 062541 000163 000000 000000
0000020 000000 000000 000000 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 072170 026563 066160 064541
  • Thanks for a comprehensive response, but how does this answer my question? I do realize that only data are written in the absence of header, so at a glance the effect should be same as when plain dm-crypt is used, but I'm not sure. Jan 6, 2016 at 1:19
  • 1
    @AlexanderSolovets It is not just the same effect but indeed the same technical procedure. You can run dmsetup table devicename and see that LUKS does exactly what you would do manually. Jan 6, 2016 at 1:59
  • Does this mean that so-called "headerless LUKS" would offer similar "plausible deniability" as to whether a drive had been wiped if the header were generated deterministically from the password at run/mount/boot time? May 18, 2020 at 16:12
  • @JamesTheAwesomeDude I guess you can say that. But unless you are willing to type all the commands each time, there is a script or binary asking for the password; maybe even started automatically. In order to be plausible you have to wipe at least that. And perhaps its directory entry (depending on the name). "Plausible" is subjective anyway. You could say "Yes, that was my headerless LUKS partition but I overwrote it with random data". May 18, 2020 at 17:07
  • @HaukeLaging - A script/bootCD to do such would be "equivalent" (in this sense) to a copy of the TrueCrypt software. Certainly indicative, but: they can't tell which of the many apparently-random drives laying around (if any!) is actually a headerless LUKS ...My claim/hypothesis is that this method would provide as much PD as TrueCrypt itself did (I'm mostly certain this is the case, but am looking for a check on that claim per se. Whether or not TC/VC would be considered "plausibly deniable" is an out-of-scope can'o'worms.) May 18, 2020 at 17:58

For LUKS archives:

What about creating a normal but decoy/fake LUKS header on the device? Follow along; I could run urandom (or other faster noise filling on the media) via the decoy header to completely noise fill using that decoy header.

Now I save that header to restore it when I want to. Next I create a new header with secure password and the create my filesystem and use it when I want to save files.

A little work but executable shell scripts would make this fast and easy. When I want to use the media I write the correct luks header to the media and have full access to the filesystem. When finished I wipe the header area and then write the decoy LUKS header back to the media. Would be super easy and fast with an executable shell script.

It would seem to me that if I opened the LUKS media using the decoy header that it would appear to be completely wiped and since there is no such a thing as hidden volumes the suspicion of such a move would not be high.

Just a thought.


No, they are not equivalent in terms of plausible deniability. The reason is the existence of the header file, which is not cryptographically hidden.

  • 1
    I explicitly stated "headerless" LUKS, meaning that the header is detached off the main data and is stored elsewhere. Jul 21, 2016 at 4:11
  • I know, and my answer still stands. "Elsewhere" is not cryptographically hidden. Jul 21, 2016 at 4:14
  • the existence of the header file - that's a separate issue from the headerless LUKS disk itself. The header could be deterministically generated from the password and select settings in a TrueCrypt-like/-knockoff interface to headerless LUKS. May 18, 2020 at 16:17

You must log in to answer this question.

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