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&fingerprint=on&exact=on
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

You will find a couple of references on traffic analysis
applied to
anonymous networks here
http://freehaven.net/an
onbib/

--Anton

-----Original Message-----
From: owner-cryptographymetzdowd.com
[mailto:owner-cryptographymetzdowd.com] 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 majordomometzdowd.com


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On 10/19/06, Leandro Meiners <lmeinersgmail.com> 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." -><-
<URL:http://www.
subspacefield.org/~travis/>
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Hi Leandro,

I am compiling a review paper on traffic analysis as well as
a talk.
They can be found here:

h
ttp://homes.esat.kuleuven.be/~gdanezis/TAIntro.pdf
http://homes.esat.kuleuven.be/~gdanezis/talks/TAIn
tro-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 majordomometzdowd.com

Disclaimer: http
://www.kuleuven.be/cwis/email_disclaimer.htm


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Mon, 23 Oct 2006 11:43:17 +0200, George Danezis
<george.danezisesat.kuleuven.be> wrote:

> Hi Leandro,
> 
> I am compiling a review paper on traffic analysis as
well as a talk.
> They can be found here:
> 
> h
ttp://homes.esat.kuleuven.be/~gdanezis/TAIntro.pdf
> http://homes.esat.kuleuven.be/~gdanezis/talks/TAIn
tro-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.columbi
a.edu/~smb

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Mon, 23 Oct 2006 11:43:17 +0200, George Danezis
<george.danezisesat.kuleuven.be> wrote:

> Hi Leandro,
> 
> I am compiling a review paper on traffic analysis as
well as a talk.
> They can be found here:
> 
> h
ttp://homes.esat.kuleuven.be/~gdanezis/TAIntro.pdf
> http://homes.esat.kuleuven.be/~gdanezis/talks/TAIn
tro-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.columbi
a.edu/~smb

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com