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

[Theodore Ts'o]

On Tue, Jun 27, 2017 at 09:02:54PM +0000, Salz, Rich wrote:
> > What is your concerns about syscall performance?  What are your
> > performance requirements?  I can tell you that Chrome has been using
> > /dev/urandom 
> 
> Well, Chrome ultimately works at human-scale.  On the server side, thousands of connections per second and one or two syscalls per connection seems like something we should avoid.
> 
> > My recommendation for Linux is to use getrandom(2) the flags field set to
> > zero. 
> 
> And for older Linux?

The Chacha20 based CRNG is available since Linux 4.9.  So Debian
Stable and Ubuntu LTS 16.04.3 (out in August) will be using a kernel
with the ChaCha20 based CRNG.

Using the attached benchmark program, which calls getrandom() a
million times to generate a 32 byte (256 bit) session key, the latency
of getrandom(2) is approximately 2.9 microseconds, when run on a
n1-standard-1 GCE VM.

For older Linux systems, where you are using a SHA1 based CRNG, the
time to run getrandom(2) is approximately 5.5 microseconds on the same
class of VM.  It really is not that much worse.  And I'll gently
suggest that the public key operations will probably dominate the cost
of calling getrandom(2) or reading from /dev/urandom.

The reason why I moved to the ChaCha20 based algorithm was only
partially about the speed.  It also had the significant bonus that I
didn't have keep on explaining that theoretical and demonstrated
attacks against SHA-1 weren't applicable to how it was being used in
Linux's RNG.  (See also previous comments about how a lot of
complaints about RNG's are more religious than real.)

It's also very unlikely that Enterprise distributions will bother
updating to a newer version of OpenSSL, since in general they don't
want to break shared library ABI's, and the version of OpenSSL that
they shipped with originally will almosrt certainly have an
incompatible ABI with a modern version of OpenSSL.  So I doubt this is
really a significant issue.

By the time a new version OpenSSL which uses getrandom(2) is picked up
by Linux distributions, it is extremely likely that they will be using
a 4.9 or newer kernel --- and unless you have a crypto accelerator to
speed up your symmetric key operations, I really doubt performance is
going to be an issue when you are using getrandom(2), regardless of
which kernel version you are using.

Cheers,

	   	       	   		  - Ted

P.S.  The version of the getrandom(2) manpage in Ubuntu LTS's are very
much obsolete.  Even after Ubuntu LTS updates to a 4.9 or newer kernel
when 16.04.3 gets released in August 2017, it's unlikely they will
bother to update the manpages, and the 16.04 getrandom(2) man page was
outdated when the distribution was released.  So arguments that
getrandom(2) should not be used based on the manpage are not valid.