potential changes to random number generation for libgcrypt

[Nikos Mavrogiannopoulos]

On Tue, Apr 17, 2018 at 9:59 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> 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.

I concur in that. The distributor has often only knowledge of the
default kernel available for this distribution. Whether the
administrator downgrades/upgrades the kernel that is outside the
distributor's control. Even worse you can have full distributions
running inside containers, having for example ubuntu running on centos
(i.e., with centos kernel). That means that if the bucket passes to
distributions, distributions will pass it to administrator. The
administrator him/herself it is very unlikely that he knows anything
about getrandom/urandom or whether the application he relies on uses
libgcrypt. As such, if you'd like to address that issue, the only way
seems to be detecting the kernel capabilities on run-time.

regards,
Nikos