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

[Daniel Kahn Gillmor]

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.

back at your computer later, you feed the data from both parts into your
messaging application and it derives the ephemeral rendezvous secret.

From the rendezvous, you ratchet forward to new ephemeral keys, and
optionally bind the exchange to a stronger persistent long-term key.

This provides forward secrecy of linkages and strong long-term keying,
and eliminates the need for a larger long-term directory service.

The extra cost is borne by the user, who has to print and maintain these
one-off cards.

	--dkg

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