packet traffic analysis

[Travis H.]

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

During lulls, you are constantly sending chaff packets.  On average,
you're halfway through transmitting a chaff packet when you want to
send a real one.  The system has to wait for it to finish before
sending another.  QED.

> Ah, but if you generate unequal-length packets then they are
> vulnerable to length-analysis, which is a form of traffic analysis.

I'm talking about a stream, with packets embedded in it.  For
circuit-switched circuits, this is no problem.  For a packet-switched
network, you must packetize the stream, which is unrelated to the
packets embedded in the stream.

This is somewhat inefficent, which is why I suggested that it is more
applicable ot something like PPP, SSH, or OpenVPN links, which are
already virtual circuits.  This is a fair criticism, but just think of
the number of such circuit/packet conversions when someone uses a TCP
virtual circuit over packet-based IP over an analog POTS link, which
is itself a virtual circuit that is packetized and sent over a circuit
(long-haul wirepair or fiber) in the telco network.

If you explain to me how an eavesdropper can tell where plaintext
packet begins or ends, then I'll agree with you that it is indeed
vulnerable to length analysis.

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

That might or might not be a problem.  With ECB, it's vulnerable to
analysis (chaff is constant, so encryption of it is constant).  With
some modes, the amount you can transmit is limited (e.g. CTR mode). 
Modes that are based on a small window of previous plaintext, such as
OFB, would be vulnerable too.  It could very well be that it's a bad
idea to send a lot of constant plaintext under other modes, as well. 
For example, if most of the data is constant, then you have a close
approximation of known-plaintext.

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

It's not necessary to run a PRNG on the receiver.  You just have to be
able to tell when you're looking at random data, or an encrypted
version of an escape sequence and a valid packet, which can be
recognized, as per your point 4a.  If you find that it's not a
legitimate packet, you treat it as PRNG data, and start looking for
the encrypted escape sequence.  However, with a 32-bit escape
sequence, the chances of getting such a false positive are low.

I personally think sending encrypted versions of constant data under
the same key you use for real data is not crazy, but somewhat
imprudent.  Do you know what the unicity distance is?  Have you read
of attacks that require a large amount of ciphertext encrypted under
the same key?
--
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