[cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-)

Michael Rogers michael at briarproject.org
Wed Aug 21 13:15:41 EDT 2013

Hash: SHA1

Hi Fabio,

It seems to me that there are two fundamental problems to solve if you
want to disguise the correlation between a node's inputs (submissions,
comments and edits) and its outputs (notifications).

The first problem is disguising the correlation between a single input
and its outputs. To do that, every output must correspond to several
possible inputs. So if you plan to disguise the correlation by
randomly delaying the outputs, you need to delay them by several times
the maximum interval between inputs. At this point two practical
questions arise:

1. Is there any maximum interval between inputs, and is it possible to
know what it is?

2. Does the resulting delay make the notification system less
responsive than, say, logging into the node once a week to check for

The second problem is disguising the correlation between a series of
inputs and their outputs, where the adversary knows that the outputs
are related. This is much harder than the first problem.

For example, if the adversary knows that a series of outputs went to a
journalist who published a certain leak, the adversary may guess that
many of those outputs were caused by inputs made by the leaker. For
each output, the adversary finds the set of suspects who could have
made an input that caused the output. If we've done a good job of
solving the first problem then there are many possible inputs per
output, so the set of suspects for each output is large. But the
leaker probably appears in more of those sets than anyone else, so the
adversary counts how times each suspect appears. The longer the series
of outputs, the more likely it is that the leaker will stand out.

In the anonymity literature, attacks like this are called intersection
attacks or disclosure attacks, and they're very effective. You're not
going to prevent them with a simple approach like random delays.


On 20/08/13 20:31, Fabio Pietrosanti (naif) wrote:
> Hi all,
> at GlobaLeaks we are going to implement a feature that want to
> mitigate time correlation attacks between a Whistleblower
> submitting something and a Receiver, receiving a notification that
> there's a new leak outstanding to be accessed.
> We already had a internal discussion and received some valuable 
> suggestions and comments available here 
> https://github.com/globaleaks/GlobaLeaks/issues/264 .
> However being the argument possibly tricky, we would like to
> subject to suggestion, criticism and review the proposal.
> That's a summary of the context:
> Overview
> When a whistleblower submits to a globaleaks node all receivers
> that they have selected as recipients for their submission will
> receive a notification informing them that a new submission has
> occurred. Other whistleblower interactions also trigger a
> notification (that should therefore be protected from timing
> attacks) and such interactions are:
> *
> A new comment is added to an existing submission by a WB
> *
> A new comment is added to an existing submission by a Receiver
> *
> A new file is uploaded to an existing submission by a WB
> Goals
> We are interested in mitigating correlation attacks based on the 
> dispatching of notifications for interactions performed by a 
> whistleblower. It should not be possible (or harder) for an
> attacker to determine which person is a whistleblower for a certain
> submission based on their capabilities (more on that below).
> Adversary model A
> Their goal is to find which user has performed a certain submission
> on a globaleaks node.
> This adversary has the following capabilities:
> *
> They can read the content of notification messages.
> *
> They can perform a new submission to a globaleaks node and
> therefore trigger notifications (i.e. they are capable of doing a
> /flooding/ /blending/ attack)
> *
> A log of traffic from N users they suspect to have blown the 
> whistle. This log includes the timestamp of when the request was 
> made, the response was received and the size of the payload.
> *
> The log of the notification traffic. This includes the timestamp
> of when the notification was dispatched and the size of it. The
> content of the notification will be either encrypted (model A) or
> plaintext (model B).
> Adversary model B
> This adversary has all the capabilities of the above adversary, but
> they do not have the ability of reading the content of the
> notification messages.
> Adversary model C
> All of the above except the receiver is not trusted: their goal is
> to de-anonymise the WB.
> Is this any different from Adversary A, that is an adversary that
> has the ability to read the notification emails because they are
> not encrypted?
> Example real world scenario
> The GL node is a GL node for a private company. The adversary is a 
> Manager of The Company that wants to find out who blew the whistle
> on the fact that he is recycling money through a shell company in
> the island of mann. Since they are on the receiver list, because
> the globaleaks node was configured to have a plurality of
> receivers, they will be able to read the content of the
> notification emails.
> The whistleblower decided to blow the whistle on from their office
> and the office network has a proxy that logs every HTTP request
> being done.
> When the Manager receives a notification that a new submission has
> been done to the globaleaks site they take the timestamp of such
> notification and look at the traffic logs for that period of time
> to see who was generating traffic during that period of time and
> based on this they should not be able to distinguish normal Tor
> user (or people loading the cover traffic widget) from the
> whistleblower.
> Thanks in advance for opinion!
> -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and
> Digital Human Rights http://logioshermes.org -
> http://globaleaks.org - http://tor2web.org
> _______________________________________________ cryptography
> mailing list cryptography at randombit.net 
> http://lists.randombit.net/mailman/listinfo/cryptography

Version: GnuPG v1.4.10 (GNU/Linux)


More information about the cryptography mailing list