[liberationtech] Security / reliability of cryptoheaven ?

[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

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.

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.

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.

> 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.

Nick