Re: [PATCH 0/5] Feed entropy pool via high-resolution clocksources
From: Jarod Wilson <hidden>
Date: 2011-06-17 18:52:13
Matt Mackall wrote:
On Wed, 2011-06-15 at 10:49 -0400, Jarod Wilson wrote:quoted
Matt Mackall wrote:quoted
On Tue, 2011-06-14 at 18:51 -0400, Jarod Wilson wrote:quoted
Matt Mackall wrote:...quoted
quoted
quoted
But that's not even the point. Entropy accounting here is about providing a theoretical level of security above "cryptographically strong". As the source says: "Even if it is possible to analyze SHA in some clever way, as long as the amount of data returned from the generator is less than the inherent entropy in the pool, the output data is totally unpredictable." This is the goal of the code as it exists. And that goal depends on consistent _underestimates_ and accurate accounting.Okay, so as you noted, I was only crediting one bit of entropy per byte mixed in. Would there be some higher mixed-to-credited ratio that might be sufficient to meet the goal?As I've mentioned elsewhere, I think something around .08 bits per timestamp is probably a good target. That's the entropy content of a coin-flip that is biased to flip heads 99 times out of 100. But even that isn't good enough in the face of a 100Hz clock source. And obviously the current system doesn't handle fractional bits at all.What if only one bit every n samples were credited? So 1/n bits per timestamp, effectively, and for an n of 100, that would yield .01 bits per timestamp. Something like this:Something like that would "work", sure. But it's a hack/abuse -relative to the current framework-. I'm reluctant to just pile on the hacks on the current system, as that just means getting it coherent is that much further away.
Something I should have probably made clearer was that we were looking for a semi-quick improvement for a particular use case that involves a certain 2.6.32-based kernel... For the short term, we're looking at some userspace alternatives, such as a Linux implementation of an entropy seed approach BSI approves of. Reference doc here, but in German: https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Longer-term, we're having some discussions related to the revamped framework you've laid out. I'll table this clocksource-based entropy contribution code for now. Also, thank you for putting up with me. ;) -- Jarod Wilson jarod@redhat.com