Richard wrote: > (I'm tempted to try this with /dev/random only on Unix... do I remember it > right, that it blocks for a while after every 8 byte chunk on some Unixen?)
Many but not all /dev/random sources will block to fulfill the requested entropy if sufficient isn't in the gathering pool already. (it's not quite that simple but that's the gist of it). Some but not most /dev/urandom sources will do the same. Later kernels are better than older ones in general. I'm not aware of a kernel that limits reads to 8 bytes at a time, although there usually is a single read size maximum. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Richard Levitte [mailto:[email protected]] Sent: Tuesday, 3 April 2018 11:29 PM To: [email protected] Subject: Re: [openssl-project] Entropy seeding the DRBG In message <[email protected]> on Tue, 3 Apr 2018 12:52:50 +0000, "Salz, Rich" <[email protected]> said: rsalz> I had not realized that we just increased the "entropy" rsalz> requirements by 50%, from 256 to 384. The original DRBG rsalz> submission that I did only required 128 bits. I think that is rsalz> wrong, and I think the PR that did it (#5503) should be reverted. rsalz> rsalz> I am concerned that we are trying to meet requirements that we rsalz> really don't have. The original code was a huge improvement. rsalz> rsalz> Requiring 384 bits of random seed is silly. I think it is rsalz> ridiculous. One way or another we HAVE to fix that before the rsalz> release. rsalz> rsalz> Thoughts? FYI, here's the magic number that lies behind this: : ; git grep RAND_DRBG_STRENGTH ... include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH 256 The requirement change from 128 to 256 happened with this commit: commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9 Author: Kurt Roeckx <[email protected]> Date: Sun Feb 18 19:16:13 2018 +0100 Switch the DRBGs from AES-128-CTR to AES-256-CTR Reviewed-by: Dr. Matthias St. Pierre <[email protected]> GH: #5401 And then there's this one, which did the added 50%: commit 2a70d65b99e1f2376be705d18bca88703b7e774a Author: Kurt Roeckx <[email protected]> AuthorDate: Sat Mar 3 23:19:03 2018 +0100 Commit: Kurt Roeckx <[email protected]> CommitDate: Sun Apr 1 21:11:26 2018 +0200 Make sure we use a nonce when a nonce is required If a nonce is required and the get_nonce callback is NULL, request 50% more entropy following NIST SP800-90Ar1 section 9.1. Reviewed-by: Dr. Matthias St. Pierre <[email protected]> GH: #5503 Each of them seen by itself make sense. The combined result, though, leaves me wondering... (I'm tempted to try this with /dev/random only on Unix... do I remember it right, that it blocks for a while after every 8 byte chunk on some Unixen?) -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
