That's a fairly interesting review, and Skype should be commended for
hiring someone to do it. I hope to see more evaluations from vendors
in the future.
However, I have a couple of suggestions.
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section
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. I
considered doing this with SLIP back before broadband (back when my
friend was my ISP). There are
If you have
to be that confident in your computer security to use the payment
system, it's not going to have many clients.
Maybe the trusted computing platform (palladium) may have something to
offer after all, namely enabling naive users to use services that
require confidence in their own
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
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
