On Tue, 9 Oct 2001, Michael T. Babcock wrote:
> Incidentally, do these attacks apply to traffic analysis of IPSEC
> connections using something like FreeS/WAN?
Yes. It's harder if there is other traffic using the same IPsec
connection, but there might not be.
The FreeS/WAN project is investigating adding small amounts of automatic
padding, to at least obscure the packet sizes some. (The IPsec protocols
already have provisions for this, fortunately.)
It's harder for us to do anything about timing. At the network layer, we
don't have much information about what the application is doing, and we're
reluctant to deliberately delay packets which may not benefit.
Introducing dummy traffic would have to be done with great care and some
kind of adaptive strategy, and we don't have any good ideas about the
details at the moment. Moreover, dummy traffic doesn't really eliminate
this signal path -- it just adds background noise, which makes things
harder for the eavesdropper but not impossible.
The nice thing about the Silicon Defense technique (assuming I've
understood it correctly -- I haven't yet examined their code) is that it
actually eliminates the signal path completely, by fitting the real
traffic into the dummy traffic. At first glance, I don't think there's
any reasonable general-purpose way for the network layer to do that.
Given that the only really touchy area is passwords, which are a tiny
fraction of all network traffic, it seems reasonable to seek long-term
solutions at or near the application layer, where it's easier to recognize
the situations needing special attention. In particular, it's really dumb
to have passwords going across a character at a time, when there is no
character-by-character interaction involved.
Henry Spencer
henry@xxxxxxxxxxxxx
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
