> Modes that are based on a small window of previous plaintext, such as
> OFB, would be vulnerable too.
My mistake, OFB does not have this property. I thought there was a
common mode with this property, but it appears that I am mistaken.
If it makes you feel any better, you can consider the PRNG
> 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.
> A
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, yo
> I assume that the length is
> explicitly encoded in the legitimate packet. Then the peer for the
> link ignores everything until the next "escape sequence" introducing a
> legitimate packet.
I should point out that encrypting PRNG output may be pointless, and
perhaps one optimization is to stop
Good catch on the encryption. I feel silly for not thinking of it.
> 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
> p
Travis H. wrote:
Part of the problem is using a packet-switched network; if we had
circuit-based, then thwarting traffic analysis is easy; you just fill
the link with random garbage when not transmitting packets.
OK so far ...
There are two problems with this; one, getting
enough random