Re: [PATCH 0/5] Feed entropy pool via high-resolution clocksources

[Matt Mackall <mpm@selenic.com>]

On Fri, 2011-06-17 at 15:29 -0400, Neil Horman wrote:
> On Fri, Jun 17, 2011 at 02:51:31PM -0400, Jarod Wilson wrote:
> > Matt Mackall wrote:
> > >On Wed, 2011-06-15 at 10:49 -0400, Jarod Wilson wrote:
> > >>Matt Mackall wrote:
> > >>>On Tue, 2011-06-14 at 18:51 -0400, Jarod Wilson wrote:
> > >>>>Matt Mackall wrote:
> > >>...
> > >>>>>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. ;)
> > 
> Not to prolong this conversation, but Matt, since you seem talkative about it,
> has any consideration been given to using a periodically reseeded DRNG as an
> input to the entropy pool?  some of the papers that Jarod referenced in this
> thread suggest that using the tsc entropy as a reseed factor to a drng can
> provide a good non-predictable source of entropy.

Yep. But just about everything we're talking about in this thread has to
come after a redesign of the RNG's input side, which at present is
simply no good for weak sources.

-- 
Mathematics is the supreme nostalgia of our time.