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 '16 at 21:45
  • @bodhi.zazen for this question you can think of plausible deniability as a fairly random set of bytes. – Alexander Solovets Jan 5 '16 at 21:49
  • 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. – Gilles 'SO- stop being evil' Jan 5 '16 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 '19 at 3:56
  • "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" – JamesTheAwesomeDude May 18 at 16:13

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
| improve this answer | |
  • 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. – Alexander Solovets Jan 6 '16 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. – Hauke Laging Jan 6 '16 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? – JamesTheAwesomeDude May 18 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". – Hauke Laging May 18 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.) – JamesTheAwesomeDude May 18 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.

| improve this answer | |

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

| improve this answer | |
  • 1
    I explicitly stated "headerless" LUKS, meaning that the header is detached off the main data and is stored elsewhere. – Alexander Solovets Jul 21 '16 at 4:11
  • I know, and my answer still stands. "Elsewhere" is not cryptographically hidden. – metaquanta Jul 21 '16 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. – JamesTheAwesomeDude May 18 at 16:17

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.