Nick Daly: > On Tue, Oct 9, 2012 at 7:24 AM, Jacob Appelbaum <[email protected]> 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 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
