Fwd: [RNG] Haveged - A Simple Entropy Daemon

[coderman]

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...