Re: Traffic Analysis References

2006-10-25 Thread Steven M. Bellovin
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

2006-10-23 Thread George Danezis
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=indexsearch=lmeiners%40gmail.comfingerprint=onexact=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

2006-10-22 Thread Travis H.

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, ATT'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. --
URL:http://www.subspacefield.org/~travis/
GPG 

Re: Traffic Analysis in the New York Times

2005-05-24 Thread Adam Shostack
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=1274414400en=9ff3763213102706ei=5090partner=rssuserlandemc=rss

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


Re: traffic analysis

2003-08-29 Thread David Wagner
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

2003-08-29 Thread Anonymous
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

2003-08-29 Thread Ryan Lackey
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

2003-08-29 Thread kent
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

2003-08-29 Thread John S. Denker
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 (was: blackmail / stego)

2003-08-28 Thread David Honig
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

2003-08-28 Thread An Metet
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

2003-08-28 Thread John S. Denker
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 of phone calls?

2003-07-12 Thread Don Davis
 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]


Re: traffic analysis of phone calls?

2003-07-12 Thread Vin McLellan
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]