[cryptography] Quality of HAVEGE algorithm for entropy?

Stephan Mueller smueller at chronox.de
Thu Nov 28 09:29:52 EST 2013

Am Donnerstag, 28. November 2013, 15:04:49 schrieb Jonas Wielicki:

Hi Jonas,

> On 28.11.2013 10:29, Stephan Mueller wrote:
> > That is why my current patch set only uses the jitter noise source as 
> > resort, i.e. when /dev/random is about to block. As long as the other
> > noise sources produce entropy, my jitter noise source is not even 
> That sounds as if the jitter noise should be incorporated as a noise
> source into rngd. If it is available from userspace at least. rngd has
> the approach to feed the entropy pool if it falls below a certain
> watermark to avoid dominating the pool.

I am aware of that, and I will approach the developers of rngd too. But, I 
am intrigued by the questions and flag I get on LKML. So, I know I did not 
have my homework completed, even though I have tests on the 
appropriateness of the CPU jitter RNG on more than 200 systems of all 
kinds of CPUs ranging from embedded devices up to mainframes. All of 
today's common CPU types are covered. See [2] for details.

As the heart of this RNG is only 30 lines of code, it should be suitable 
for rngd too.

Though, my original ideas for writing the RNG are:

- decentralized noise source (i.e. every user in need of entropy 
instantiates his own)

- available at earliest boot and all environments (e.g. live CDs and 
initial installation environments where you may generate long lasting keys 
for disk encryption)

- available in embedded environments

- available on all architectures

- available in virtual environments

rngd falls short in some of the goal. Therefore, I will pursue rngd in an 
attempt after the Linux kernel.

[2] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html

| Cui bono? |

More information about the cryptography mailing list