Wolfgang Rupprecht <wolfgang+gnus20011109T112003@wsrcc.com> writes:
> Would pushing the "would-be entropy" through a crypto-system make it
> non-predictable enough to prevent such attacks?

No.

Here is a gedankenexperiment to explain why.

Imagine that you have a system that can produce 800 possible
outputs. We put the 800 possible outputs through a hash function in
order to obscure them. How many possible outputs are there from the
hash function? Still just 800. You can trivially generate all 800
possible states, hash them, and search the output space.

The issue is one of completely known or "nearly completely known"
information. Even though you might not be able to get the exact timing
of the network event being mixed in, you might know more than enough
to reduce the space of possible timing register outputs to only a few
million, which is pretty small to search.

Now it is true that the way we mix entropy into the pool using this as
a lever is not extremely likely. However, "not extremely likely" is
not a very comforting thing for someone with a crypto background,
especially when stuff like this ends up in embedded hardware that is
very expensive to remove from the field or update.

Consider, for example, the recent attack that broke all of the ATM
machines that run with a particular IBM crypto processor. It is
designed not to let you get at the keys, but it turns out that you can
push it into a mode where a fairly limited space of keys could be used
to bootstrap the extraction of the secure keys, and that limited
keyspace is sufficiently small to make searching it practical.

Anyway, I'm happy enough if, as has been repeatedly suggested, the
configuration of the network hardware as an entropy source forcefully
warns the user.

--
Perry E. Metzger		perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/