[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Ralf Schlatterbeck]

On Wed, Apr 29, 2015 at 05:31:44PM +0200, Aaron Zauner wrote:
> > 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.
> 
> https://lists.debian.org/debian-boot/2013/01/msg00225.html

But embedded devices have no filesystem :-(
Good for VMs, though.

> > 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).
> 
> Exactly. For most embedded devices haveged doesn't really give you
> anything because haveged is architecture dependent. So sticking with
> what the kernel gives you is probably a better idea.

I think it makes a difference. But measuring this would be cool.

> > 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.
> 
> That's my understanding as well. But I don't see how haveged does
> improve the entropy pool in any way. The kernel has excellent entropy
> sources and the algorithms for mixing are constantly reviewed and
> updated if need be.

Not for embedded devices, see Ps and Qs paper.

[...]
> Some software still reads from /dev/random unfortunately. Do you have
> further references w.r.t. embedded entropy sources? Not sure but using
> kernel interrupts seems quite generic.

AFAIR in Ps and Qs paper, haven't looked at it for some months though.
And I'm not up to date with kernel developments in this area.

Note that embedded devices don't have many interrupt sources to begin
with. And I think to remember from Ps&Qs paper that network interrupts
were deemed attacker-influenceable at some point -- which is the *only*
interrupt source of many embedded routers.

> > 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.
> 
> I think this has been fixed.
> 
> https://github.com/openssl/openssl/commit/8a99cb29d1f0013243a532bccc1dc70ed678eebe

Um, no. This might improve things if the RNG fails (but if you have
known plaintext and you can predict the RNG you still can crack the
DSA key). I'm looking for the Seeding algos on the RNG generator
of OpenSSL, this should be fixed at the root...

I remember this from the paper:
- OpenSSL has its own internal RNG pool from which RNG numbers are
  computed
- This pool is seeded once on startup from the Linux RNG (with urandom)
- The pool is re-seeded only after enough (hopefully random) bits have
  been consumed
- If seeded from a repeatable Linux RNG value it will produce the same
  sequence of "random" numbers everytime

On embedded devices which were up for *months* this led to repeatable
sequences of DSA nonces for *different* devices randomly probed on the
net. The SSH daemon had been started with no entropy and the OpenSSL RNG
had kepts its (predictable) state over months.

> > 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?
> 
> No idea. But that's a problem quite different from the kernel source, right?

It means repeating the stuff done in the Ps and Qs paper with
more modern kernels -- and comparing with running additional entropy
gathering tools like haveged. To have an opinion on haveged backed by
facts (and I'm not accusing of having no facts I don't have any either :-)

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