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

[Theodore Ts'o]

On Wed, Jun 28, 2017 at 01:50:49AM +0000, Salz, Rich wrote:
> That's interesting info Ted, thanks. But we don't currently know
> anything about which kernel or glibc version we're building for;
> maybe that has to change.  (We barely, and rarely, look at the
> toolchain version.)  And we need to be able to build a version which
> runs across a whole mess of kernels and x86 CPU's.

The performance numbers for /dev/urandom and getrandom pre-4.9 should
be largely consistent until you get back to when we were using MD5
instead of SHA-1 for the CRNG.  When you get back to the days when
/dev/urandom used MD5, the performance will be (obviously) faster, and
given the way we use the cryptographic hash algorithms, the currently
known attacks to MD5 and SHA won't be an issue.

The much *LARGER* problem is that those ancient kernels are almost
certainly filled with unpatched security holes (e.g., the kind that
might be exploitable remotely using a malformed ICMP packet.)  Why
should the attacker bother with some complex cryptographic attack with
a simple buffer overrun will get them all that they need, much more
easily?

If you are using an older version of glibc, that doesn't have
getrandom(2) support, you can either attempt to call getrandom(2)
directly via the syscall interface, or you can just fall back to
opening /dev/urandom and reading from it.  As long as you do proper
error checking to catch things like the fd exhaustion attack, you
should be fine from a security perspective, and the performance of
reading from /dev/urandom should be no different from using
getrandom(2), assuming you keep the fd to /dev/urandom open during the
life of the process.

If you have a pre-3.17 kernel that doesn't have getrandom(2) support,
the same logic applies above.  You won't have a performance problem,
and the potential security concerns (IMHO, of a purely certificational
nature) of /dev/random from that era will be the *least* of your
problems.

Cheers,

							- Ted