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.

perhaps one optimization is to stop encrypting when switching on the

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.

Reply via email to