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 last > > 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 asked. > > 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 Ciao Stephan -- | Cui bono? | _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
