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,
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
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
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,
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 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
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
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
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
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
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
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
12 matches
Mail list logo