1

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
1

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 
204800

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

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

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                 
200704

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. – 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
0

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.

-1

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. – 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

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.