packet traffic analysis
John Denker
jsd at av8n.com
Mon Oct 31 09:54:48 EST 2005
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.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list