Comments on: Haveged – A True Random Number Generator

By: Aaron Toponce

Aaron Toponce — Sat, 06 Oct 2012 14:15:06 +0000

Because the entropy created from the standard system stuff day-to-day, is “good enough” for most users. If you want more, then haveged is available.

By: Matt Campbell

Matt Campbell — Thu, 04 Oct 2012 17:06:48 +0000

So why isn’t haveged yet a part of every GNU/Linux distro’s base installation? Is it just too obscure, or is there some kind of trade-off?

Thanks for blogging about this.

By: Marc Deslauriers

Marc Deslauriers — Mon, 17 Sep 2012 23:05:11 +0000

@guwertz: Interesting, thanks for clearing that up.

By: Aaron Toponce

Aaron Toponce — Mon, 17 Sep 2012 19:46:25 +0000

Marc Deslaureiers- I was going to correct your comment, but guwertz has already done so. http://www.issihosts.com/haveged/history.html#havege explains it fairly well. caching, interrupts, etc.

Jason- /dev/urandom uses the Yarrow PRNG. It too draws on entropy as /dev/random does, but when exhausted, will turn to Yarrow to generate the numbers. As will all performant PRNGs, a period is associated with Yarrow, and after so many have been generated, the rest can be predicted. In this case, it’s a 128-bit period.

By: guwertz

guwertz — Mon, 17 Sep 2012 17:40:15 +0000

havege does not use TSC drift. havege relies on variations of execution timing – not the same thing at all. Execution timing in a modern processor depends on all sort of caching: l1 data, l1 instruction, translation look-aside buffers, branch predictors. In any realistic interrupt driven system, the elapsed time for execution a series of instructions in unpredictable – anyone who has ever bench marked code will agree. A high resolution timer is needed to scale this effect down to where the benchmark can be performed quickly enough to serve as a RNG. Actually it is not quite that simple because the signal is weak and highly skewed (log normal) and some art is needed to create uniformly distributed output.

The polar SSL link shows one of the few ways this can go wrong: a badly virtualized TSC. AFAIK, the only way to deal with this is to validate operation at run time. That is what the latest haveged now does. It uses the AIS-31 test suite used in German CC certification to verify correct operation at run time.

By: Jason

Jason — Sun, 16 Sep 2012 23:00:52 +0000

I don’t know where entropy falls into what I’m about to say, but;
I’ve heard for years that /dev/random’s limitations are mostly overcome by /dev/urandom

Is entropy not included in that statement?

By: Marc Deslauriers

Marc Deslauriers — Sun, 16 Sep 2012 22:31:01 +0000

AFAIK, Havege uses TSC drift as a random source of entropy, but recent CPUs now have an accurate TSC, so havege hasn’t been generating random numbers for a while now. This is also an issue in certain virtualized environments.

PolarSSL had to switch away from using Havege as the basis of their RNG because of this issue:
http://polarssl.org/trac/wiki/SecurityAdvisory201102

By: jpope

jpope — Sat, 15 Sep 2012 15:51:49 +0000

Thanks for this post. My webserver had a ~160 bit average entropy according to munin. I hadn’t even thought about looking to increase this but, after installing haveged, my server seems to average ~2000.
And after a little more research, I’ve found that “hackers” can utilize low entropy situations by guessing some bits. A higher available entropy will help security some by making it more difficult to randomly guess bits.