Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers

[Matt Mackall <mpm@selenic.com>]

On Sun, May 07, 2006 at 10:13:50AM -0300, Thiago Galesi wrote:
> >Sure.
> >
> >First, since the existence of /dev/random's entropy accounting scheme
> >is predicated on the assumption that we can break the hash function at
> >will, I'll replace SHA1 with, oh, say, CRC-16. This'll be illustrative
> >until someone has a nice preimage attack against SHA1.
> >
> >Then I'll run my test on one of the various arches where HZ=~100 and
> >we don't have a TSC. Like Sparc?
> >
> >Now all the inputs are easily predictable from anywhere with <10ms
> >ping, with the occassional need to guess between a pair of timer
> >ticks. And since I can calculate preimages of CRC-16, I can now deduce
> >the state of the pool if I can watch some subset of its output, say
> >https session keys I request. And then I can start guessing future
> >outputs and breaking into other people's https sessions.
> >
> >The point of /dev/random is to -survive- SHA1 being broken by never
> >giving out more secrets than we take in.
> 
> OK, here goes...
> 
> 1 - by eliminating feeding enthopy from network cards you are

Keep up, folks, I dropped that position in the very first round of replies.
 
> 2 - some platforms have much better enthropy sources than ethernet (or
> user input), just think hardware rngs, or even the sound card rng
> thing mentioned above

Point?

> 3 - as people said, your example (CRC-16 on specific platfoms) is
> (IMHO) an exxageration.

Yes, CRC-16 was a rhetorical device. MD4 would not have been. HZ=100
is not an exaggeration. Odds are pretty good you have such a Linux box
in the form of a router or such already. This completely invalidates
all the arguments about the hardware making the timing too
unpredictable as it does so on a timescale of microseconds or less.

-- 
Mathematics is the supreme nostalgia of our time.