You are not logged in.

#1 2014-12-11 20:12:41

Dreamkey
Member
Registered: 2010-08-28
Posts: 36

Plausible deniability on an encrypted external drive?

Hello,
I would like to use an external drive as a backup to store my personal data. As I don't care about Windows compatibility, LUKS seems good for that.
But my problem is to encrypt my critical data (like bank details), where a nested hidden volume seems a good option. Arch still has the "good" version of TrueCrypt, but its strange end of life announcement make me wonder if it's still good to use.
LUKS' author doesn't plan to add this yet, listing a number of reasons but a comment (#18) seems to tell it's feasable.

So what are my options if I want to do that?
Thanks.

Offline

#2 2014-12-11 20:13:45

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 9,572
Website

Re: Plausible deniability on an encrypted external drive?

I thought overwriting with /dev/random prior to encryption was recommended?  Look at the LUKS FAQ for more.


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#3 2014-12-11 22:53:16

clfarron4
Member
From: London, UK
Registered: 2013-06-28
Posts: 2,162
Website

Re: Plausible deniability on an encrypted external drive?

graysky wrote:

I thought overwriting with /dev/random prior to encryption was recommended?  Look at the LUKS FAQ for more.

I'd also recommend this step.

The cryptsetup-nuke-keys  package doesn't really answer the question of plausibility, because it nukes the key header of all the keys. Use this one with care, because you need to back up the key header in the event that you do use the nuke passphrase AND LUKS headers don't always restore correctly.


Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository

Offline

#4 2014-12-11 23:22:26

Dreamkey
Member
Registered: 2010-08-28
Posts: 36

Re: Plausible deniability on an encrypted external drive?

graysky wrote:

I thought overwriting with /dev/random prior to encryption was recommended?  Look at the LUKS FAQ for more.

I was planning to do that, but thanks for the reminder.

clfarron4 wrote:

The cryptsetup-nuke-keys  package doesn't really answer the question of plausibility, because it nukes the key header of all the keys. Use this one with care, because you need to back up the key header in the event that you do use the nuke passphrase AND LUKS headers don't always restore correctly.

I'm not sure I understood all the LUKS author's reasons for not implementing this option, but I don't think I will need this package. I see being forced to decrypting my personal data as a necessary evil if I want to protect my critical data.

Offline

#5 2014-12-12 08:57:16

deltasquared
Member
Registered: 2014-09-12
Posts: 12

Re: Plausible deniability on an encrypted external drive?

In regards to plausible deniability, it's possible to go even further if you're willing to roll up your sleeves...

You can do something like creating a "normal" partition containing stuff you don't care too much about, partially spanning the disk. Then, in the unallocated space beyond that partition, pick a region of sectors to use as the encrypted volume, and set up a loop device to access them.

 losetup -o [offset in bytes] --sizelimit [size in bytes] /dev/loop0 /dev/sdX 

Then, set up dm-crypt in *plain* mode on that loop device (plain mode means no header, so the encrypted data is theoretically indistinguishable from random garbage):

 cryptsetup --cipher=${chosen_cipher} open --type=plain /dev/loop0 ${some_name} 

which will make the decrypted device show up at /dev/mapper/some_name. This command prompts for a passphrase to be entered. note this command has do be re-done the same each time you need to mount the decrypted storage. You can also use a keyfile, by adding

 --key-file=somefile --key-size=${size_of_key_in_bits} 

to the cryptsetup command before "open". The mapper device can then be closed with

 crypsetup close ${some_name} 

and the raw loop device removed with

 losetup -d /dev/loop0 

If you do it this way, both the opening commands must be done manually when you want to access the encrypted storage. Additionally you'll need to remember the offset and size of the region on the external drive that is your encrypted data. However, if you overwrite the disk with random data before starting, there's no way to tell the encrypted data is there just by looking at the disk - hidden amongst the random data. The idea of the normal partition before it is to act like a decoy, so you could claim the "unallocated" space is just where you want to add a new partition later.

Offline

#6 2014-12-12 20:18:58

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 994

Re: Plausible deniability on an encrypted external drive?

Dreamkey wrote:
graysky wrote:

I thought overwriting with /dev/random prior to encryption was recommended?  Look at the LUKS FAQ for more.

I was planning to do that, but thanks for the reminder.

Overwriting with random data is only useful is the drive _used_to_ contain sensitive data that you want to destroy. Otherwise, this is a complete waste of time.

Dreamkey wrote:
clfarron4 wrote:

The cryptsetup-nuke-keys  package doesn't really answer the question of plausibility, because it nukes the key header of all the keys. Use this one with care, because you need to back up the key header in the event that you do use the nuke passphrase AND LUKS headers don't always restore correctly.

I'm not sure I understood all the LUKS author's reasons for not implementing this option, but I don't think I will need this package. I see being forced to decrypting my personal data as a necessary evil if I want to protect my critical data.

What is there not to understand? Plausible deniability is like security through obscurity -- it makes sense if you don't think too hard. In jurisdictions where law matters, nobody can force you provide a passphrase anyways; in places where the law doesn't matter, there are lots of effective ways (not involving brute force encryption breaking) to get to your data.

So, unless you are confusing this forum with a CIA training camp (or just trying to play agent 007), the exercise you are about to perform is educational but useless in real world smile


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

Board footer

Powered by FluxBB