On Tue, 4 Jul 2023, James Almer wrote:
On 7/3/2023 6:52 PM, Marton Balint wrote:
On Mon, 3 Jul 2023, 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()
It depends on OS and version most likely.
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.
I am no expert on the subject, but even the generic code seems reasonably
secure. It gathers entropy, it uses a crypto hash to get the output. And
as you said, even that only used for obscure cases.
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.
Sorry, seems a bit overdesign for me, so I won't be pursuing this further.
I just sent a patchset implementing a new av_random() function that uses the
existing av_get_random_seed() entropy sources, and adds the ones used by
hlsenc too.
If that goes in, then this patchset can go in as well afterwards.
Thanks! I will rework the patch to use av_random() then.
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".
