[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Ralf Schlatterbeck]

On Wed, Apr 29, 2015 at 02:32:02PM +0200, Aaron Zauner wrote:
> 
> Maciej Soltysiak wrote:
> > I wanted to ask about one recomendation give in chapter 3.3.3 on haveged.
> > Haveged is suggested for increasing the kernel entropy pool to improve
> > the RNG quality.
> > 
> 
> Yeah. I never particularly liked that section. It's unclear to me how
> haveged improves security on a production system. When this initially
> came up I noted that there's been no recent research into haveged's
> security -- what you'll find is basically the original papers by the
> haveged authors.

(As I've written part of that section let me reply here)

The main worries of RNG seeding are for small embedded devices and for
VMs -- in particular during startup when not much entropy is available.
For VMs recent KVM seem to have mechanisms of seeding the RNG of the
guest from the host machine. This is not yet in stable releases of major
distros, though (checked for Debian). Some of the entropy gathering
techniques of haveged work also inside a VM (because they rely on timing
of events of the real hardware). This implies that you need good timers
inside the VM.

For small embedded devices the problem is IMO still mainly unsolved but
running haveged there *seems* to improve things (although some of the
mechanisms of haveged only work on bigger CPUs).

As far as I understand the kernel entropy mixing code, if something
feeds the kernel entropy pool (and default install of haveged is used in
that mode) I don't think it can somehow "dilute" the entropy pool -- if
it doesn't feed entropy into the pool (in the worst case constant data)
the kernel entropy pool won't be worse than without this non-random
source.

So using an additional questionable entropy source should not lower
security of the rng.
(And I'm not asuming a malicious entropy-source here where an attacker
has access to the random-pool internal data to fabricate mixins to
influence the outcome of the RNG as DJB asumes in
http://blog.cr.yp.to/20140205-entropy.html )

> Furthermore; haveged is /really/ slow. Applications that depend on
> timely randomness will block which might cause security issues in
> itself. I'd rather trust upstream kernel maintainers with randomness
> than an unmaintained academic project. YMMV.

That would only apply in case an application is using /dev/random (and
blocking)? 
Concerning trust about kernel maintainers randomness: The "Mining your
Ps and Qs" Paper has some criticism on missing random sources on low-end
embedded devices. Seems some random sources have been removed from the
kernel (if they might somehow be affected by an attacker) leaving almost
no random sources on these small devices. 

In addition there was -- at the time of the Ps & Qs paper -- some
brokenness in OpenSSL entropy code in that OpenSSL seeded its RNG
early-on *once* and later only if enough entropy was consumed from the
internal OpenSSL pool. This means that a daemon relying on entropy (e.g. SSH)
would have seeded the OpenSSL internal RNG once from /dev/urandom when
there was almost no entropy in the system (at the start of the daemon).
One of the results were guessable nonces for DSL algos (making the
secret key recoverable) *even after days of running the system* (where
enough entropy would have been available but OpenSSL didn't use it).
I don't know if this is fixed in recent OpenSSL.


> > The author writes quite convincingly that low entropy does not matter;
> > that there is no count of entropy, but an estimate and given the fact
> > that in actuality /dev/random and /dev/urandom are fed by the same
> > CSPRNG, the only difference is that /dev/random blocks and /dev/urandom
> > is - given the computational security we're aiming to get - a safe bet.
> 
> Both use the same seed, that's true. _NO_ application should ever use
> /dev/random. I'd actually be for removing accessibility to it, but I
> figure there're some obscure cases in legacy software that will really
> need /dev/random (where?). /dev/urandom is seeded by /dev/random.
> Depends on the OS you're using but on Linux that's the case; more
> details in http://man7.org/linux/man-pages/man4/random.4.html.

In fact it's a good idea that Linux now also implements OpenBSDs
getentropy/getrandom -- with a special file like /dev/urandom for this,
too much can go wrong opening and reading from a file (as the LibreSSL
developers have repeatedly pointed out).

> > Therefore, when I asked about it [2] I was suggested that haveged is
> > only a waste of resources. That made me go back to bettercrypto and
> > think whether it's good to add a note that haveged is sometimes
> > proposed, but it's not improving the security of crypto using the RNGs.
> > If you suffer from /dev/random blocking, use /dev/urandom. Period. No
> > benefit in using /dev/random and feeding entropy.
> > 
> 
> ACK.

Has someone done measurements on this?
I'd like to see experiments with some OpenWRT devices with current
OpenSSL code check for, e.g., DSL nonces generated with and without
haveged...
Has someone recently looked into OpenSSL RNG code?

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office at runtux.com
allmenda.com member                     email: rsc at allmenda.com