[OneRNG-Discuss] Debian 12 kernel ignoring entropy from OneRNG?

[Jim Cheetham]

On Fri, 15 Mar 2024, at 11:42 AM, Andy Smith wrote:
> I still wonder if the output of hardware entropy gadgets are
> actually being used by the kernel though, because as mentioned the
> CSPRNG is seeded really early in the boot by RDRAND and goes on its
> merry way from there. I'm not sure if it uses much even from RDRAND
> after the initial seeding.

The CSPRNG, like all PRNGs, has a limit to the amount of data that can be output, the "period". With a decent algorithm this can be a very large number, and you can try to keep track of usage & plan when to reseed the generator ... but from what I can see the strategy in random.c is to reseed opportunistically about once every 60 seconds; so mixing more entropy in will always have an effect.

I suspect RdRand is one of the "hardware generators", and therefore a contribution from it will be used every time the PRNG is reseeded.

> I suppose it is very hard to quantify if an entropy pool resulting
> from the Linux CSPRNG running for time t is any "better" for having
> some entropy mixed in from a gadget vs. if it had just been left to
> extrapolate from its initial seeding by RDRAND and CPU timings etc.

A long time ago I had wanted to run an experiment on boot times & moving data across ssh & tls services, on a large fleet of VMs. Sadly never managed to do it; it would have made a nice measurement for sysadmin operations. I don't think that under a current kernel there's any speed benefit any more.

However, a large part of "having multiple entropy sources" is to protect you from attacks or errors on the default sources. This is probably still a valid proposition :-)

And of course, generation of random numbers for non-operating-system features is still valid. PRNGs (even CSPRNGS) are not "the same" as actual entropy sources.

-jim