Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Gregory Baudet
>3. An approved DRBG, thus forming a chain of at least two DRBGs; >the initial DRBG in the chain SHALL be seeded by an approved >NRBG or an approved entropy source. A DRBG instantiation may >seed or reseed another DRBG instantiation, but SHALL NOT reseed > >itse

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Stephan Mueller
Am Montag, 28. April 2014, 10:23:50 schrieb Theodore Ts'o: Hi Theodore, > > I am not too convinced of RDRAND due to the lack of usable source code > > (i.e. source code that I can build myself). But that is my personal taste > > :-) > The problem is the FIPS validation would presumably require ob

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Theodore Ts'o
On Mon, Apr 28, 2014 at 08:00:19AM +0200, Stephan Mueller wrote: > > However, given that we're reseeding once a minute (or as needed), it's > > actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a > > DRBG is forbidden to reseed itself automatically). > > To be honest, I do not read

Re: [RFC] /dev/random for in-kernel use

2014-04-27 Thread Stephan Mueller
Am Sonntag, 27. April 2014, 20:19:41 schrieb Theodore Ts'o: Hi Theodore, > On Sun, Apr 27, 2014 at 08:49:48PM +0200, Stephan Mueller wrote: > > With the heavy update of random.c during the 3.13 development, the > > re-seeding of the nonblocking_pool from the input_pool is now prevented > > for a

Re: [RFC] /dev/random for in-kernel use

2014-04-27 Thread Theodore Ts'o
On Sun, Apr 27, 2014 at 08:49:48PM +0200, Stephan Mueller wrote: > With the heavy update of random.c during the 3.13 development, the re-seeding > of the nonblocking_pool from the input_pool is now prevented for a duration > of > random_min_urandom_seed seconds. Furthermore, the nonblocking_pool