Re: [Security] [patch] random: make get_random_int() more random

[Willy Tarreau]

On Fri, May 15, 2009 at 03:47:17PM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Thu, 14 May 2009, Jake Edge wrote:
> > >
> > > It seems like this should be queued up for stable, yes?  I just 
> > > saw the 2.6.29.4 review patches go out, but this wasn't part of 
> > > it ...
> > 
> > Well, I was hoping to maybe have actual timing numbers from some 
> > better hash, in case Matt can make one that is efficient enough. 
> > So I committed the randomness improvement as a clear _improvement_ 
> > over what we had, but it may not be the final version.
> 
> yep, it was just a quick hack really. If someone can do a stronger 
> hash that also happens to be faster i guess we all will be happy 
> campers. The performance figures showed room for improvement - how 
> well are those hashes optimized? Many thousands of cycles ... is 
> that really justified?

In fact we must keep in mind that those hashes produce far more data
than we need and we're throwing that data to the bin on every call.
If we use SHA1, we get 160 bits. We should save them and return them
by 5 packets of 32 bits, then only call SHA1 once every 5 calls. That
way, we get one slower exec every 5 calls but faster calls on average.

And if we can't get a good hash to be fast enough, let's make this
configurable. Most of us won't ever care about the strength of the
hash. People concerned about security won't care about the slower
hash. If we set the slower hash by default and have a tunable for
it, everyone will have the solution that fits them.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/