Messages in this thread | | | From | "Michael S. Zick" <> | Subject | Re: [Security] [patch] random: make get_random_int() more random | Date | Sat, 16 May 2009 09:00:00 -0500 |
| |
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.
Mike
| |