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

[Benjamin Kaduk]

On 06/27/2017 04:51 PM, Kurt Roeckx wrote:
> On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote:
>>
>> On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote:
>>
>>> Do you mean having openssl just pass through to
>>> getrandom()/read()-from-'/dev/random'/etc. or just using those to seed
>>> our own thing?
>>>
>>> The former seems simpler and preferable to me (perhaps modulo linux's
>>> broken idea about "running out of entropy")
>> That's a pretty big modulus.  As I wrote over on the crypto list:
>>
>> The xenial 16.04 LTS manpage for getrandom(2) says quite explicitly:
>>
>>>> Unnecessarily reading large quantities  of data will have a
>>>> negative impact on other users of the /dev/random and /dev/urandom
>>>> devices.
>> And that's an understatement.  Whether unnecessary or not, reading
>> not-particularly-large quantities of data is tantamount to a
>> denial of service attack against /dev/random and against its
>> upstream sources of randomness.
>>
>> No later LTS is available.  Reference:
>>   http://manpages.ubuntu.com/manpages/xenial/man2/getrandom.2.html
>>
>> Recently there has been some progress on this, as reflected in in
>> the zesty 17.04 manpage:
>>   http://manpages.ubuntu.com/manpages/zesty/man2/getrandom.2.html
>>
>> However, in the meantime openssl needs to run on the platforms that
>> are out there, which includes a very wide range of platforms.
> And I think it's actually because of changes in the Linux RNG that
> the manpage has been changed, but they did not document the
> different behavior of the kernel versions.
>
> In case it wasn't clear, I think we should use the OS provided
> source as a seed. By default that should be the only source of
> randomness.
>

I think we can get away with using OS-provided randomness directly in
many common cases.  /dev/urandom suffices once we know that the kernel
RNG has been properly seeded.  On FreeBSD, /dev/urandom blocks until the
kernel RNG is seeded; on other systems maybe we have to make one read
from /dev/random to get the blocking behavior we want before switching
to /dev/urandom for bulk reads.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170627/6b1a410c/attachment.html>