Re: Plain dm-crypt

[Daniel Kahn Gillmor]

On Thu 2015-10-29 13:46:42 -0400, address@hidden wrote:
> No, since I type the line in manually every time, it is not located 
> anywhere for it to be discovered and need denying. I know my system very 
> well. I know if I put one USB drive into a slot, it will be named 
> (USB0). If I plug more than one USB drive into the system, I know what 
> they will be named based on their physical locations.

"Deniable" crypto seems like it would have very limited utility [0], but
there could still be some marginal use cases for it (for people who
aren't Christopher Toews, anyway: Chris has already admitted publicly on
this list to using encryption on his high-entropy devices, so he can't
deny it any longer).

If the patchset is small/simple (i haven't seen a pointer to the patches
-- can someone supply a link?), and it doesn't introduce any troubling
UI/UX issues, providing the feature in grub doesn't seem like a terrible
idea.

The other use case that Chris hasn't mentioned is that there may be
people who don't trust LUKS to adequately protect the master dm-crypt
key for their volume.  I'm unaware of any legitimate reason to distrust
the cryptography in the LUKS header itself, but i also haven't thought
deeply about attacking it either.

> Look, you can't presume to know my setup better than I do and then try 
> to convince me that I don't require this feature. I understand if it 
> won't be included, but don't hold it out because you think people are 
> too stupid to know how to use it, or worse, because you think people are 
> too stupid to know that they don't need it. There are people who want 
> this feature for good reasons and have the know-how to be able to 
> utilize it. Why can't you just accept that?

I suspect that Vladimir isn't resistant because he thinks people are
stupid.  he's probably resistant like any other responsible long-term
developer/maintainer of crucial infrastructure.  more features == more
support == more bugs, so conservatism on adding features is healthy, and
it's not surprising that he is looking for a more concrete example of
how it might get used.

That said, it's tough to to provide a more concrete use case than the
one descirbed by Chris here.  In particular, this is a feature whose
users will generally not admit to being users (since admitting to being
a user is to lose its benefit).  So i appreciate Chris being willing to
out himself here in service of others who might like to have something
that looks deniable.

(fwiw, i'd really like it if all hard drives shipped from the
manufacturer full of high-entropy noise by default.  That would provide
people like the users Chris is advocating for with much more convincing
cover)

  --dkg

[0] https://www.debian-administration.org/users/dkg/weblog/104 discusses
    deniability for chat, but similar analysis probably applies to
    encrypted volumes.