Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers

["Martin Storsjö" <martin@martin.st>]

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.

> } 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

It still executes in reasonable amount of time; my patch now looks like 
this:

         if (t == last_t) {
             repeats[0]++;
         } else {
             // If we got a new unique number of repeats, update the history.
             // (We don't need to check repeats[2]; if it is equal to the new
             // value we'll end up keeping the same two values as before, in
             // opposite order.
             if (repeats[0] != repeats[1]) {
                 repeats[2] = repeats[1];
                 repeats[1] = repeats[0];
             }
             repeats[0] = 0;
         }

// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".