[Freedombox-discuss] Fwd: timer entropy
On 4 Oct 2011, at 16:22, Sandy Harris wrote:
> On Tue, Oct 4, 2011 at 8:36 PM, Frank <frank at debian-nas.org> wrote:
>
>> great to see efforts to create additional sources for entropy. I took the
>> liberty of reading the accompanying PDF paper in the FTP repository for
>> maxwell. In the paper the claim is made that HAVEGED is only
>> 'pseudo-random'.
>
> I did not intend to make that claim, more that Havege is /partly/
> pseudo-random.
>
> I do not know about Haveged, the Debian demon. I was going by, and
> quoting the documentation on the Havege web site:
> http://www.irisa.fr/caps/projects/hipsor/
>
> "HAVEGE [ HArdware Volatile Entropy Gathering and Expansion ]"
>
> "HAVEGE combines on-the-fly hardware volatile entropy gathering
> with pseudo-random number generation."
>
> As I read that, the "entropy gathering" is a true hardware RNG. The
> "and Expansion" part is pseudo-random.
>
>> Do you mean to say with that statement that the crucial difference between
>> HAVEGED and maxwell is, that maxwell never over-estimates the entropy it
>> seeds and HAVEGED potentially does?
>
> I hope that is true for maxwell(8), and give arguments in the paper that it is.
> The Havege entropy gathering is almost certainly better, since it uses more
> sources. Maxwell relies on a timer alone.
>
> To me, the "and expansion" and the description quoted imply that part
> of Havege is only pseudo-random.
Correct. The paper says
> In order to accommodate applications requiring very high volume of random numbers, we modified the HAVEG algorithm to generate on-the-fly random numbers through a very simple algorithm.
> HAVEGE (HArdware Volatile Entropy Gathering and Expansion) combines concurrent continuous hardware volatile entropy gathering with pseudoran- dom number generation. The presented implementation uses a very simple pseudorandom number generator: two concurrent self-modifying walks in a single table are run while the collected entropy continuously updates the walk table.
> That does not matter unless Haveged
> is being used to replace /dev/random for critical things like
> generating long-term PGP keys.
It's not obvious to me that this is correct in and of it's self. The HAVAGE algorithm appears to have a very short reseeding time in it's PRNG element, although I do wonder what happens when it has trouble generating entropy from it's external machine state sources.
It does seem like it would be extremely hard to bias or measure the entropy state in any meaningful way due to it's fundamental entropy source. I am not entirely sure that the same is true for maxwell. Clock jitter seems like the sort of thing that could be strongly influenced by TEMPEST attacks or measured by an unprivileged user to me.
> Even for critical apps, it might be just fine depending on how the
> pseudo-random part of Havege is designed, and exactly how and how
> often it is re-seeded from the truly random part. Generators like
> Yarrow (http://www.schneier.com/yarrow.html) have that sort of
> two-part design, and are thought highly secure. I have not looked at
> Havege at this level of detail, but the details are readily available
> -- Open Source code and several papers.
The HAVEGE paper actually explicitly references the work on Yarrow.
Reply to: