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

[iang]

On 15/03/2024 04:04, Jim Cheetham wrote:
>> 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.

Hi Jim,

It used to be that entropy was the focus and also the measure. But that 
proved too difficult - it is very hard to reliably estimate entropy, in 
large part because the part can break and deliver zero entropy and you 
can't tell.

Early designs followed the Schneier concept of measuring the entropy in 
a pool and then stirring in some more when needed from a trusted source. 
But that didn't make for simple coding.

Since then, thinking has changed:

1. seek not entropy but surprise. The former is a physical quality, 
whereas the latter is a human quality. Who is your attacker? You just 
need to surprise him with numbers he can't see, they don't need to be 
high entropy at all, they just need to be unpredictable *by your attacker*.

2. NB that if your attacker is on your machine, and can read everything, 
then it makes no difference if it is entropy or surprise...

3. Instead of relying on one perfect entropy engine, rely on several 
poor quality devices. 3 or even 6 of them.  As long as they are 
independent, they all help.

4. Then mix it all together, and shove it through a cryptographically 
secure hash function.  Ie one that cannot be looked back through.  
Typically people use an encryption algorithm for this.

5. Enjoy!  I first wrote this up back in 2014 
https://iang.org/ssl/hard_truths_hard_random_numbers.html


iang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20240315/8583f2ed/attachment.html>