On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsjö wrote:
> On Thu, 6 Feb 2025, Michael Niedermayer wrote:
> 
> > > +            // If the timer resolution is high, and we get the same timer
> > > +            // value multiple times, use variances in the number of repeats
> > > +            // of each timer value as entropy. If the number of repeats changed,
> > > +            // proceed to the next index.
> > 
> > Does it still work if you check against the last 2 ?
> > or does this become too slow ?
> > What iam thinking of is this
> > 
> > 7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,... and a 9 or 6 or further distant would trigger it
> > 
> > I assume both the CPU clock and the wall time are quite precisse so if we
> > just compare them the entropy could be low even with 2 alternating values
> 
> Yes, that still works for making it terminate in a reasonable amount of
> time. I updated the patch to keep track of 3 numbers of repeats, and we
> consider that we got valid entropy once the new number of repeats is
> different from the last two.
> 
> So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the last
> one, we have old repeats 8 and 8, and the new repeat count 7, which in that
> context looks unique.

I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used
values not 8,8
that is, something like:

if (old2 == new) {
    FFSWAP(old,old2);
} else if (old != new) {
    old2 = old;
    old = new;
}

but again, iam not sure this will work or just need too much time to gather
enough entropy

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.