[messaging] Unlinkable rendezvous via human-sized keys (was: Re: Human sized keys)
infinity0 at pwned.gg
Sat Mar 22 18:01:16 PDT 2014
On 21/03/14 01:19, Trevor Perrin wrote:
> On Thu, Mar 20, 2014 at 8:44 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net <mailto:dkg at fifthhorseman.net>> wrote:
> On 03/20/2014 03:11 AM, Trevor Perrin wrote:
> > You'd have users exchange ~160-bit ECDH keys directly. I'd have users
> > exchange (introduction server name, ~128-bit fingerprint) and use these to
> > lookup an "introduction cert" where the fingerprinted long-term key signs a
> > short-term ECDH key.
> > Your approach eliminates the need to mask the intro-cert lookup via PIR or
> > dummy traffic. But it lowers the security of your long-term key from ~128
> > bits to ~80 bits, and reduces "forward-secrecy of linkages", since
> > compromise of the long-term ECDH key (which you've printed on your business
> > card, so you're not going to rotate it frequently) allows going through
> > published rendezvous messages and linking correspondents for the key's
> > lifetime.
> Watson's scheme is also doable with ephemeral keys, you just wouldn't
> have them on your business card -- each user could have their machinery
> generate a stash of ephemeral keys and print out one card per key. each
> card would have the public key of a single ephemeral key written on one
> half of the card (the "peer" half), and a short tag on the other half
> that identifies the private key in your client's ephemeral stash (the
> "self" half)
> you meet someone who also plays this game, and the two of you take the
> top card from each of your stacks, tear it in half, give the peer half
> to the other person, and staple or tape or otherwise pair up the two
> pieces for use later when you're online.
> Yeah, I think that loses the main benefit of a DH rendezvous though, which is that each party has a single static value which they can print on biz cards, publish widely for corroboration, or exchange via 3rd parties.
> Your process requires:
> - printing and carrying around a stack of perforated tickets
> - tearing and exchanging them
> - attaching them with staples or tape
> I think a lot fewer people would be willing / able to do that.
I think the point is that, this is something that can be added onto any long-term identity system. You could even mix the two - Alice can generate one-use identities and Bob can use his long-term identity. This comes at some extra cost to Alice (she has to remember which id she gave to Bob) but I don't think Bob has any extra cost.
In other words, we have a generic construction that lets us build ephemeral identities *on top of* a system based on long-term identities. As you say it's pretty costly, but we could think of ways to lower this cost (e.g. specify a reusable standard way of doing this), if we wanted to support it better.
(Of course, it's also probably possible to do the reverse construction, i.e. build long-term identities *on top of* a system based on ephemeral identities.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 880 bytes
Desc: OpenPGP digital signature
More information about the Messaging