[liberationtech] Security / reliability of cryptoheaven ?

[Jacob Appelbaum]

Maxim Kammerer:
> On Wed, Oct 3, 2012 at 2:41 PM, D J Capelis <djcapelis at cs.ucsc.edu> wrote:
>> I like the part where you say the problem is easy and then point to a
>> solution with issues that make it anything but easy, tenable or workable.
> 
> Why? The solution (if you refer to cables in Liberté) is easy to use,
> is robust, and it works. Here is a sample feedback that I found online
> (translation mine): “The Tor email [referring to cables] is
> brilliantly implemented. No registration or setup whatsoever, during
> first boot a unique email address is configured, and this way it is
> possible to correspond with others like you” [1].
> 

This is an interesting observation - it is a self-selecting user base -
it is easy to use as long as you know 0) how to make a bootable disk, 1)
you know how to decide if your computer supports it, 2) it does support
and it all loads properly and 3) everyone you care to communicate with
also fits that model.

We have seen with Tails that the 0-2 is rare except in groups where 3)
is really very solidly true.

I personally think the cables design in Liberté is really quite
interesting. If it was possible for Tails to support it and for other
chat programs to support it as well, I think we could shift the burden
presented above and it would help to attract a different user base.

I imagine their feedback might be interesting at the very least.

> Even the CryptoHeaven solution that I criticized above is good,
> discarding minor issues that can be easily fixed, and discarding
> what's apparently a security-usability tradeoff decision: not
> incorporating a public key hash in the username (making the user
> address self-authenticating). There is apparently no solution to this
> tradeoff — see Zooko's triangle in [2].
> 
> [1] https://ns-wp.ws/forum/index.php/topic,4983.msg69093.html#msg69093
> [2] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
> 

One consideration is a server that keeps a running list - it is a point
of centralization, of course. Aaron Swartz has suggested such a thing in
the past:
http://www.aaronsw.com/weblog/squarezooko

Then there is stuff like NameCoin and other designs. Ultimately, I think
we agree that no solution is worth the security trade offs as of yet. I
think it isn't a totally lost cause for private groups that run their
own servers or some kind of TOFU bootstrapping model.

Imagine an OTR extension that allows you to pass your .onion address
over an authenticated jabber/aim/whatever session - now you can meet
again on a decentralized system. You'll also already have the
username/alias/realname in the chat client, I think.

>> But saying that it's not a hard problem makes the real challenges that
>> remain less visible. Throwing layers of encryption on e-mail is easy.
>> Verifying that it's being encrypted to the right person is *still* hard.
> 
> That's why you need self-authenticating addresses, or another way of
> non-optional recipient authentication.
> 

Agreed.

Another useful thing is a dynamic, cryptographically secured but time
limited, federated meeting protocol. I've been working on such a
protocol and I hope to finish it before the end of the year. If you'd
like to talk about it, I bet we could put it and cables together for
something quite usable.

>> And that's not even getting into platform inter-op issues that
>> drive so many people to want to do their crypto in a web interface or on
>> some other person's server.
> 
> You can't provide interoperability between secure and insecure systems
> while leaving the security intact. That's why the military uses
> compartmentalization and air gaps.

Indeed and even that has issues. Problems everywhere...

> 
>> Pretending it's an easy problem because technologies exist that aren't
>> usable ignore the real technology issues we haven't solved yet.
> 
> Only if you want to use technologies that weren't developed with
> security in mind.
> 

Solving the problems presented are pretty easy - if users explicitly
want security *and* another goal - such as an easy to remember name -
they must understand that currently, we have no way to satisfy both
safely. Users can't always get what they want but perhaps there are
better ways to communicate that issue?

All the best,
Jacob