[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key

[James Almer]

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.