Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deniability and Duress

mit.edu

Post reply on HN
Print view View original

81–90 of 124 posts

Re: Deniability and Duress

#81

Post by ianferrel »

rattray wrote: post #79
77pt77 wrote: post #77

Earlier quoted context omitted.

The most disseminated example is TrueCrypt's hidden volumes.

Can you (or others) elaborate here?

Truecrypt is a (now discontinued) encryption program that allowed you to nest encrypted containers within one another in a way that if you provided Password1, it would open Container1, and if you provided Password2, it would open Container2.

Since the Container's full size was allocated at creation, and the size of the contents cannot be determined without the key, this gave plausible deniability. You could keep your real sensitive information in an encrypted volume, and put something that could plausibly be sensitive but that you didn't really care about someone getting in a nested volume, and when forced by the law/rubber hose to decrypt, provide the password to the volume you don't care about, and there's no way for anyone to prove that you didn't fully decrypt the contents.

Re: Deniability and Duress

#82

Post by stinkytaco »

miend wrote: post #76
Rafert wrote: post #75

Earlier quoted context omitted.

Why not both? A password with a U2F security key seems hard to beat.

I use this combo whenever possible, though the number of services yet supporting FIDO/U2F is still a bit disappointing. It's been incredibly convenient to be able to use my bitcoin hardware wallets to double as U2F keys wherever I need them. Given that any device I would use an OTP or text 2FA solution with already requires time to unlock, it's far less convenient on top of being more exploitable.

Are you using the ledger as a wallet? Doesn't plugging the device into an untrusted PC worry you at all? Leaving all that aside, the biggest issue for me an u2f is the mobile problem I have a yubikey neo, but u2f does not work over nfc, so I'm still stuck creating application passwords for things.

Re: Deniability and Duress

#83

Post by StavrosK »

TeMPOraL wrote: post #56
StavrosK wrote: post #40

Earlier quoted context omitted.

Yes, that's why everyone should be using it.

Or simply it should be shipped by default with your operating system. That way, everyone has it, whether they need it or not, and you can claim you don't know what that is and it must be something that came with your Windows copy.

Yep, that's another good idea.

Re: Deniability and Duress

#84

Post by forgotpwtomain »

I think this article is glossing over an important part of the discussion. Biometric Information is good for user identification it is not good for passwords and AFAIK this is a widely shared-opinion across security professionals. Don't use fingerprints as passwords to protect sensitive data.

Re: Deniability and Duress

#85

Post by munificent »

turc1656 wrote: post #65

"However, the bad news is that hand-typed passwords are increasingly seen as the way of the past; hardware tokens and biometric sensing are considered to be far more usable, and will likely be employed more and more in the future." Anytime you sacrifice security for convenience or simplicity, you lose. That's why I have no intention of ever using anything other than good ol' alphanumeric passwords that must be entere…

> Anytime you sacrifice security for convenience or simplicity, you lose.

No, you don't. And it's exactly this kind of black and white, all or nothing thinking that has hampered the success of the security community for decades.

Security folks, for obvious reasons, are only ever thinking about user scenarios where active security is needed. Scenes involving rubber hoses, angry cops, jealous spouses, competing corporations, etc. Those scenes matter, but they are a very small fraction of most users lives'.

Users are not stupid. When they reason about security, they think about all of the scenarios in their life. And, for every time they get picked up by the secret police and would be really glad they picked a 14-digit alphanumeric passcode, they know there are a million more times where they wanted to take a picture of that cute thing their kid is doing right now and don't want to spend the time unlocking the phone.

That is a real win in the user's mind. And those many small conveniences and joys are a huge part of the equation of their life.

Well-designed systems give users good security by integrating into their whole life, not just the idealized nefarious circumstances security folks spend all day thinking about. If you make your security too annoying, users will route around it, and now they have no security.

Re: Deniability and Duress

#86

Post by SilasX »

ianferrel wrote: post #81
rattray wrote: post #79

Earlier quoted context omitted.

Can you (or others) elaborate here?

Truecrypt is a (now discontinued) encryption program that allowed you to nest encrypted containers within one another in a way that if you provided Password1, it would open Container1, and if you provided Password2, it would open Container2. Since the Container's full size was allocated at creation, and the size of the contents cannot be determined without the key, this gave plausible deniability. You could keep your…

But isn't it a non-trivial problem to generate plausible fake data?

Re: Deniability and Duress

#87

Post by canadaduane »

mspecter wrote: post #71

Hi, author here. Really happy (but somewhat surprised) to see this up on HN, and am generally interested in pursing this as a PhD thesis topic. If anyone has ideas or thoughts on novel systems in this arena I’d be very interested to hear about it!

Is it possible to create a "zip file" format that looks like a normal zip file, but has two passwords and two separate paths to decode to different content?

Re: Deniability and Duress

#89

Post by _archon_ »

CJefferson wrote: post #61
mynegation wrote: post #33

Earlier quoted context omitted.

I immediately thought the same thing upon reading. One thing that comes to mind is: automatically triggered data destruction. If laptop or the phone detects non-owner access attempts and destroys data on its own, is it destruction of evidence? Owner did not do it, and it was there just to protect from the real bad guys: corporate spies, identity thieves.

The law often uses intention. Could you convince a jury of your peers you didn't do this just to hide your stuff from law enforcement?

The obvious rebuttal is that you did this to hide your stuff from EVERYONE. Criminal mens rea doesn't exist; you're just a citizen who likes his privacy.

Re: Deniability and Duress

#90

Post by ensignavenger »

SilasX wrote: post #86
ianferrel wrote: post #81

Earlier quoted context omitted.

Truecrypt is a (now discontinued) encryption program that allowed you to nest encrypted containers within one another in a way that if you provided Password1, it would open Container1, and if you provided Password2, it would open Container2. Since the Container's full size was allocated at creation, and the size of the contents cannot be determined without the key, this gave plausible deniability. You could keep your…

But isn't it a non-trivial problem to generate plausible fake data?

You would use a 'fake' container for safe work that you don't mind revealing, while only entering your 'secret' container only when, and alway when, doing work you want to keep secret. This way. there isn't really any 'fake' data, just different data.
Post reply on HN