John S. Denker writes:

> A scenario of relevance to the present discussion
> goes like this:
>   -- There exists a data haven.  (Reiter and Rubin
>      called this a "crowd".)
>   -- Many subscribers have connections to the haven.
>   -- Each subscriber maintains a strictly scheduled
>      flow of traffic to and from the haven, padding
>      the channel with nulls if necessary.
>   -- All the traffic is encrypted, obviously.
>
> Then the opponent can put unlimited effort into
> traffic analysis but won't get anything in return,
> beyond the _a priori_ obvious fact that some pair
> of subscribers *may* have communicated.

This is not true, and in fact this result is one of the most important
to have been obtained in the anonymity community in the past decade.  The
impossibility of practical, strong, real-time anonymous communication has
undoubtedly played a role in the lack of deployment of such systems.

The attack consists of letting the attacker subvert (or become!) one of
the communication endpoints.  This can be as simple as running a "sting"
web site offering illegal material.

Then the attacker arranges to insert delays into the message channels
leading from subscribers into the crowd.  He looks for correlations
between those delays and observed delays in the message traffic to his
subverted endpoint.  This will allow him to determine which subscriber
is communicating with that endpoint, regardless of how the crowd behaves.

It will often be possible to also trace the communication channel back
through the crowd, by inserting delays onto chosen links and observing
which ones correlate with delays in the data observed at the endpoint.
This way it is not necessary to monitor all subscribers to the crowd,
but rather individual traffic flows can be traced.

Wei Dai's PipeNet proposal aims to defeat this attack, but at the
cost of running the entire crowd+subscriber network synchronously.
The synchronous operation defeats traffic-delay attacks, but the problem
is that any subscriber can shut the entire network down by simply delaying
his packets.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to