Re: traffic analysis
A couple of people wrote in to say that my remarks about defending against traffic analysis are "not true". As 'proof' they cite http://www.cypherspace.org/adam/pubs/traffic.pdf which proves nothing of the sort. The conclusion of that paper correctly summarizes the body of the paper; it says they "examined" and "compared" a few designs, and that they "pose the question as to whether other interesting protocols exist, with better trade-offs, that would be practical to implement and deploy." Posing the question is not the same as proving that the answer is negative. I am also reminded of the proverb: Persons saying it cannot be done should not interfere with persons doing it. The solution I outlined is modelled after procedures that governments have used for decades to defend against traffic analysis threats to their embassies and overseas military bases. More specifically, anybody who thinks the scheme I described is vulnerable to a timing attack isn't paying attention. I addressed this point several times in my original note. All transmissions adhere to a schedule -- independent of the amount, timing, meaning, and other characteristics of the payload. And this does not require wide-area synchronization. If incoming packets are delayed or lost, outgoing packets may have to include nulls (i.e. cover traffic). This needn't make inefficient use of communication resources. The case of point-to-point links to a single hub is particularly easy to analyze: cover traffic is sent when and only when the link would otherwise be idle. Similarly it needn't make inefficient use of encryption/decryption resources. This list is devoted to cryptography, so I assume people can afford 1 E and 1 D per message; the scheme I outlined requires 2 E and 2 D per message, which seems like a cheap price to pay if you need protection against traffic analysis. On top of that, the processor doing the crypto will run hotter because typical traffic will be identical to peak traffic, but this also seems pretty cheap. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffix analysis
I agree with anonymous summary of the state of the art wrt cryptographic anonymity of interactive communications. Ulf Moeller, Anton Stiglic, and I give some more details on the attacks anonymous describes in this IH 2001 [1] paper: http://www.cypherspace.org/adam/pubs/traffic.pdf which explores this in the context of ZKS Freedom Network, and Pipenet presenting attacks on the Freedom Network, Onion Network, Crowds and Pipenet which affect privacy and availability. Adam "Traffic Analysis Attacks and Trade-Offs in Anonymity Providing Systems", IH 2001, Adam Back, Ulf Moeller, and Anton Stiglic. On Wed, Aug 27, 2003 at 09:17:05PM -0500, Anonymous wrote: > 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] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffix analysis
At 09:17 PM 8/27/2003 -0500, Anonymous wrote: 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. Using random "throwaway" WiFi neighborhood hotspots can blunt this type of attack. Even if they trace the link back to the consumer who lent his bandwidth it may provide scant information. steve Experience teaches us to be most on our guard to protect liberty when the government's purpose is beneficent. Men born to freedom are naturally alert to repel invasion of their liberty by evil-minded rulers. The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -Louis Dembitz Brandeis, lawyer, judge, and writer (1856-1941) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffix analysis
At 09:17 PM 8/27/2003 -0500, Anonymous wrote: > 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. That's what http://www.cs.dartmouth.edu/~ashubina/google.html is all about. steve - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffix analysis
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]
Re: blackmail / real world stego use
bear wrote: > On Wed, 27 Aug 2003, Ed Gerck wrote: > > >OTOH, it is possible that the dutch man was traced not by a one > >time download of the image but by many attempts to find it, > >since the upload time of the image to the site was not exactly > >known to him and time was of essence. In this case, the required > >tracing capability would NOT need a large capability for packet > >recording and correlation. It would just include finding 100's > >(or 1000's) of identical access occurrences in surfola's incoming > >server traffic, after surfola's server was tagged from the website's > >logs. > > The problem being here access to the website's logs. Getting the logs > via a warrant and due process, No, the website's logs mentioned above belongs to the victim -- who had no problems in fully cooperating with law enforcement. > which seems like a minimal exercise for > a privacy server, is hard to do inside 24 hours. It's much easier to > believe that the FBI is keeping its own logs at hubs, routers, and > switches connected to surfola, thereby eliminating the need for > warrant service. surfola connects upstream to someone, who is tapped before the victim posts the image. Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
