On Sun, 9 Jul 2023, James Almer wrote:

On 7/9/2023 1:23 PM, Marton Balint wrote:


 On Sun, 9 Jul 2023, Anton Khirnov wrote:

 Quoting Marton Balint (2023-07-07 22:02:26)


 On Fri, 7 Jul 2023, Anton Khirnov wrote:

 It is a better interface for /dev/u?random on Linux, which avoids the
 issues associated with opening files.


 getrandom() actually have the same problem as read(). It can read less
 than requested. So you should use it in a loop in that case or if it
 returns EINTR.

 I'm not convinced it's actually a problem.

 This API is intended for small secrets like keys and such, somebody
 trying to generate vast quantities of random data is likely misusing it
 and could just as well use LFG or something.

 Failing in that case seems like a good thing to me.

 This is a very bad argument. If the API should not be used for big
 secrets, then it should always fail for size > 256 or something, not
 sometimes fail. And such limitation should be documented.

 And its not just about big secrets. EINTR can be returned for small
 secrets as well, and you should handle it.

 I also question if it is a good idea to use the non blocking mode. Imagine
 a situation when somebody wants to automatically start a command line
 after boot which needs a key. It might fail right after boot, but will
 work after a couple of minutes. IMHO it is better to block (1-2 minute
 tops) than making the function sometimes work, sometimes not.

If we make the urandom/getrandom() path block and potentially take 1-2 minutes, then I'd prefer if it's last in the function, after all available external implementations (Some of which can fail) were tried first.

It will take 1-2 minutes if it is right after boot and if the system has no support for quickly gathering entropy via some hardware feature...

So it is not like /dev/random. It only waits until the CSPRNG of /dev/urandom initializes. I doubt external libraries can come up something significantly quicker, since they are also using the same system provided randomness for initialization...

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Reply via email to