packet traffic analysis

[Travis H.]

Good catch on the encryption.  I feel silly for not thinking of it.

> If your plaintext consists primarily of small packets, you should set the MTU
> of the transporter to be small.   This will cause fragmentation of the
> large packets, which is the price you have to pay.  Conversely, if your
> plaintext consists primarily of large packets, you should make the MTU large.
> This means that a lot of bandwidth will be wasted on padding if/when there
> are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's
> the price you have to pay to thwart traffic analysis.

I'm not so sure.  If we're talking about thwarting traffic on the link
level (real circuit) or on the virtual-circuit level, then you're
adding, on average, a half-packet latency whenever you want to send a
real packet.  And then there's the bandwidth tradeoff you mention,
which is probably of a larger concern (although bandwidth will
increase over time, whereas the speed of light will not).

I don't see any reason why it's necessary to pay these costs if you
abandon the idea of generating only equal-length packets and creating
all your chaff as packets.  Let's assume the link is encrypted as
before.  Then you merely introduce your legitimate packets with a
certain escape sequence, and pad between these packets with either
zeroes, or if you're more paranoid, some kind of PRNG.  In this way,
if the link is idle, you can stop generating chaff and start
generating packets at any time.  I assume that the length is
explicitly encoded in the legitimate packet.  Then the peer for the
link ignores everything until the next "escape sequence" introducing a
legitimate packet.

This is not a tiny hack, but avoids much of the overhead in your
technique.  It could easily be applied to something like openvpn,
which can operate over a TCP virtual circuit, or ppp.  It'd be a nice
optimization if you could avoid retransmits of segments that contained
only chaff, but that may or may not be possible to do without giving
up some TA resistance (esp. in the presence of an attacker who may
prevent transmission of segments).
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com