Re: Traffic Analysis References
On Mon, 23 Oct 2006 11:43:17 +0200, George Danezis <[EMAIL PROTECTED]> wrote: > Hi Leandro, > > I am compiling a review paper on traffic analysis as well as a talk. > They can be found here: > > http://homes.esat.kuleuven.be/~gdanezis/TAIntro.pdf > http://homes.esat.kuleuven.be/~gdanezis/talks/TAIntro-prez.pdf > > These will soon be expanded (by January) since they are going to be > presented as a talk to the CCC (Berlin) as well as a book chapter. > > If anyone with material on the subject can give me more pointers I would > be most grateful. > Very nice summary. I'd add a few things. First, on a topical note, Hewlett-Packard obtained call records of various people, including members of its own board and reporters for major publications. In other words, there's a private sector threat. Second, in many cases the beauty of traffic analysis is that it can be done after the fact. Phone companies don't keep recordings of all conversations; they do keep billing data. In a legal vein, in some jurisdictions (i.e., the U.S.) traffic analysis warrants are *much* easier to obtain than wiretaps. Philosophically, the distinction is because traffic analysis data (and in particular telephone calling records) is information that was voluntarily given to a third party, the phone company. There is thus no expectation of privacy. Again, this is U.S. law; your jurisdiction's law may vary. Finally, you should cite the Zendian problem, since it's a classic published training exercise. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Traffic Analysis References
Hi Leandro, I am compiling a review paper on traffic analysis as well as a talk. They can be found here: http://homes.esat.kuleuven.be/~gdanezis/TAIntro.pdf http://homes.esat.kuleuven.be/~gdanezis/talks/TAIntro-prez.pdf These will soon be expanded (by January) since they are going to be presented as a talk to the CCC (Berlin) as well as a book chapter. If anyone with material on the subject can give me more pointers I would be most grateful. Yours, George Leandro Meiners wrote: > Dear list, > > Can anybody point me to any good references regarding traffic analysis? > > regards, > > Leandro. > > -- > Leandro Federico Meiners > > GnuPG key fingerprint: > 7B98 C0F5 42A3 2BEE 44AF > 9D19 936F 5957 27DF AE74 > > GnuPG-Key: > http://pgp.mit.edu:11371/pks/lookup?op=index&search=lmeiners%40gmail.com&fingerprint=on&exact=on > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Traffic Analysis References
On 10/19/06, Leandro Meiners <[EMAIL PROTECTED]> wrote: Can anybody point me to any good references regarding traffic analysis? This is the only interesting page I found on it: http://guh.nu/projects/ta/safeweb/safeweb.html There are some historical incidents that are sufficiently old to be unclassified: For example, the Japanese left their normal morse operators behind when setting sail for Pearl Harbor. They continued to send transmissions as though they were still in Japan's waters. Morse operators are fairly identifiable by their rhythm and idiosyncrasies, known collectively as their "fist". It's just like any other behavior performed subconsciously, like typing or signing your name; at first there's a lot of variation, and later it becomes fairly fixed and potentially identifying. Also during WWII, a year before D-Day, the Allies in Scotland created a radio net that purported to be a [nonexistent] 4th Army, ostensibly to feint towards southern Norway. The purpose behind this was to further dilute Axis forces, to keep them far enough away to be unable to participate around Normandy (there were, obviously, numerous deception operations around D-Day). This last bit is well documented in "The Codebreakers", which also has numerous entries in its appendix for Traffic Analysis. I suspect that in many instances where traffic analysis was useful, it was necessary to make (or learn) certain assumptions about typical traffic patterns; that is, orders come from the top and are disseminated down the military hierarchy, etc.; that requests for supplies, battle damage assessments, and other feedback flows up from the front-line troops to the logistic units or field commanders; that traffic increases as one approaches a major military operation, etc. In other words, it's context-specific, and may resist generalization into easily-remembered axioms. Also, the mixmaster and cypherpunk remailers, AT&T's crowds, and the onion-routing groups, probably have some papers considering various traffic analysis and correlation attacks against those systems since they are encrypted inside the mixers. One thing I have been interested in is the security of typical plaintext Internet protocols when "secured" with SSL/TLS/IPSec. If they don't do any padding, then the length of each step of the protocol is effectively given away; just count how much data passes to the recipient before data starts flowing in the opposite direction. Also, there is timing information, and it is fairly well preserved even across the Internet (see the timing side channel attacks against SSL). Even if there is padding, which is basically wasted bandwidth, it may still be possible to discern information. I've been thinking about this, and I am not sure how to entirely avoid it without running into other problems. For example, Unix's configuration files and application-level TCP/IP protocols are very easy to interpret and troubleshoot thanks to their human-readable strings. The typical encrypted protocol uses non-textual, constant-length messages, which can make it difficult to extend without introducing incompatibilities (or even making different responses different lengths again, the worst of both worlds). One doesn't typically need very extensive decoding algorithms in order to make the plaintext data human-readable, which is good because those decoding libraries are also processing data from remote (untrusted) entities and form part of the attackable surface, and have proven to be security holes on more than one occasion. One alternative I came up with is to send the entire catalog of possible responses at the beginning of the transmission, then refer to them by a fixed-length index. This would be a lot of overhead in many cases. Another alternative is to have a standard catalog, something like an MIB, that may be cached between invocations. Nevertheless, there are many times during a protocol that you wish to dynamically construct a response without knowing it a priori; it would seem difficult to deal with those cases in any other way. These approaches could be implemented simultaneously, and perhaps one only needs to pad when sending variable-length messages, so that "normal" common messages don't incur any overhead (at the cost of fixed-length and variable-length messages being distinguishable sets, but not distinguishable individually). In this way it is similar to what cryptologists were doing with telegraph codebooks, which encoded standard phrases in relatively similarly sized units, but had to spell out anything not in the codebook using many codes (each signifying one letter or part of a word). If you come across any other links, please let me know as I'd like to add them to my page on side-channel attacks: http://www.subspacefield.org/~travis/side_channel_attacks.html -- "It's not like I'm encrypting... it's just that my communications developed a massive entropy deficiency." -><- http://www.subspacefield.org/~travis
RE: Traffic Analysis References
> Dear list, > > Can anybody point me to any good references regarding traffic > analysis? > > regards, > > Leandro. Google Scholar has a pretty good academic paper search engine which ranks the papers in order of the number of citations they've received: http://scholar.google.com/scholar?q=traffic+analysis Regards, Jeremy A. Hansen, MS, CISSP Director of Security RAIR Technologies, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Traffic Analysis References
You will find a couple of references on traffic analysis applied to anonymous networks here http://freehaven.net/anonbib/ --Anton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Meiners Sent: October 19, 2006 2:09 PM To: Cryptography Subject: Traffic Analysis References Dear list, Can anybody point me to any good references regarding traffic analysis? regards, Leandro. -- Leandro Federico Meiners GnuPG key fingerprint: 7B98 C0F5 42A3 2BEE 44AF 9D19 936F 5957 27DF AE74 GnuPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=index&search=lmeiners%40gmail.com&fin gerprint=on&exact=on - 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: Traffic Analysis in the New York Times
On Mon, May 23, 2005 at 02:49:03PM -0400, Adam Shostack wrote: | On Mon, May 23, 2005 at 11:46:25AM -0400, Perry E. Metzger wrote: | | | | The original article has some nice diagrams, but unfortunately, | | because of the NY Times' policies, the article won't be online in a | | few days. | | The times is trying to address this for RSS readers. Aaron Swartz has | some code http://nytimes.blogspace.com/genlink | | This link should last: | http://www.nytimes.com/2005/05/22/weekinreview/22kola.html?ex=1274414400&en=9ff3763213102706&ei=5090&partner=rssuserland&emc=rss | Speaking of which, in the star graph, it seems there are lots of "cut off" or stub lines. Does anyone understand what the graph is supposed to be showing? Its very pretty and all.. Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Traffic Analysis in the New York Times
On Mon, May 23, 2005 at 11:46:25AM -0400, Perry E. Metzger wrote: | | The original article has some nice diagrams, but unfortunately, | because of the NY Times' policies, the article won't be online in a | few days. The times is trying to address this for RSS readers. Aaron Swartz has some code http://nytimes.blogspace.com/genlink This link should last: http://www.nytimes.com/2005/05/22/weekinreview/22kola.html?ex=1274414400&en=9ff3763213102706&ei=5090&partner=rssuserland&emc=rss - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis
On 08/28/2003 04:26 PM, David Wagner wrote: > > Are you sure you understood the attack? Are you sure you read my original note? > The attack assumes that communications links are insecure. I explicitly hypothesized that the links were encrypted. The cryptotext may be observed and its timing may be tampered with, but I assumed the attackers could not cut through the encryption to get at the plaintext. > The *transmission* from Alice may adhere to a fixed schedule, but > that doesn't prevent the attacker from introducing delays into the > packets after transmission. Fine. So far the timing doesn't tell us anything about the behavior of Alice, just the behavior of the attacker. > For instance, suppose I want to find out who is viewing my web site. > I have a hunch that Alice is visiting my web site right this instant, > and I want to test that hunch. I delay Alice's outgoing packets, > and I check whether the incoming traffic to my web contains matching > delays. I explicitly said that if some endpoints are not secure, Alice suffers some loss of privacy when communicating with such an endpoint. Here DAW is playing the role of attacker, and is mounting an attack that combined traffic analysis with much more powerful techniques; he is assuming he "owns" the endpoint or otherwise can see through the crypto into the plaintext. Let us not confuse "traffic analysis" issues with "anonymity" issues. I explicitly said that traffic analysis was not the only threat to be considered. To say it another way: The US ambassador in Moscow is not trying to remain anonymous from the US ambassador in Riyadh; they just don't want the opposition to know if/when/how-often they talk. = I described a certain model based on certain hypotheses. Many people have responded with attacks on different models, based on different hypotheses. Some have frankly admitted contradicting me without having bothered to read what I wrote. I'm not going to respond to any more of these ... except to say that they do not, as far as I can see, detract in any way from the points I was making. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis
On Thu, Aug 28, 2003 at 08:06:07AM -0400, John S. Denker wrote: [...] > 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. Different models. You state in your previous note that it is important that all the endpoints be trusted. Traffic between military bases, embassies etc all involve trusted endpoints. A public website is intrinsically not a trusted endpoint. Moreover, addition of "cover browsing" by the hub to random websites doesn't add any significant protection if the goal is to provide real-time access. -- Kent Crispin "Be good, and you will be [EMAIL PROTECTED],[EMAIL PROTECTED] lonesome." p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis
Quoting John S. Denker <[EMAIL PROTECTED]>: > 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). Scheduled communications are secure against passive observers, but not an attacker who can implement the "clogging attack" mentioned in Adam's paper. Selectively DoSing various end-users to see if the network traffic continues, either at the endpoints or by doing a binary search of routing nodes, would definitely be possible for a national government or slightly competent script kiddie. Persistent interactive communications with low-latency require some form of cascade (either synchronization or DC-style) such that attacking nodes attacks the system. I think the ultimate solution is to rearchitect systems to not require interactive anonymous communications, and implement less interactive long term distribution, which can be effectively synchronized. Software agents acting largely autonomously on infrequent orders, ideally executing in some kind of tamper-resistant environment, is the best chance for high security in a deployable system. There really is no fundamental need for high bandwidth interactive communications with low latency in most interesting applications, it's just how traditional client-server and p2p software has been designed so far. -- Ryan Lackey [RL960-RIPE AS24812] [EMAIL PROTECTED] +1 202 258 9251 OpenPGP DH 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis
John S. Denker writes: > 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). Suppose you are engaged in a video conference with another party via an anonymous real-time communications network. Don't you agree that you cannot remain anonymous to that party, if they have the power to insert arbitrary delays into communication links? How could you prevent frame dropouts when she delays your link into the anonymizing cloud? You can insert nulls, or get the cloud to do it for you, but it will be obvious to the recipient that your video has stopped. This again demonstrates that you cannot remain anonymous with realtime communication against an adversary who can corrupt selected endpoints and who can insert traffic delays. If you disagree, explain how you will counter this attack. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis
On Thu, Aug 28, 2003 at 08:06:07AM -0400, John S. Denker wrote: > A couple of people wrote in to say that my remarks > about defending against traffic analysis are "not > true". As 'proof' they cite [1] > > which proves nothing of the sort. I agree it doesn't prove anything directly. However if your proposed scheme falls to one or more of the traffic attacks we detail then that conversely demonstrates that your scheme is also not ideally secure. With reference to your previous post (which I had not read until now), it's unclear on the datahaven. You posit that it exists and is trustworthy, but you seem to be working to a weaker threat-model than we explored, namely your propose a user trust a single trusted entity. We explored the more interesting case where the user can choose to trust some set of nodes operated by different entities and the objective is to design a system such that you still get good anonymity as long as some k of n of the nodes are not rogue and hostile to your anonymity. Some of the attacks we examined discuss traffic analysis attacks inside the anonymous network. But some consider the anonymous network as a black box with perfect properties (this model seems to be similar to yours.) Of those the attack where the user disrupts an input and observes disruption in the output appear to work. ie. say there are two users A and B browsing the web via this idealised system; if I disrupt (DoS / crash etc) user A's network connection and one of the browsing streams abruptly stops, I have some statistical information suggesting that browsing stream belonged to real user A. Now this is not really a criticism of the anonymous network as such, but a problem particular to browsing -- the system requires observable events to happen on the internet as the information is coming from computers outside of the anonymity system. Ideas about how to combat these kinds of problems are: - mimic functions - to have some agent continue the browsing when the user's connection is disrupted. However the limitation here is that good user browsing mimic functions are likely hard. - another is cacheing (ZKS Freedom did this) and this tends to help because some of the content is coming from the cache and so only observable to a rogue node that happens to be the exit (and cacheing) node. - another is moving the content inside the anonymous network; ie trying to host the content in a p2p network that also provides anonymity. For example freenet tries to do this kind of thing. but overall I have not seen any anonymous system design to date that comes close to providing interactive anonymity against a threat-model of retaining security with k of n honest nodes with k < n (!) (and where n != 1) Even a single compromised node (eg the exit node) plus ability to observe or remotely influence network behavior of target users seems to break most systems. I restrict that comment to system where the content is outside of the anonymous network; systems like freenet where the content is inside the system probably require a different threat model, because there are a number of new threats still I think would be vulnerable to similar attacks from hostile insiders (and here anyone can usually be an insider as it is a p2p system). New threats in a p2p context include: 1. attacker's ability to discover what content a given node is serving 2. attacker's ability to discover all nodes serving a given file 3. attacker's ability to damage file integrity 4. attacker's ability to flood the network with files (pure volume DoS) 5. attacker's ability to flood the network with bogus files and trick downloaders and p2p nodes into downloading and sharing the bogus files in place of genuine content 6. search term privacy 7. attacker's ability to flood the search mechanism attack 1 particularly seems hard to defend against. about the padding scheme: > 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 is vulnerable to insider attack because the padding is not end-to-end if I read your description correctly. Wei Dai has an attack on that scheme which we describe in the paper and uses it to argue for end-to-end padding. (Note Pipenet is about internal traffic, it does not propose external traffic, though presumably this could be added at the cost of the discussed loss of security). But in fact if I understand you are talking about a single anonmity-providing node so you have to trust that node to terminate the padding. So I think the case is more that what you proposed co
Re: traffic analysis
John S. Denker wrote: >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. Are you sure you understood the attack? The attack assumes that communications links are insecure. The *transmission* from Alice may adhere to a fixed schedule, but that doesn't prevent the attacker from introducing delays into the packets after transmission. For instance, suppose I want to find out who is viewing my web site. I have a hunch that Alice is visiting my web site right this instant, and I want to test that hunch. I delay Alice's outgoing packets, and I check whether the incoming traffic to my web contains matching delays. If so, it's a good bet that Alice has a connection open to my site. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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: traffic analysis
Jim McCoy writes: > While IANL, it seems that the whole anonymity game has a flaw that > doesn't even require a totalitarian regime. I would direct you to the > various laws in the US (to pick a random example :) regarding > conspiracy. Subscribing to an anonymity service might not become > illegal, but if anyone in your "crowd" was performing an illegal action > you may be guilty of conspiracy to commit this action. You were > explicitly trying to assist someone to avoid lawful detection of > illegal activity, therefore you are in danger of being charged with > conspiracy to commit the illegal act (even if the overt act was never > successfully completed, which is where things could get really surreal > for the remailer/crowds/proxy groups.) It is also worth noting that the > burden of proof in a conspiracy trial is substantially lower than for > other cases... This is from http://www.lawnerds.com/testyourself/criminal_rules.html: A person is guilty of conspiracy if: - Two or more people agree to commit a crime, and - the people intended to enter into the agreement, and - at least one of the conspirators commits some overt act (such as some act of preparation) that furthers the conspiracy. I don't see how using an anonymity service, or any internet service whose activities are not forbidden by law, could fall into this category. You would fail to achieve the first element of the crime, the agreement to commit a crime. Now, if it were made illegal to use an anonymizing service then you might also be charged with conspiracy, if you used it. But the mere fact that people might use the service to commit crimes does not imply that uninvolved users have agreed to commit a crime. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis (was: blackmail / stego)
At 01:01 PM 8/27/03 -0700, Jim McCoy wrote: >While IANL, it seems that the whole anonymity game has a flaw that >doesn't even require a totalitarian regime. I would direct you to the >various laws in the US (to pick a random example :) regarding >conspiracy. Subscribing to an anonymity service might not become >illegal, but if anyone in your "crowd" was performing an illegal action >you may be guilty of conspiracy to commit this action. Ok, so you have a EULA in which you prohibit "offensive" behavior. A crowd-member might violate this, but any "chaff" crowd-member would have a legal defense ---"Hey, I used the foobar service to avoid hackers finding my IP, its not my fault if someone threatened the king" A real police state would just Tomahawk the servers. After rubber hosing the operators. Anything less than a Total Police State would have to acknowledge innocent subscribers. Kinda like (ca. 1980) yeah, I have a cell phone, its because I am on the road ---I'm not a pharmdealer, even if half the carrier's traffic is dubious. Or, moving into this century, "yeah, I use KaZaa++, but its to download unrecognized indie bands, not MetalliMadonna" (assuming K++ were anonymous..) Of course, its becoming easier and easier to be a total police state.. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis (was: blackmail / stego)
At 01:01 PM 8/27/2003 -0700, Jim McCoy wrote: While IANL, it seems that the whole anonymity game has a flaw that doesn't even require a totalitarian regime. I would direct you to the various laws in the US (to pick a random example :) regarding conspiracy. Subscribing to an anonymity service might not become illegal, but if anyone in your "crowd" was performing an illegal action you may be guilty of conspiracy to commit this action. You were explicitly trying to assist someone to avoid lawful detection of illegal activity, therefore you are in danger of being charged with conspiracy to commit the illegal act (even if the overt act was never successfully completed, which is where things could get really surreal for the remailer/crowds/proxy groups.) It is also worth noting that the burden of proof in a conspiracy trial is substantially lower than for other cases... I too ANAL, but I think the prosecution would have to prove that you knew or should have known that your system was being used specific illegal acts. Just knowing that someone "might" use your link to illegal purposes is insufficient. steve "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." --President James Madison (1751-1836) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis (was: blackmail / stego)
On Wednesday, August 27, 2003, at 10:12 AM, John S. Denker wrote: *) Anonymity means They can't prove you're guilty. But it also means you can't prove you're innocent. A sufficiently totalitarian regime will require everyone to be able to prove their innocence at all times. Subscribing to an anonymity service would therefore be automatically illegal. While IANL, it seems that the whole anonymity game has a flaw that doesn't even require a totalitarian regime. I would direct you to the various laws in the US (to pick a random example :) regarding conspiracy. Subscribing to an anonymity service might not become illegal, but if anyone in your "crowd" was performing an illegal action you may be guilty of conspiracy to commit this action. You were explicitly trying to assist someone to avoid lawful detection of illegal activity, therefore you are in danger of being charged with conspiracy to commit the illegal act (even if the overt act was never successfully completed, which is where things could get really surreal for the remailer/crowds/proxy groups.) It is also worth noting that the burden of proof in a conspiracy trial is substantially lower than for other cases... Jim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis (was: blackmail / stego)
From: "John S. Denker" <[EMAIL PROTECTED]> > It is true that if you design an "anonymity" system > under the assumption that the opposition doesn't > have enough resources to perform traffic analysis, > you'll be taken to the cleaners if the opposition > does have such resources. I think it's likely that an anonymity server was given special attention by the FBI. If the story's accurate this guy probably put himself at greater risk by using one. > There exist well-known techniques for greatly > reducing the effectiveness of traffic analysis. > > A scenario of relevance to the present discussion > goes like this: The crook demands a text message sent to a widely-carried newsgroup. This can be noted down in an internet cafe while viewing it via google. To say nothing of the fact that distribution of the card secret is desirable. Risk of apprehension at an ATM could be reduced (at a cost in other risks) by manufacturing numerous cards and posting them (smartly presented) to random people as a supposed offer. Your card has been approved - withdrawals from your account are interest free for the first month. The flood of people emptying ATMs over a wide area should keep Plod busy. Or demo one card in a cut+choose manner and sell the rest to a crook who doesn't know you. He then carries the risk of visiting ATMs (and the weight of e200,000). The sum involved is funny. It's not enough to be a once-in-a-lifetime big crime unless he's trying to get out (once) from e150,000 debt. But what do I know ? I'm still working. -- ## # Antonomasia ant notatla.org.uk # # See http://www.notatla.org.uk/ # ## - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis of phone calls?
Don Davis <[EMAIL PROTECTED]> writes: >with similar import, here's cringely's article on insecure CALEA >workstations: A friend of mine who used to work for a large telco ended up being delegated to attend some of the CALEA meetings. He reports that the FBI were totally unable to comprehend that if they built a system full of easily-accessible backdoors (pushbutton access to anything anytime), anyone with the necessary know-how could also use those backdoors, and since the CALEA monitoring system didn't appear to have been designed with security in mind (and as Cringely's article points out, that obviously got carried through to the final design), it would be possible to watch the watchers. Sort of like assuming that when you shoot at the bad guys they go down, but when they shoot back the bullets bounce off. (I think this was a manifestation of a generic problem with nontechnical decision-makers, the FBI has very clueful technical people, but the ones who got sent to the CALEA meetings were nontechnical people armed with wish- lists rather than techies armed with clues). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis of phone calls?
At 11:21 AM 7/12/03 -0400, Don Davis wrote: > It often does not lie behind a firewall. Heck, it > usually doesn't even lie behind a door. It has a direct > connection to the Internet because, believe it or not, > that is how the wiretap data is collected and transmitted." I believe the CALEA specs call for the data to be encrypted however. The sophisticated spook/cartel also gets payphone logs and does geographic matching. How much does a free-lance counter-intel person make in Columbia? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis of phone calls?
Personal (Use it if you'd like, but keep me out of it.) Steve Bellovin wrote: Slightly off-topic, but a reminder of the sort of thing that ordinary crypto doesn't hide. http://www.silicon.com/news/59-51/1/5093.html?rolling=2 IT Myths: Colombian drugs gang's mainframe-assisted assassinations? Reminds me of a Supercomputer system admin I ran across in California in the mid-1980s -- a part time Deputy Sheriff -- who (at the request of a California state LEA, and with the approval of his boss) was banging away at the DES-encrypted records of a guy, alleged to be a bookkeeper or financial analyst for a Columbia drug cartel, who had been arrested in California. The story he told me was that the Deputy had been asked to try to brute-force the encryption on the file after the NSA and DEA had refused to attempt it. Using free cycles on his corporate machine, he was into the project for a couple of months when a guy from the NSA showed up and convinced his boss that his effort was counterproductive to national security -- apparently because it threatened the reputation of DES. At the time, I was more impressed that the Columbian was using a PC crypto package that apparently did not have an operational weaknesses that was then common in almost all commercial encryption packages for PCs. Hope all is well for you and yours. _Vin - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: traffic analysis of phone calls?
> Slightly off-topic, but a reminder of the sort of thing that > ordinary crypto doesn't hide. > > http://www.silicon.com/news/59-51/1/5093.html?rolling=2 > > IT Myths: Colombian drugs gang's mainframe-assisted assassinations? > Did drugs barons really use multi-million pound systems to see who > was grassing to informants...? with similar import, here's cringely's article on insecure CALEA workstations: - don davis http://www.pbs.org/cringely/pulpit/pulpit20030710.html "Not only can the authorities listen to your phone calls, they can follow those phone calls back upstream and listen to the phones from which calls were made. They can listen to what you say while you think you are on hold. This is scary stuff. "But not nearly as scary as the way CALEA's own internal security is handled. The typical CALEA installation on a Siemens ESWD or a Lucent 5E or a Nortel DMS 500 runs on a Sun workstation sitting in the machine room down at the phone company. The workstation is password protected, but it typically doesn't run Secure Solaris. It often does not lie behind a firewall. Heck, it usually doesn't even lie behind a door. It has a direct connection to the Internet because, believe it or not, that is how the wiretap data is collected and transmitted." - - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
