Re: traffic analysis

[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]