From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id BCEFE46CD1 for ; Fri, 7 Jul 2023 14:43:07 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A05A968C688; Fri, 7 Jul 2023 17:43:04 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3656A68C65E for ; Fri, 7 Jul 2023 17:42:58 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id 4E7881C0003 for ; Fri, 7 Jul 2023 14:42:57 +0000 (UTC) Date: Fri, 7 Jul 2023 16:42:56 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230707144256.GW1093384@pb2> References: <4b0740-7b32-415b-47af-3199463854b@passwd.hu> <168841859463.9711.12513000520212201640@lain.khirnov.net> <20230703235057.GQ1093384@pb2> <168845004614.542.18132678959456829324@lain.khirnov.net> <20230704235012.GS1093384@pb2> <168854896467.542.3745621457505615992@lain.khirnov.net> <20230705225447.GT1093384@pb2> <168862993295.542.15593141999950137681@lain.khirnov.net> <20230707005546.GV1093384@pb2> <168871715065.542.16772150579352770511@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: <168871715065.542.16772150579352770511@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============7624667118357913624==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7624667118357913624== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AFjAQ8ujNJnIGHaX" Content-Disposition: inline --AFjAQ8ujNJnIGHaX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 07, 2023 at 10:05:50AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-07-07 02:55:46) > >=20 > > The litteral wording was > > "that guarantees either cryptographically secure randomness or an error= =2E" > >=20 > > that was what i refered to. > >=20 > > the wording used now: > > "to the best of our ability, and that of the underlying libraries we re= ly on) cryptographically secure." > >=20 > > is perfectly fine with me. > > I would have the same issue if someone said AES gurantees ... >=20 > 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 lib= s 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 [...] --=20 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. --AFjAQ8ujNJnIGHaX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZKgkbAAKCRBhHseHBAsP q3RhAJ9LqAHPkeB/6NH0QRbJwlhIGbFmMgCfaL1lf3KHSFmTbsLlvsvmL0QS+TI= =OY+q -----END PGP SIGNATURE----- --AFjAQ8ujNJnIGHaX-- --===============7624667118357913624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============7624667118357913624==--