[messaging] Introduction secrets and "unlinkable rendezvous" protocols

[Daniel Kahn Gillmor]

On 02/14/2014 01:38 PM, Trevor Perrin wrote:
> (C) With no computers, there's various ways to agree on enough entropy
> for an unlinkable online rendezvous:
>  1. People invent passwords on-the-fly, and hope that a bunch of
> key-stretching will make them strong enough.
>  2. Shuffling / splitting decks of cards (Adam's idea for Pond).
>  3. Exchanging printed "tickets" with one-time codes which you tear in
> half, as you mention in your other email.
>  4. Exchanging public-key fingerprints used to retrieve Diffie-Hellman
> public keys (my suggestion).

I also find C4 appealing, but in its usual operation violates the
"unlinkability" property of the identities that Brian was focusing on.

> Of these options, I think I still prefer C4 (Diffie-Hellman
> rendezvous).  Since it doesn't require exchanging secrets it's less
> vulnerable to problems with insufficient entropy or the secrets being
> mishandled.  And since it's based on the public-key, the rendezvous is
> tied into strong authentication, and can be done flexibly based on
> published info.

A symmetric implementation of scheme C3 should have all of the same
advantages, while preserving Brian's identity unlinkability goal:

Each party pre-generates a bunch of DH secret keys, and prints a
dual-stub copy of each public key;   At the meeting, they each tear off
their half of the pubkey and swap with their peer, stapling/folding the
two stubs together with whatever notes they want to take about the meeting.

Back at the machine that stores the secret key material, both stubs get
scanned in or re-transcribed, the secret key material corresponding to
"our" public key is fetched from storage, and an unlinkable rendezvous
point is generated from the one-off DH handshake.

>   For example, if I can query (via Tor) some trusted
> directory associating your email address and fingerprint, then we only
> need to exchange email addresses at the meeting, which would be quite
> nice.

if we have a trusted directory service then we don't need any of this
setup, since the directory service can just reserve and publish names
for users. I don't think we can rely on such a service as a solution to
this problem.

> Good point.  I'd distinguish between "unlinkable communications" and
> "unlinkable pseudonyms".  This notion of "unlinkable communications"
> is similar to how [Feigenbaum] and [Hevia] use "unlinkability", though
> [Pfitzmann] and [Backes] use "relationship anonymity".

I like the distinction between "unlinkable communications" and
"unlinkable pseudonyms".

> AIUI one of the differences between Pond and Petmail is that [Petmail]
> uses relationship pseudonyms by default (though the scope of the
> pseudonymity is limited to pseudonyms sharing the same mailbox
> server).
> 
> I argue that using relationship pseudonyms by default is undesirable,
> since it makes it harder for parties to leverage public information to
> authenticate each other or perform a "Diffie-Hellman rendezvous".

I don't think these are mutually exclusive.  A person can play multiple
roles; in some circumstances, they might want to be contactable based on
public information.  In other circumstances, they might want to just
have a quick way to establish a rendezvous with someone who they happen
to meet (without establishing identity or public pseudonyms or anything
else).

> Preventing pseudonyms from being linked requires a lot of discipline,
> so it's reasonable for users who want multiple pseudonyms to
> explicitly create them.  For most users having an easily-fetched and
> easily-authenticated public-key seems more valuable.

I agree that persistent pseudonyms are a ton of work; very easy to slip
up with; and once linked, are impossible to de-link.

But a pairwise unlinkable rendezvous isn't really a persistent
pseudonym; it's just a way to communicate securely online with someone
who you've met in person.  you might have a petname for the contact, but
it wouldn't need to be shared with anyone else, including the contact or
any rendezvous server.

	--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/20140214/eb302349/attachment.sig>