On Tue, 4 Jul 2023 at 06:54, Anton Khirnov <an...@khirnov.net> wrote:
> Quoting Michael Niedermayer (2023-07-04 01:50:57) > > On Mon, Jul 03, 2023 at 11:09:54PM +0200, Anton Khirnov wrote: > > > Quoting Marton Balint (2023-07-03 22:54:41) > > > > On Mon, 3 Jul 2023, Anton Khirnov wrote: > > > > My patch use av_get_random_seed() which uses what the underlying OS > > > > provides, BCrypt for Windows, /dev/urandom for Linux, arc4random() > for > > > > BSD/Mac. > > > > > > IOW it's a jungle of various paths, some of which are not guaranteed to > > > be cryptographically secure. I see no such guarantees for arc4random() > > > from a brief web search, and the fallback get_generic_seed() certainly > > > is not either. Granted it's only used on obscure architectures, but > > > still. > > > > > > The doxy even says > > > > This function tries to provide a good seed at a best effort bases. > > > > > > > You really think that these are significantly worse than > > > > OpenSSL/GCrypt, so it should not be allowed to fallback to? > > > > > > I think we should be using cryptographically secure PRNG for generating > > > encryption keys, or fail when they are not available. If you want to > get > > > rid of the openssl dependency, IMO the best solution is a new > > > int av_random(uint8_t* buf, size_t len); > > > that guarantees either cryptographically secure randomness or an error. > > > > "guarantees cryptographically secure randomness" ? > > If one defined "cryptographically secure" as "not broken publically as > of today" > > > > Iam saying that as i think "guarantees" can be misleading in what it > means > > I feel your snark is very much misplaced. > > I recall way more instances of broken crypto caused by overconfident > non-experts with an attitude like yours ("those silly crypto libraries, > broken all the time, how hard can it be really") than by actual > vulnerabilities in actual crypto libraries. > > In fact the highest-profile break I remember (Debian key entropy bug) > was caused precisely by non-experts fiddling with code they did not > understand. > +1 Kieran _______________________________________________ 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".