[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3
pg at futureware.at
Wed Apr 29 14:38:55 CEST 2015
> The author writes quite convincingly that low entropy does not matter;
> there is no count of entropy, but an estimate and given the fact that
> actuality /dev/random and /dev/urandom are fed by the same CSPRNG, the
> 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
> Therefore, when I asked about it  I was suggested that haveged is
> only a
> waste of resources. That made me go back to bettercrypto and think
> it's good to add a note that haveged is sometimes proposed, but it's
> 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
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
> here and asking around.
More information about the Ach