packet traffic analysis

[John Denker]

In the context of:

 >>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.

Travis H. wrote:

> 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. 

I very much doubt it.  Where did that factor of "half" come frome.

> 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 

Ah, but if you generate unequal-length packets then they are
vulnerable to length-analysis, which is a form of traffic analysis.
I've seen analysis systems that do exactly this.  So the question is,
are you trying to thwart traffic analysis, or not?

> I should point out that encrypting PRNG output may be pointless, 

*is* pointless, as previously discussed.

> and
> perhaps one optimization is to stop encrypting when switching on the
> chaff. 

A better solution would be to leave the encryption on and use constants
(not PRNG output) for the chaff, as previously discussed.

> Some minor details
> involving resynchronizing when the PRNG happens to

The notion of synchronized PRNGs is IMHO crazy -- complicated as well as
utterly unnecessary.