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. Ah,

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.
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

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, you

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