Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] TrueCrypt Alternatives?

Lucas Gonze lucas.gonze at gmail.com
Mon Oct 6 12:05:34 PDT 2014


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 (danny at 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 companys at 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 companys at stanford.edu.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20141006/083a1d2c/attachment.html>


More information about the liberationtech mailing list