[liberationtech] Security / reliability of cryptoheaven ?

[Jacob Appelbaum]

Nick Daly:
> On Tue, Oct 9, 2012 at 7:24 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> Maxim Kammerer:
>>> 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].
>>
>> 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.
> 
> I've been working on a more generalized form of protocol-independent
> communication for the last few months with FBuddy:
> 
> https://gitorious.org/freedombuddy/freedombuddy

Awesome - I'm glad to see so much progress since we last talked in Brazil.

> 
> Thanks to other FreedomBox work (and dayjob commitments) it hasn't
> received half as much love as it should've, but it's a good part of
> the way there, so maybe this is a good time to talk about it (I wanted
> to finish a few outstanding features first, but that might just be
> vanity).  The essential point is that folks exchange connection
> information, once.  From then on, automated services pull location
> information over any protocol that both end points share.

I think that is similar to what we discussed - so we could bump phones,
scan a qr code and then we have enough information to securely
bootstrap, right?

> 
> For example, I could get your host location (which might be an .onion
> address, a GNUnet document ID, etc.) and pull that information down.
> That initial request also contained my host location, so you now know
> where to find me, across the many protocols we both might support.
> 

Ideally, we'd implement it in a privacy preserving way where we'd
support by default, a challenge - perhaps we let blank challenges slide
in for some uses but other times, we can actually provision a .onion per
group or even per user relationship. The challenge could be stored in
the buddy list and hooked into the FreedomBox - so we'd automatically
alias ourselves, allow them to see certain information when they show
up, etc.

> It's essentially turning the issue of dynamic connections into one of
> data exchange at pre-shared locations.  The hard part is the second
> 90%, that of pushing those location updates into the services that
> need them.  Right now, it relies on PGP for message signing and
> encryption, but other verification methods (OTR, others) are also
> possibilities.
> 

Sure - the key point is that it attempts to turn a single meeting into
resolving a bunch of hard to know, hard to remember, hard to use points
of discovery.

>> 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.
> 
> I'd love to hear more about that when you have time.  It could be very
> useful to FBuddy and similar tools.
> 

Sure - I can send you a draft paper when it is suitable for others to read.

I plan on releasing a fairly simple plugin, a fairly simple server, a
parasitic client (in the plugin), and a paper. In the reverse order, I
think... :)

I think my latest draft called the idea PANDA.

All the best,
Jake