[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Aaron Zauner]

Hi,

Ralf Schlatterbeck wrote:
> (As I've written part of that section let me reply here)

The section is actually not bad, I have a problem with the haveged
recommendation.

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

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

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

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

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.

> 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

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

I agree.

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

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150429/d79aec6e/attachment.sig>