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

[Jarod Wilson <jarod@redhat.com>]

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. ;)

-- 
Jarod Wilson
jarod@redhat.com