[messaging] Introduction secrets and "unlinkable rendezvous" protocols

Rich Griffin rich.griffin at gmail.com
Mon Feb 17 05:08:15 PST 2014


Is there anything from OTR protocol v3 that can be leveraged for
TextSecure? https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

    *Rich Griffin*



On Sat, Feb 15, 2014 at 6:50 PM, Trevor Perrin <trevp at trevp.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:
> ...
> >>>  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
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140217/d95c1fd3/attachment.html>


More information about the Messaging mailing list