On Mon, Oct 06, 2014 at 08:56:05PM +0000, Jonathan Wilkes wrote: > Hi Danny, > Unfortunately it's impossible to draw any conclusions from your data > point. For example, here in the U.S. I'd actually want a longer > interrogation if the alternative is local law enforcement effortlessly > exploiting my device and copying all my data from it. > -Jonathan
Sorry, I think I was perhaps not clear. Of course it's better to have encryption, but having a tool which leaves traces of its existence but has a plausible deniability feature regarding the contents of the encryption seems to have minimal benefits, compared to just cordoning off the encrypted content in a way that is (physically) hideable. This statement works as well in a US situation as the rubberhose scenario. We just don't have that many examples of situations where most of the initial advantages of plausible deniability aren't provided for just as well by physically hiding material. And those situations aren't usually ones where you can realistically create a secondary corpus of convincing alternative material. So I think in practice, we all end up recommending cordoning material, and encrypting that, but not creating a deniable partition. d. > > On Monday, October 6, 2014 2:53 PM, Danny O'Brien <da...@eff.org> wrote: > > On Mon, Oct 06, 2014 at 05:56:59PM +0100, Eleanor Saitta wrote: > > On 2014.10.06 01.56, Bill Cox wrote: > > > I will have an impact on the code going forward. Also, I am > > > entirely a pragmatist. I am an engineer, not a cryptographer, and > > > I build stuff that works in the real world. Can you explain a > > > deniable crypto-system that fits the real world? > > > > It's unclear that there is one. I'd feel far happier recommending a > > (new, continued development, audited, etc.) version of Truecrypt with > > no deniability features at all. Using the features in such a way that > > you don't leave traces of the container has always been really, really > > difficult -- if you read the docs page on what's required to evade > > forensic detection, it should be pretty clear how unsuitable this > > feature is for regular users. Yes, some of those might be removable > > with significant developer effort, but I'm not sure why that's worth > > it, given the larger issues. > > > > I think one of the challenges here is that, to the extent that deniable > crypto-systems are used and understood in the real world, the switch > from "we will use our ingenious forensic tools to detect your > subterfuge" to "we will beat you up until you tell us the password" is > prompted by Truecrypt's presence and notoriety, rather than any feature > of the software. By that, I mean that the one data point I have is > talking to activists who say that if their laptop or devices are > inspected, having Tor and Truecrypt visibly installed is a signal for > further interrogation. > > So we're really in a position where hiding the application from casual > inspection is more important than the cryptosystem, because the > cryptosystem is going to be bypassed by rubberhose cryptoanalysis once > noticed. Security developers hate this, I think, because hiding an > application's traces on a standard OS is an endless task with no > guarantee that we haven't left some sort of fingerprint which is > trivially detectable with the right kind of tool. This is one of the > reasons why practical advice seems to be moving more towards the "have a > secure device which you hide" rather than "use secure software on your > visible everyday device". > > A hidden, cordoned device allows us to make a much stronger assertion > about the safety of its contents, and a much clearer moment to describe > when its contents may be breached. Under this design, deniability really > isn't something you implement in software. Deniability comes from > physically hiding the device. There's no deniability *within* Truecrypt > because Truecrypt use itself is already perceived as an indication of > guilt. > > d. > > > > > > I think we who are trying to keep TrueCrypt alive could use your > > > advice. > > > > Happy to chat more. > > > > E. > > > > -- > > Ideas are my favorite toys. > > -- > > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, > change to digest, or change password by emailing moderator at > compa...@stanford.edu. > > > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, > change to digest, or change password by emailing moderator at > compa...@stanford.edu. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
