>> 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: ... >>> 4. Exchanging public-key fingerprints used to retrieve Diffie-Hellman >>> public keys (my suggestion).
Here's a better sketch of the "DH rendezvous" idea, fwiw. Users could create signed "introduction certificates" weekly, containing: - their long-term public signing key - a short-term DH key - their mailbox server's address - an expiration date - a signature over all values Users would publish these certs into an "introduction directory", which would be a widely mirrored repository of unexpired introduction certs. During an offline meeting, users would exchange their long-term fingerprints. They would then enter the other party's fingerprint into their app, which would perform some pre-rendezvous steps: - Retrieve the other party's introduction cert by querying one of the mirrors. - Calculate the DH shared secret between both parties' short-term DH keys. - Decide whose mailbox server to use as a rendezvous server, based on the shared secret. Also use the shared secret to derive the meeting ID and a symmetric key for encrypting KeyExchange messages. If Alice's mailbox server is being used for rendezvous, Alice will do the following: - Alice will have a bunch of "rendezvous tokens". Alice's mailbox server gives these tokens to its users via a blind signature scheme, so it can recognize authentic tokens but can't trace them. - Alice will use a rendezvous token to register the meeting ID with the mailbox server, and post up her encrypted KeyExchange (over Tor). The mailbox server will learn that one of its users is performing a rendezvous, but won't know that it's Alice. - Bob will contact Alice's server using the meeting ID, post his encrypted KeyExchange, and retrieve Alice's. - Alice will retrieve Bob's KeyExchange and the rendezvous is complete. Advantages vs. rendezvous server with introduction secrets: - The "introduction directory" is handling public data so can be mirrored widely (unlike a "rendezvous server" handling low-entropy meeting IDs). - The mailbox/rendezvous server only stores rendezvous messages associated with its own users, so is less susceptible to being flooded with junk. - The "rendezvous latency" is reduced since only KeyExchange messages need to be exchanged through the mailbox/rendezvous server (not key agreement messages). - Rendezvous can be done based on public data (fingerprints), instead of requiring a prior exchange of secrets. Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
