[Info-vax] In need of "good enough" randomness sources, anyone wanna help out? (OpenSSL 1.1.1 beta)

[Snowshoe]

On 4/3/2018 12:00 PM, Richard Levitte wrote:
> [disclaimer: this discusses pseudo-random numbers, not true randomness, so any time you see "random" written, think "pseudo-random".  Bill Gunshannon, please pay attention and don't derail]
> 
> Hey,
> 
> The randomness machinery in OpenSSL has changed radically for upcoming version 1.1.1.  The implementation is now a block cipher DRBG as specified in https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90ar1.pdf, based on AES-256-CTR.
> 
> To get some kind of seeding, this implementation does like before, and relies on data from an entropy aqcuisition function (see below).  It worked, by delivering just enough entropy (64 bytes at assumed 4 bits of entropy per byte => 256 bits, which is exactly enough for AES-256-CTR).
> 
> Now, we've run into a bit of trouble because of a very recent change that adds the possibility of a nonce to the pool.  When no nonce is given, but there's still a nonce size specified, and I quote:
> 
>      /*
>       * NIST SP800-90Ar1 section 9.1 says you can combine getting the entropy
>       * and nonce in 1 call by increasing the entropy with 50% and increasing
>       * the minimum length to accomadate the length of the nonce.
>       * We do this in case a nonce is require and get_nonce is NULL.
>       */
> 
> So we suddenly find ourselves in a situation where 256 bits of entropy isn't enough, the requirement has been elevated to 384 bits (96 bytes à 4 bits of entropy per byte).

Get the equivalent of MC LANCP SHOW DEVICE Exxx:/COUNTER to get some 
entropy related to the comings and goings of LAN traffic. Should be good 
for a few bytes of entropy. The more devices you have, the merrier.
MC SCACP SHOW CHANNEL /COUNTER will get you some more but because this 
goes on the lan the actual entropy will be less than the sum of the two.