[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Philipp Gühring]

Hi Maciej,

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

Well, yes and no. If you are in special situations like e.g. early-boot or
virtualised systems where the hypervisor does not properly deliver random
numbers to the guests, then the difference between low entropy and no
entropy can become dangerous. In the early-boot scenario, havege should
solve the problem, in the virtualisation scenario, havege might not help
at all.

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

Well, it depends on your threat-model. If you create high-value keys like
root certificates for certification authorities or, can generate high
costs, then I would suggest to use /dev/random, and make sure, that enough
entropy is delivered to it. For the average user, /dev/urandom should be
fine, though.

I think havege really solves the early-boot problem, and in that alone, I
would say that it´s useful.

What´s your experience regarding the ressource waste of havege? How much
does it slow things down?

> Of course, I'm far from being authority, I'm just wearing a sysadmin
> hat
> here and asking around.

Best regards,
Philipp