Hi! > > So you are relying on high-resolution timestamps. Ok. then you do kind > > of the check on the timestamps... ok, why not. But then you mix in the > > data regardless, saying that "they are not dependent" and thus can't > > hurt. > > > > But you already know they _are_ dependent, that's what your stuck test > > told you: > > The stuck test says that there is a pattern, but not that the pattern shows a > dependency. ... > > Now. I could imagine cases where interrupts are correlated... like > > some hardware may generate two interrupts for each event or something > > like that... > > But I see what you are referring to and I think you have a valid point in a > worst case assessment. > > Thus, any stuck value should not be mixed into the pool. Thanks. > /* This RNG does not work if no high-resolution timer is available */ > BUG_ON(!random_get_entropy() && !random_get_entropy()); Heh, does this cause BUG() with 2^-64 probability? :-). > If there is no high-resolution timer, the LRNG will not produce good entropic > random numbers. The current kernel code implements high-resolution timers for > all but the following architectures where neither random_get_entropy nor > get_cycles are implemented: Ok, what about stuff like Intel 486 (no RDTSC)? > Thus, for all large-scale architectures, the LRNG would be applicable. > > Please note that also the legacy /dev/random will have hard time to obtain > entropy for these environments. The majority of the entropy comes > from high- Understood. > Though, the patch I offer leaves the legacy /dev/random in peace for those > architectures to not touch the status quo. Well -- that's the major problem -- right? Makes it tricky to tell what changed, and we had two RNGs to maintain. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
