[FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers
Martin Storsjö
martin at martin.st
Fri Feb 7 00:04:53 EET 2025
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
More information about the ffmpeg-devel
mailing list