20.09.2019 03:23, Alexander E. Patrakov пишет:
20.09.2019 02:47, Linus Torvalds пишет:On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov <patrakov@xxxxxxxxx> wrote:This already resembles in-kernel haveged (except that it doesn't credit entropy), and Willy Tarreau said "collect the small entropy where it is, period" today. So, too many people touched upon the topic in one day, and therefore I'll bite.I'm one of the people who aren't entirely convinced by the jitter entropy - I definitely believe it exists, I just am not necessarily convinced about the actual entropy calculations. So while I do think we should take things like the cycle counter into account just because I think it's a a useful way to force some noise, I am *not* a huge fan of the jitter entropy driver either, because of the whole "I'm not convinced about the amount of entropy". The whole "third order time difference" thing would make sense if the time difference was some kind of smooth function - which it is at a macro level. But at a micro level, I could easily see the time difference having some very simple pattern - say that your cycle counter isn't really cycle-granular, and the load takes 5.33 "cycles" and you see a time difference pattern of (5, 5, 6, 5, 5, 6, ...). No real entropy at all there, it is 100% reliable. At a macro level, that's a very smooth curve, and you'd say "ok, time difference is 5.3333 (repeating)". But that's not what the jitter entropy code does. It just does differences of differences. And that completely non-random pattern has a first-order difference of 0, 1, 1, 0, 1, 1.. and a second order of 1, 0, 1, 1, 0, and so on forever. So the "jitter entropy" logic will assign that completely repeatable thing entropy, because the delta difference doesn't ever go away. Maybe I misread it.You didn't. Let me generalize and rephrase the part of the concern that I agree with, in my own words:The same code is used in cryptoapi rng, and also a userspace version exists. These two have been tested by the author via the "dieharder" tool (see the message for commit d9d67c87), so we know that on his machine it actually produces good-quality random bits. However, the in-kernel self-test is much, much weaker, and would not catch the situation when someone's machine is deterministic in a way that you describe, or something similar.
A constructive suggestion here would be to put the first few thousands (ok, a completely made up number) raw timing intervals through a "gzip compression test" in addition to the third derivative test, just based on what we already have in the kernel.
-- Alexander E. Patrakov
Attachment:
smime.p7s
Description: Криптографическая подпись S/MIME
