[messaging] Unlinkable rendezvous via human-sized keys (was: Re: Human sized keys)

[Ximin Luo]

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

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

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140323/83b4a8e3/attachment.sig>