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

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
Date: Fri, 7 Jul 2023 16:42:56 +0200
Message-ID: <20230707144256.GW1093384@pb2> (raw)
In-Reply-To: <168871715065.542.16772150579352770511@lain.khirnov.net>

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

On Fri, Jul 07, 2023 at 10:05:50AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-07-07 02:55:46)
> > 
> > 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 ...
> 
> IMO the two formulations are equivalent whenever it comes to practical
> computing. An algorithm can be mathematically proven to be sound*, but
> any practical computing scheme on actual hardware is always subject to
> software bugs, system misconfiguration, hardware bugs, hardware failure,
> etc.
>

> We use similar wording in other documentation, where e.g. we might
> guarantee that some function returns a NULL-terminated string or so.
> That guarantee is always under the implicit condition that there are no
> bugs and the code runs in the expected environment. The same
> considerations apply here.

Theres a big difference between a bug in our implementation
And us claiming some cryptographic primitive is secure.
It was said previously that we shouldnt do things we lack the experties
on and rather delegate to cryptographic libraries writen and audited by
experts. (where it matters for security not just for playback)
But claiming CSPRNG or AES or anything else is guranteed secure is
exactly such a claim that is not within our experties.

If you claim your code produces a null terminated string that i believe
you (within the bounds you mentioned) but if you tell me AES will always
be secure i wont believe you that unless you have the mathemtical proofs
to back that up (and i read and understood them).

Now all that flawlessness with security primitives from proper security libs and
stuff needs to be taken with a grain of salt too.
just 4 months ago i found 2 issues with teh random number generator in the hardware
password manager that i use.
So yeah maybe people feels iam too nitpicky here but honestly id rather be nitpicky
on security stuff

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.

[-- 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".