Comments on: Haveged - A True Random Number Generator https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/ Linux. GNU. Freedom. Sun, 13 May 2018 18:21:35 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-43006 By: Aaron Toponce https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-154406 Mon, 28 Jul 2014 01:28:39 +0000 http://pthree.org/?p=2497#comment-154406 Well, "true random" turns into a philosophical debate very quickly, but what's important isn't the "random" environment numbers come from as much as when observing a sequence of numbers, you still cannot gain any additional knowledge out future generated numbers. In other words, "computationally secure" unpredictability.

At any event, with "true random" numbers, you still end up subjecting them to a man-made algorithm. So, even if you could prove beyond a shadow of a doubt that you have "true random" numbers, as soon as you subject them to a cryptographically secure algorithm, they are only as "strong" as the algorithm that they were subjected to. The only time "true random" numbers really make any sense, is when you are using an informational theoretic algorithm, such as the One Time Pad or Shamir's Secret Sharing.

]]>
By: True Randomness https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-152291 Fri, 25 Jul 2014 21:14:34 +0000 http://pthree.org/?p=2497#comment-152291 In the end, “randomness” is all about the definition… just ask a cryptographer. 😉

]]>
By: Aaron Toponce https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-117014 Sat, 06 Oct 2012 14:15:06 +0000 http://pthree.org/?p=2497#comment-117014 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 https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-117004 Thu, 04 Oct 2012 17:06:48 +0000 http://pthree.org/?p=2497#comment-117004 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?

]]>
By: Marc Deslauriers https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-116940 Mon, 17 Sep 2012 23:05:11 +0000 http://pthree.org/?p=2497#comment-116940 @guwertz: Interesting, thanks for clearing that up.

]]>
By: Aaron Toponce https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-116939 Mon, 17 Sep 2012 19:46:25 +0000 http://pthree.org/?p=2497#comment-116939 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 a CSPRNG, and it's output is indistinguishable from "true random" numbers. It too draws on its own entropy pool separate from /dev/random, but when exhausted, will turn to using SHA1 to generate the random numbers. As will all performant PRNGs, a period is associated with SHA1, and after so many have been generated, the rest can be predicted. In this case, it's a 160-bit period (which is fairly large).

]]>
By: guwertz https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-116938 Mon, 17 Sep 2012 17:40:15 +0000 http://pthree.org/?p=2497#comment-116938 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 https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-116933 Sun, 16 Sep 2012 23:00:52 +0000 http://pthree.org/?p=2497#comment-116933 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 https://pthree.org/2012/09/14/haveged-a-true-random-number-generator/#comment-116931 Sun, 16 Sep 2012 22:31:01 +0000 http://pthree.org/?p=2497#comment-116931 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: