>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
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
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
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
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
Hi,
before I start, please allow me to point out that this email is not a
discussion about entropy. There was already too much such discussion without
any conclusion. This email shall just explore the pros and cons as well as an
implementation of making the logic behind /dev/random available fo
