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 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 that in
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 obeying
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
itself.
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
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
