> On Jun 7, 2019, at 7:24 PM, Kurt Roeckx <k...@roeckx.be> wrote:
>
> That's all very nice, but nobody is going to run that.
They also don't have to upgrade their kernel, or deploy new
versions of OpenSSL. If platform release engineers don't
deploy core services that ensure reliably CSPRNG seeding,
then their platform is less secure at boot. This is their
choice. Users can vote with their feet for more secure
O/S distributions.
Secure CSPRNG seeding is a platform responsibility, OpenSSL
then runs secure PRNGs seeded from the platform. There's
only so much we can reasonably do. The rest has to happen
outside of OpenSSL, as a pre-requisite.
And yes, fallback on RDSEED/RDRAND + TPM (real or virtual)
+ whatever is available, but ideally not in libcrypto, but
rather a service that that seeds the system at boot.
Those other mechanisms are often either not fully trusted in
isolation, not always available, or too expensive at every
process start. The logic to identify which are available,
and how many are enough, ... is best extracted to run separately
at boot, with the library using either getentropy() or read
/dev/urandom (older kernels).
--
Viktor.
