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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 5309 bytes --]

On Thu, Jul 06, 2023 at 09:52:12AM +0200, Anton Khirnov wrote:
> 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.

The litteral wording was
"that guarantees either cryptographically secure randomness or an error."

that was what i refered to.

the wording used now:
"to the best of our ability, and that of the underlying libraries we rely on) cryptographically secure."

is perfectly fine with me.
I would have the same issue if someone said AES gurantees ...

thx


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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