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

[Anton Khirnov]

Quoting Michael Niedermayer (2023-07-06 00:54:47)
> On Wed, Jul 05, 2023 at 11:22:44AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-07-05 01:50:12)
> > > On Tue, Jul 04, 2023 at 07:54:06AM +0200, Anton Khirnov 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.
> > > 
> > > There is no snark here, at least that was not the intend
> > > Also what you say in these 2 paragraphs is true but isnt really
> > > related to what i said or meant to say
> > > 
> > > these cryptographically secure PRNGS are secure as long as the
> > > currently used components and assumtations they are build on havnt
> > > been broken.
> > > Can i do better? no. but that doesnt mean that these
> > > are going to be unbroken in 30 years.
> > > just look 30 years in the past what percentage of what was believed to
> > > be secure 30 years ago has been broken today. or 50 or 100years
> > > thats really what i meant
> > 
> > I still don't see what point are you trying to make here.
> > Yes, any practical cryptographic algorithm could potentially be broken
> > at some point. And everything in real life is imperfect, because we do
> > not live in the world of ideal forms.
> 
> > But I don't see what practical steps could or should be taken in
> > response to this.
> 
> for us i dont know but a user could
> instead of putting critical data in a system that might be broken in 30 years
> just write it down on paper and burn and grind the paper when its not needed anymore
> (which may or may not be an option)
> 
> nothing is perfect but there are methods to transfer and destroy data which have a
> long track record of being secure and are simple.
> 
> I think we should not make it sound like encrypting with these random numbers
> is as good as not storing/transmitting or using bits from fliping a real fair coin

We are not claiming that. We are claiming that the random numbers
generated are (to the best of our ability, and that of the underlying
libraries we rely on) cryptographically secure. This means suitable for
use in state of the art cryptographic algorithms like AES.
I do not think it makes sense to mistrust CSPRNGs, yet still trust AES.

-- 
Anton Khirnov