[Solved] DM-Crypt vs Plausible Deniability

MM · 2016-06-18 00:04:20

Hello,

I was researching about how to use *plain* dm-crypt and it seems ArchLinux is the only Distro with thorough enough documentation to actually explain it (Kudos! ) but... reading that article [1] it says (below the ASCII diagram) the following:

"/boot and the boot loader cannot be kept on the encrypted drive, or it will defeat the purpose of using plain mode for deniable encryption."

I understand why the boot may not be encrypted (most texts seem to refrain due to the complication of actually booting it without a boot partition, which does sound very complicated), but why would it defeat deniability?

Great wiki / docs! thx.
MM

[1] https://wiki.archlinux.org/index.php/Dm … n_dm-crypt

Last edited by MM (2016-06-18 22:30:32)

madpierre · 2016-06-18 00:43:20

Here ya go:

https://www.myattorneyhome.com/

jasonwryan · 2016-06-18 00:47:17

madpierre wrote:

Here ya go:
https://www.myattorneyhome.com/

That isn't helpful. If you aren't going to contribute constructively, don't...

madpierre · 2016-06-18 01:03:36

That isn't helpful. If you aren't going to contribute constructively, don't...

My apologies @MM and @jasonwryan.

What's your definition of the term "plausible deniability" @MM?

Last edited by madpierre (2016-06-18 01:06:18)

R00KIE · 2016-06-18 01:16:42

MM wrote:

I understand why the boot may not be encrypted (most texts seem to refrain due to the complication of actually booting it without a boot partition, which does sound very complicated), but why would it defeat deniability?

Not an expert, not even close, but I would say that would be a very strong indication that you have an encrypted disk, and if you are after plausible deniability that would defeat the purpose.

On the other hand, having a disk full of what seems to be random data is suspicious in itself. Why would you have such a thing, specially if no other disk in the machine is unencrypted and bootable? If you are up against an adversary where you might need plausible deniability then this applies: https://xkcd.com/538/

I'd say don't make life harder for yourself trying to implement plausible deniability, at least not that way. Encryption is fine to prevent your random thief from accessing your private data in case your machine is stolen, but I highly doubt that would stick with the police, three letter agencies or any state actors after you.

MM · 2016-06-18 01:32:57

madpierre wrote:

My apologies @MM and @jasonwryan.

hehe, that's ok, it did bring a smile. But yea, not quite helpful because I ask not for being in trouble (nor intending to) but because I'm interested in cryptography in general, ever since college, and it seemed too strong a statement in my opinion. (and I'm also interested in keeping Arch great documentation at this level)

What's your definition of the term "plausible deniability" @MM?

Well, a couple paragraphs earlier it does link to the wikipedia page : ) [2nd paragraph under that section, to be precise]

but I ask more specifically why "plain dm-crypt" was singled out in particular (if we all have a general idea of what the term means, do I still have to give you my definition?)..

I mean, is it *only* dm-crypt or in general?

btw, now I noticed the term plain was italicized there, so does that mean that other schemes doesn't suffer from that? or maybe it means it doesn't have anything to do with the actual crypto (which I think could be clarified if so, due to slightly misleading?).

In other words, actually because other ways of making a working /boot partition encrypted manages to somehow bypass any considerations of deniability? (maybe the built-in ZFS or other modern filesystems?)

MM · 2016-06-18 01:53:47

R00KIE wrote:

Not an expert, not even close, but I would say that would be a very strong indication that you have an encrypted disk, and if you are after plausible deniability that would defeat the purpose.

Aha, yes. I was waiting such an answer before I'd elaborate further why I think having that statement there is silly (at least without further clarification), but didn't want to influence the reply (nor sound like a dick at the outset of my very first post on Arch forums, hahaha)

