potential changes to random number generation for libgcrypt

[Daniel Kahn Gillmor]

On Sat 2018-04-14 11:09:54 +0200, Werner Koch wrote:
> On Fri, 13 Apr 2018 21:20, dkg at fifthhorseman.net said:
>
>> I think it actually solves problems for users of modern systems, and
>> acts as an incentive against sketchy behavior that might otherwise
>> bypass the kernel's own concept of whether it has received sufficent
>
> The problem I see with this proposal is that it is Linux specific.
> /dev/random is not a Linux specific device but fortunately implemented
> by many OSes.  The exact properties differ slightly and that is why we
> need to be very cautious on assumptions on its properties.  Right, the
> getrandom syscall is currently Linux specific but it might be
> implemented by other OS too (iirc OpenBSD has a getrandom call even
> longer).

Yes, this proposal is Linux-specific.  The proposed patch has *no*
effect on non-Linux systems.  Why is this a problem?  This is an
important platform that it is worthwhile to optimize for.

> Further there is no guarantee that Libgcrypt or gpg are only used on
> modern Linux kernels.  In fact old Linux versions are still in
> widespread use.

right, that's why the libgcrypt code already propose falls through at
runtime if the kernel doesn't support getrandom().  My proposed patch
doesn't change that either.  If the running kernel doesn't support
getrandom(), then the gcrypt code will fall back to reading from the
underlying character devices.

> As portable software Libgcrypt and GnuPG can't assume that everything is
> Linux and thus I consider it a distribution thing to tweak the
> installation.  In particular adding "only-urandom" to
> /etc/gcrypt/random.con can easily be done by the distribution as the
> distro maintainers known which Linux version they install.

This proposed solution is problematic.  As you say above, it's possible
that gcrypt is run on a system whose kernel does not support
getrandom().  If the decision is made at distribution time to set
"only-urandom", but then the kernel changes underneath the distribution
(e.g. booting from a hardware-vendor-supplied kernel), then the
"only-urandom" setting could cause the code to read from /dev/urandom,
which is capable of providing pseudorandom data before the kernel's
entropy pool is initialized.

This can lead to generation of predictable long-term secrets (e.g. RSA
public keys that are breakable by internet-wide gcd factorization),
which is a super bad outcome.

Rather than recommending that distributions make a compile- or
packaging-time decision about whether to assume that the kernel has
getrandom() available, the better choice is for gcrypt to make that
decision at runtime, based on the current kernel.

I believe that's what my proposal does, while leaving untouched the
semantics and behavior of gcrypt on other platforms (and on Linux
kernels that do not support getrandom()).

If you think that's not the effect of the proposed patch, i'd be
grateful for any corrections.

         --dkg