Hi Martin

On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsjö wrote:
> On Thu, 6 Feb 2025, Michael Niedermayer wrote:
> 
> > 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
> 
> Sure, that's probably doable too.
> 
> > that is, something like:
> > 
> > if (old2 == new) {
> >    FFSWAP(old,old2);
> 
> I don't see why we'd need to check this if clause at all, it seems to me
> that it's enough to have the "if (old != new)" case.

> If we have old2 == new,
> we'd just end up with old2 = old, and old = (previous old2 value) anyway.

It was intended to be a least recent used check with 2 entries

If we have a clock running and sample that in precise intervalls
lets say the clock runs at 1.9hz and we sample at 10hz we would get

clock:    0  0  0  0  0  0  1  1  1  1  1  2  2  2  2  2  3  3  3  3  3  3  4  4  4  4  4  5  5  5  5  5  6  6  6  6  6  7  7  7  7  7  7  8  8  8  8  8  9  9
difference:  0  0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  1  0  0  0  0  0  1  0  0  0  0  1  0

Above adds no entropy after the initial entropy, this can be read forever
it will not improve randomness

here we have runs of repeated clock reads of 5,4,4,5,4,4,4,5,4
again we can read this as long as we want there is no entropy gained
so after a 5,4,4,4 if a 5 happens thats not breaking the pattern and should
not be counted as new entropy (if possible)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.