and you already touched at the reason (AND the solution (kudos to you), that is, if nobody else can think of a better reason, as I can't either, thus this thread), when you said:

On the other hand, having a disk full of what seems to be random data is suspicious in itself. Why would you have such a thing, specially if no other disk in the machine is unencrypted and bootable?

Doesn't having only that lonely /boot partition of the diagram has *ALREADY* defeated the purpose? ^_^

The solution (tho yes, I doubt it would 'stick', tho less, let's call it, "self-defeating" ), would be to have that same boot partition boot something "legit" besides the encrypted stuff...

I'd say don't make life harder

Totally! btw, I had seen that comic, awesome : )

Last edited by MM (2016-06-18 01:55:05)

madpierre · 2016-06-18 03:31:33

but I ask more specifically why "plain dm-crypt" was singled out in particular (if we all have a general idea of what the term means, do I still have to give you my definition?)..

The title appears to be somewhat misleading. ("DM-Crypt vs Plausible Deniability") Perhaps a title similar to "Why the Significance of Plain DM-Crypt" would be more apropos? My request for your definition was to better understand the direction and tenor of your quest. There is never a "must do" in my regard. Hence, no need to respond to my request for clarity.

My original post was, indeed, intended to put a smile on your face but also to alert you to the generally accepted meaning of "plausible deniability". The term is also associated with terms such as actionable, pecuniary liability, damages, contributory negligence, joint and several, misfeasance, collusion, and a host of other not-so-fun terms if you're on the receiving end of judicial matters. The term "deniability" when applied to encryption is also usually framed in a legal sense. I personally can't speak to that nor can most folks on the forum who are not lawyers and familiar with the jurisdiction under which you labor.

@ROOKIE pretty well sums it up according to my thinking:

Encryption is fine to prevent your random thief from accessing your private data in case your machine is stolen, but I highly doubt that would stick with the police, three letter agencies or any state actors after you.

All the best,

Last edited by madpierre (2016-06-18 03:33:26)

kynikos · 2016-06-18 04:19:49

"Plausible deniability" is indeed more of a legal problem, than a technical one; I invite you to read sections 2.4 and 5.2 of the cryptsetup FAQ.

Going back to the OP, Dm-crypt/Encrypting an entire system#Plain dm-crypt says "dm-crypt plain mode does not require a header on the encrypted disk: this means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data, which is the desired attribute for this scenario, see also Wikipedia:Deniable encryption", i.e. the purpose is to give you something close to Full Disk Encryption, which can reduce the efforts to deny that the stored bits are actually ciphertext. Maybe it's not worded perfectly, but "/boot and the boot loader cannot be kept on the encrypted drive, or it will defeat the purpose of using plain mode for deniable encryption" means that if you choose to partition the disk and even store /boot and the ESP or MBR there, there's no sane reason to prefer plain mode over LUKS.

MM · 2016-06-18 21:34:00

kynikos wrote:

means that if you choose to partition the disk and even store /boot and the ESP or MBR there, there's no sane reason to prefer plain mode over LUKS.

Ahh, I understand now. Thanks kynikos. And thanks also for that link, it has info on adding RAID to the mix, which is something I'm also interested in. Cool! : )

usually framed in a legal sense

I see. I was confused by its use on that "/boot partition" context. Thanks.

Regards.

Edit: Should I mark this as "Solved" or is this sub-forum not required? (I can't see any such options)

Last edited by MM (2016-06-18 21:38:09)

jasonwryan · 2016-06-18 21:45:38

You can mark your thread as [Solved] by editing your first post and prepending it to the title.

dragonboy · 2020-05-20 11:40:31

Because plain DM-Crypt is a pain to setup for your main system drive. The distros have basically removed that option from their installers. It's easy to put /boot and /boot/efi on separate physical disks, but having a plain-DmCrypt system partition (or even detached LUKS header) is a bit messy and prone to errors and not properly supported in GRUB and Bootloaders without manual fiddling and risky. I would rather create a regular FDE'd system drive and have sensitive partitions which are Plain-Dmcrypted on external partitions/drives. This way you get to hide those while giving your main O/S to the questioner. Think of it as a 2 stage process, you'll never hide your main O/S, even with FDE, so just keep your data elsewhere and ensure /tmp is cleared on startup! And NEVER use UUID to mount the plain DMCrypts, as it would give them away as such. Good luck.

graysky · 2020-05-20 11:50:50

Another use case for encryption is simply in case of hardware failure where said hardware is covered by a manufacture warranty.

drcouzelis · 2020-05-20 17:47:02

Sorry, I don't quite follow what you're doing technically...

A while back when I learned about the concept of plausible deniability by creating an encrypted container INSIDE an encrypted container it blew my mind. I thought it was so cool! So I guess my suggestion would be full disk encryption to protect your data, then a relatively small encrypted container to store anything that requires plausible deniability. You want anyone looking at a decrypted drive to not even know there IS another encrypted container.

tokineko · 2022-01-02 05:21:24

dragonboy wrote:

Because plain DM-Crypt is a pain to setup for your main system drive. The distros have basically removed that option from their installers. It's easy to put /boot and /boot/efi on separate physical disks, but having a plain-DmCrypt system partition (or even detached LUKS header) is a bit messy and prone to errors and not properly supported in GRUB and Bootloaders without manual fiddling and risky. I would rather create a regular FDE'd system drive and have sensitive partitions which are Plain-Dmcrypted on external partitions/drives. This way you get to hide those while giving your main O/S to the questioner. Think of it as a 2 stage process, you'll never hide your main O/S, even with FDE, so just keep your data elsewhere and ensure /tmp is cleared on startup! And NEVER use UUID to mount the plain DMCrypts, as it would give them away as such. Good luck.

What about keeping sensitive data on drives that can be pulled out of storage racks of the main computer?
If you pulled out drives and hid them somewhere, would plain dm-crypt matter? I prefer zfs native encryption because it allows me to make encrypted back-ups.
You can also make encrypted ZFS back-ups to any computer that provides ZFS backup service because the service operator can't see the contents without the password.

You may give the main OS drive to interrogators, but you may not have to give up the password under duress.
Most of the time, you just have to hand over encrypted drives, and the interrogators will leave.
While the interrogators are trying to crack the password by automated password guessing, you can restore the main OS and sensitive data from encrypted ZFS back-up.

I have main OS drives, data drives, and an encrypted ZFS back-up drive that's hidden somewhere. It's good to have at least one off-site encrypted backup.

Last edited by tokineko (2022-01-02 05:25:51)

Arch Linux

#1 2016-06-18 00:04:20

[Solved] DM-Crypt vs Plausible Deniability

#2 2016-06-18 00:43:20

Re: [Solved] DM-Crypt vs Plausible Deniability

#3 2016-06-18 00:47:17

Re: [Solved] DM-Crypt vs Plausible Deniability

#4 2016-06-18 01:03:36

Re: [Solved] DM-Crypt vs Plausible Deniability

#5 2016-06-18 01:16:42

Re: [Solved] DM-Crypt vs Plausible Deniability

#6 2016-06-18 01:32:57

Re: [Solved] DM-Crypt vs Plausible Deniability

#7 2016-06-18 01:53:47

Re: [Solved] DM-Crypt vs Plausible Deniability

#8 2016-06-18 03:31:33

Re: [Solved] DM-Crypt vs Plausible Deniability

#9 2016-06-18 04:19:49

Re: [Solved] DM-Crypt vs Plausible Deniability

#10 2016-06-18 21:34:00

Re: [Solved] DM-Crypt vs Plausible Deniability

#11 2016-06-18 21:45:38

Re: [Solved] DM-Crypt vs Plausible Deniability

#12 2020-05-20 11:40:31

Re: [Solved] DM-Crypt vs Plausible Deniability

#13 2020-05-20 11:50:50

Re: [Solved] DM-Crypt vs Plausible Deniability

#14 2020-05-20 17:47:02

Re: [Solved] DM-Crypt vs Plausible Deniability

#15 2022-01-02 05:21:24

Re: [Solved] DM-Crypt vs Plausible Deniability

Board footer