[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3
azet at azet.org
Wed Apr 29 14:32:02 CEST 2015
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
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.
> 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.
> 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 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.
>  http://www.2uo.de/myths-about-urandom/
>  https://twitter.com/veorq/status/591753646104322050
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Ach