Deniability is not inherently better. Of course it has advantages. But a world that only had deniable cryptography would be worse than one which also had systems like TrueCrypt whose presence is not hidden.
It makes no sense to argue that an improved version of TrueCrypt is no better if it’s not deniable. Maybe there will be a rubber hose attack, maybe not. Many attackers are not in a position to do that. And deniability has costs which may lower resistance to other types of attack. On October 6, 2014 at 11:54:03 AM, 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.
