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.