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

["Michael S. Zick" <lkml@morethan.org>]

On Sat May 16 2009, Michael S. Zick wrote:
> On Sat May 16 2009, Eric W. Biederman wrote:
> > Ingo Molnar <mingo@elte.hu> writes:
> > 
> > > * Willy Tarreau <w@1wt.eu> wrote:
> > >
> > >
> > > Bad idea IMHO ...
> > >
> > > It is a bad idea because such sort of tunables do not really help 
> > > the user as those who tweak are a distinct minority.
> > >
> > > Also, having a two-way hack _hinders_ your good idea from being 
> > > adopted for example. Why bother with a faster hash and with using 
> > > the resulting bits sparingly if we can get an 'easy' tunable in and 
> > > can have two sub-par solutions instead of one (harder to implement) 
> > > good solution?
> > >
> > > So tunables are really counter-productive - and this is a pet peeve 
> > > of mine.
> > >
> > > Every time we have such a tunable for something fundamental we've 
> > > not improved the kernel, we've documented a _failure_ in kernel 
> > > design and implementation.
> > >
> > > Sure, we do use tunables for physical constants, limits and other 
> > > natural parameters - and _sometimes_ we just grudingly admit defeat 
> > > and admit that something is really impossible to implement. IMHO 
> > > here we are not at that point yet, at all.
> > 
> > In the lwn comment section there was a suggestion to use a high
> > quality stream cipher (AES?) instead of sha1 or the half md4 thing.
> > Apparently those should be both stronger and faster.
> > 
> > I don't know enough about it except to say that sounds right in
> > principle.
> > 
> > Apparently some of the BSDs do something similar with arc4random.
> > arc4 is old and in some case broken so it is unlikely to make a good
> > choice at this point, but the overall design of a stream cipher
> > that is rekeyed ever 5 minutes seems sound.
> > 
> > Eric
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> 
> And when building for the VIA processors that have the
> hardware rng in the padlock firmware - -
> Let the kernel use that for a high quality RNG.
> 
> Note: This may require a Kbuild tweak to force the via-rng
> driver to be built-in if this solution is selected.
> 
> PS: I have two (different) VIA C7-M machines available for testing.
>

Still getting kernel messages that there isn't a test for the rng - -
One (of many) ways to test the quality is to submit a bit string sample
to the Berlekamp-Massey algorithm; perhaps from repeated calls to the
generation function (it depends on your desired confidence level).

http://en.wikipedia.org/wiki/Berlekamp-Massey_algorithm 

If the solution is greater than a xyz bits long LFSR, the randomness 
is considered "good enough".

Note: The padlock firmware also has a Montgomery multiplier not yet 
exposed by a driver.

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