[messaging] Introduction secrets and "unlinkable rendezvous" protocols

[Trevor Perrin]

On Fri, Feb 14, 2014 at 11:35 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> 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.

Yeah, but I'm arguing against that property as a default.  I think
linkable pseudonyms are a better default.  It's easier for me to
authenticate a fingerprint if other people are seeing the same value.

If you want separate identities you can create multiple keys (pseudonyms).


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

I disagree with that goal.  I also think that's an awkward user
experience:  You're asking people to print out a bunch of one-time-use
tickets, exchange and track ticket halves, and then transcribe public
keys.  Dealing with fingerprints which are (mostly) fixed per user
would be easier.


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

I don't think a trusted directory would replace the rendezvous server.
 The rendezvous step isn't just authenticating the parties, it's also
provisioning senders with secrets so they can send messages the
recipient's mailbox will accept.


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

My point is that contacting someone based on "public information" *is*
a "quick way to rendezvous with someone who they happen to meet".

So there's a tradeoff here - if you want "unlinkable" pseudonyms by
default, then you can't use well-known public-keys to assist in
authentication or rendezvous.


Trevor