Re: packet traffic analysis

2005-11-01 Thread 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. > A

Re: packet traffic analysis

2005-11-01 Thread Travis H.
> 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

Re: packet traffic analysis

2005-10-31 Thread Travis H.
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

Re: packet traffic analysis

2005-10-31 Thread John Denker
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

Re: packet traffic analysis

2005-10-31 Thread Travis H.
> 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