[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

**To**:**current-users%netbsd.org@localhost, tech-kern%NetBSD.org@localhost, port-xen%NetBSD.org@localhost, woods%planix.ca@localhost****Subject**:**Re: regarding the changes to kernel entropy gathering****From**:**Havard Eidnes <he%uninett.no@localhost>**- Date: Mon, 05 Apr 2021 00:07:49 +0200 (CEST)

>> Do note, the existing randomness sources are still being sampled and >> mixed into the pool, so even if the starting state from the saved >> entropy may be known (by violating the security of the storage), >> it's still not possible to predict the complete stream of randomness >> data once the system has seen a bit of uptime (given that there are >> actual other sources of (unverified) entropy which aren't all of too >> low quality). > > No amount of uptime and activity was increasing the entropy in my system > before I patched it. Indeed, that's also compatible with what I wrote. The samples from whatever sources you have are still being mixed into the pool, but they are not being counted as contributing to the entropy estimate, because the quality of the samples is at best unknown. > The unpatched implementation completely and entirely prevents > the system from ever using any of those sources, despite > showing that they are enabled for use. As far as I know, those samples are still being *used*, but as said above, not counted as contributing to the entropy count. A possible workaround is, once you have some uptime and some bits mixed into the pool, you can do: % su # dd if=/dev/urandom of=/dev/random count=1 If you then ensure that the entropy is saved and restored on reboot, as is typically done, after this initialization, neither /dev/random nor /dev/urandom will block(!). Ref. the attachment. >> Besides, the implementation has been thoroughly vetted. E.g. the >> reference [7] from the wikipedia article states in the conclusion on >> page 20 >> >> Overall, the Ivy Bridge RNG is a robust design with a large >> margin of safety that ensures good random data is generated even >> if the Entropy Source is not operating as well as predicted. > > "design" != implementation Well, if I'm not mistaken, the actual implementation was tested, not just a theoretical study of the design. And, as I said, thermal noise is one of the well-known physical systems which provide actual entropy. I am still of the fairly firm beleif that the mistrust in the hardware vendors' ability to make a reasonable and robust implementation is without foundation. Regards, - Håvard

b# uname -a NetBSD b.urc.uninett.no 9.99.81 NetBSD 9.99.81 (GENERIC) #0: Sat Apr 3 23:24:06 UTC 2021 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/i386/compile/GENERIC i386 b# rndctl -l Source Bits Type Flags /dev/random 0 ??? estimate, collect, v wd0 0 disk estimate, collect, v, t, dt cd0 0 disk estimate, collect, v, t, dt cpu0 0 vm estimate, collect, v, t, dv hardclock 0 skew estimate, collect, t bge0 0 net estimate, v, t, dt system-power 0 power estimate, collect, v, t, dt autoconf 0 ??? estimate, collect, t seed 256 ??? estimate, collect, v b# rndctl -s 0 bits mixed into pool 256 bits currently stored in pool (max 256) 0 bits of entropy discarded due to full pool 0 hard-random bits generated 0 pseudo-random bits generated b# dd if=/dev/random of=/dev/null count=1024 0+1024 records in 64+0 records out 32768 bytes transferred in 0.021 secs (1560380 bytes/sec) b# rndctl -s 0 bits mixed into pool 256 bits currently stored in pool (max 256) 0 bits of entropy discarded due to full pool 0 hard-random bits generated 0 pseudo-random bits generated b# b# rndctl -lv Source Bits Type Flags /dev/random 0 ??? estimate, collect, v Dt samples = 0 Dt bits = 0 Dv samples = 0 Dv bits = 0 wd0 0 disk estimate, collect, v, t, dt Dt samples = 5559 Dt bits = 0 Dv samples = 5869 Dv bits = 0 cd0 0 disk estimate, collect, v, t, dt Dt samples = 0 Dt bits = 0 Dv samples = 0 Dv bits = 0 cpu0 0 vm estimate, collect, v, t, dv Dt samples = 183 Dt bits = 0 Dv samples = 183 Dv bits = 0 hardclock 0 skew estimate, collect, t Dt samples = 853 Dt bits = 0 Dv samples = 0 Dv bits = 0 bge0 0 net estimate, v, t, dt Dt samples = 0 Dt bits = 0 Dv samples = 0 Dv bits = 0 system-power 0 power estimate, collect, v, t, dt Dt samples = 0 Dt bits = 0 Dv samples = 0 Dv bits = 0 autoconf 0 ??? estimate, collect, t Dt samples = 43 Dt bits = 0 Dv samples = 0 Dv bits = 0 seed 256 ??? estimate, collect, v Dt samples = 0 Dt bits = 0 Dv samples = 1 Dv bits = 256 b#

**Follow-Ups**:**Re: regarding the changes to kernel entropy gathering***From:*Michael van Elst

**Re: regarding the changes to kernel entropy gathering***From:*Joerg Sonnenberger

**Re: regarding the changes to kernel entropy gathering***From:*Mouse

**Re: regarding the changes to kernel entropy gathering***From:*Greg A. Woods

**References**:**Re: regarding the changes to kernel entropy gathering***From:*Robert Elz

**Re: regarding the changes to kernel entropy gathering***From:*Havard Eidnes

**Re: regarding the changes to kernel entropy gathering***From:*Greg A. Woods

- Prev by Date:
**Re: regarding the changes to kernel entropy gathering** - Next by Date:
**Re: regarding the changes to kernel entropy gathering** - Previous by Thread:
**Re: regarding the changes to kernel entropy gathering** - Next by Thread:
**Re: regarding the changes to kernel entropy gathering** - Indexes: