fwd, and added comment at end about a "upstream distribution" of repute. ---------- Forwarded message ---------- From: coderman <coderman@gmail.com> Date: Sat, Mar 22, 2014 at 6:06 PM Subject: Re: [RNG] Haveged - A Simple Entropy Daemon To: Brad Martin <yabrad@gmail.com> On Sat, Mar 22, 2014 at 5:44 PM, Brad Martin <yabrad@gmail.com> wrote:
... When great HWRNG is working, it can be damned difficult to find the signatures - but they're always there. Even in the best case, cryptographers must whiten, if only to scramble those signatures. But the magic is in that underlying raw data - so unpredictable!
this too, a much longer discussion. we are in agreement, though one point: when FreeBSD decided against direct use of _both_ RDRAND and XSTORE, it was not an equal dismissal. RDRAND is specifically, and intentionally designed without direct access to the physical entropy sources, while XSTORE allows direct access to a userspace entropy daemon through the MSR configuration bits. XSTORE in raw mode, to userspace entropy daemon (rngd) that continously monitors for catastrophic failure (as above), and then _conservatively_ digests and folds the entropy before adding to OS kernel entropy pool is a robust configuration. RDRAND and RDSEED inherently crippled - if you had to pick a design, you would pick raw access with open and independent validation of run-time behavior with configurable conservative'ness as you so chose. instead, NIST and FIPS push _hard_ on opaque designs without raw access. in turn, US Gov pushes vendors hard for NIST/FIPS compliance. this is just one stream of influence working against the interest of users and strong privacy. if you really want to do entropy without repute: 1.: it starts with development and distribution, where every host and runtime is seeded with distinct mastering entropy that is mixed on first boot.** 2.: every physical host contains two (redundant) physical entropy sources run in continuous verification with immediate halt/panic on dual physical source failure. 3.: opportunistic entropy gathering daemons also running on host including haveged, dakarand, and kernel interrupt and activity scavenging. 4.: virtio-random device support feed into guest OSes from host entropy pool. (Qemu, KVM, Vbox, etc.) 5.: at shutdown of physical host entropy state is saved to FDE protected root volume for re-incorporation into entropy state on next start. 6.: as signal of care, in all mastering images and runtime ensure that /dev/urandom links to /dev/random special device. 7.: use the strace to confirm in every application that appropriate entropy from /dev/*random is read when generating keys or nonces. [post to HN when confused about key length equivalences and application level entropy pools...] ** your distribution in turn is fully reproducible, and the builder of your images provides you an installation image signed by them, including all the other public sigs, and including the per-instance entropy, the entirety of which is then also signed again. you exchanged keys in person at some point in the past, to get your first copy of $secure_distro, and have been using meatspace authenticated keys ever since...