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:28:16 -0500 |
| |
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/ > >
| |