[cryptography] Quality of HAVEGE algorithm for entropy?
smueller at chronox.de
Thu Nov 28 09:29:52 EST 2013
Am Donnerstag, 28. November 2013, 15:04:49 schrieb Jonas Wielicki:
> 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  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.
| Cui bono? |
More information about the cryptography