[openssl-dev] Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL uri at ll.mit.edu
Mon Aug 14 16:43:58 UTC 2017


>> 1. What’s the default if “with-rand-seed” was not provided? All of the listed supported types? None of them? Some of them…?
>  
>   As the first bullet says, it’s “os”.   

OK, thanks.

> As for the second part of your question, it is deliberately not answered.   If you care, you’ll have to read the source.  (It’s clean and easy to do so, now.)  We’re not documenting everything.
    
I think it’s a bad approach to not document this important behavior. It has to be security-analyzed, then frozen & published.

>>2. What is the order in which the seed sources are tried (both when “with-random-seed” was and was not given)? 
>
> Read the source.

Likewise. It has to be published, and the developers need to figure out the right way here and commit to it (no pun intended).
    
>> 3. What should I do if I want a given source to be used in addition to the other sources, regardless of whether openssl thinks it got “enough bits” of randomness or not?
>
> Modify the source :)

Very bad answer. 

When randomness is involved, adding more of diverse sources can only improve the outcome. Therefore there must be a way to tell OpenSSL to *not* stop when it got what it believe to be “enough” but mix in more from other sources. And that mechanism must *not* be an individual hack – but a standard reviewed maintained access method.
    
> For a few reasons, we’re deliberately not documenting all the details.  Interested parties will have to read the source.
    
I have no problem reading the source code. I do have a problem with (a) important decisions like this not “formalized” and documented, and (b) mechanisms to tune the RNG seeding not provided and clearly and comprehensively documented.

I urge the developers to reconsider.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170814/0ace489d/attachment.bin>


More information about the openssl-dev mailing list