[messaging] Introduction secrets and "unlinkable rendezvous" protocols

Robert Ransom rransom.8774 at gmail.com
Tue Feb 18 17:37:52 PST 2014


On 2/18/14, Trevor Perrin <trevp at trevp.net> wrote:
> On Mon, Feb 17, 2014 at 11:56 PM, Brian Warner <warner at lothar.com> wrote:
>> On 2/15/14 4:50 PM, Trevor Perrin wrote:
>>
>>> 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.
>>
>> Would that require some sort of PIR protocol? Seems like the mirrors
>> could learn who's interested in whom at about the same time, and thus
>> deduce the connection.
>
> Hmm, good question.
>
> The directory would learn: "a Tor user is interested in Alice" and "a
> Tor user is interested in Bob".  These wouldn't be tightly correlated
> in time, as Alice and Bob might fire up their app at different times
> after the meeting.
>
> If the directory can also monitor users as they communicate with Tor
> entry nodes, it could attempt end-to-end timing correlation (But this
> is also true of a rendezvous server with meeting IDs, not just my
> proposal).
>
> Some possible defenses, not sure which are best:
>
> - Have all users occasionally send dummy lookups to the directory.

There is no such thing as ‘dummy traffic’.

>  - Eliminate the central directory and lookup a party's key at a
> directory of her choice.  So instead of just exchanging fingerprints,
> Alice and Bob exchange <fingerprint><@directory-name>, and choose
> directories who they trust not to do these things.

This reveals more information to an attacker passively observing the
directory server.

>  - Access the directory over a high-latency mix network, to break up
> the end-to-end timing correlation.

* Even a high-latency-variance anonymity system cannot guarantee that
there will be a large enough anonymity set to hide the Alice<->Bob
connection.

* If you believe that a low-latency anonymity system is adequate to
provide anonymity, then using a high-latency-variance anonymity system
is roughly equivalent to having the client wait for a random amount of
time, then send a message using a low-latency anonymity system.

* I don't trust users to not send low-latency messages, even if they
do use (a protocol equivalent to) a high-latency-variance anonymity
system.

PIR is a very good idea.


Robert Ransom


More information about the Messaging mailing list