[Cryptography] OpenSSL CSPRNG work

[Ron Garret]

On Jun 28, 2017, at 3:36 PM, iang <iang at iang.org> wrote:

> On 28/06/2017 02:44, Ron Garret wrote:
> 
>> On Jun 27, 2017, at 10:42 AM, Nemo <nemo at self-evident.org> wrote:
>> 
>>> "Salz, Rich" <rsalz at akamai.com> writes:
>>> 
>>>> We're starting to work on a new CSPRNG for OpenSSL release 1.1.1 (the
>>>> main point of that release is TLS 1.3, so we think it will have a lot
>>>> of uptake).
>>> Have you read "Cryptographic Right Answers" from Thomas Ptacek, who
>>> actually knows what he is talking about?
>>> 
>>> https://gist.github.com/tqbf/be58d2d39690c3b366ad
>>> 
>>>    Use /dev/urandom.
>>> 
>>>    Avoid: userspace random number generators, havaged, prngd, egd,
>>>    /dev/random
>>> 
>>> Why on earth would you put something as critical as random number
>>> generation into some complex userspace monstrosity?
>>> 
>>> I am fairly confident you will ignore this advice, but could you please
>>> do me one small favor? Go ask on crypto.stackexchange.com and see what
>>> kind of response you get
>> Thomas may know what he’s talking about, but his advice is based on some tacit assumptions which may not always be true, and which a reasonable person might choose not to accept.
>> 
>> Thomas’s argument is: there are a zillion ways to screw up a CSPRNG, so it’s best to just have one very carefully vetted implementation that everyone uses.  That is /dev/urandom.
>> 
>> It’s a reasonable argument if you’re a security expert, less so if you’re a user.  If you’re a security expert you know how to vet your /dev/urandom, so if everyone uses /dev/urandom you have now eliminated multiple possible points of failure.  If you’re a user, you have either N vendors (one for each of your security-dependent applications) or N+1 vendors (one for each of your security-dependent applications plus one for your /dev/urandom driver).  If you have the choice of trusting N vendors vs trusting N+1 vendors it is not unreasonable to choose the former, particularly if N is small.
> 
> I would say precisely the reverse.  If you're a security expert you have a good chance in hell of doing a good PRNG.  If you're a user you have no chance.
> 
> I use chance here quite productively - hashes and encryption algorithms are delivered with testing numbers, so as long as you get the numbers to work, you're in good company.  Literally.  Users can do this.
> 
> Whereas PRNGs come with no good numbers.  There is no objective positive test.  There are only negative tests.  So the only way to know your PRNG is good is with a lot of care, and reference to the state of the art in thinking about PRNGs.
> 
> This is not for users.  For them, trusting a platform is far far safer, by orders of magnitude.
> 
> Now, you say now they are at the mercy of platforms.  This is true. But this mercy scales.  Millions of users will be dependent, and will observe and will yell loudly and get it fixed.  Each platform. And, those fixes will flow to all the other millions without them noticing.
> 
> I'm with Thomas on this one.  Both of them, and a host of others.

Actually, I am too for the most part.  But let’s not forget the context of this discussion.  This discussion originated because a member of the OpenSSL development team asked for some advice.  The OpenSSL development team is not a bunch of naive users.  Their expertise is probably comparable to the expertise of the people who wrote /dev/urandom for whatever OS you are using.  So the risk of the OpenSSL team screwing something up is probably comparable to the risk of the /dev/urandom team screwing something up, which is to say, the risk is low, but not zero.

Whatever the risk is, because of the way security risks compose, it is a defensible position for OpenSSL to use its own CSPRNG rather than /dev/urandom.

rg