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 8FB0E46C21 for ; Wed, 5 Jul 2023 22:55:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C698168C397; Thu, 6 Jul 2023 01:54:56 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 28A3C68C5CA for ; Thu, 6 Jul 2023 01:54:50 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id 7F7B7FF805 for ; Wed, 5 Jul 2023 22:54:48 +0000 (UTC) Date: Thu, 6 Jul 2023 00:54:47 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230705225447.GT1093384@pb2> References: <20230702193010.11654-1-cus@passwd.hu> <54fe8899-d250-8d62-1157-621deb546040@gmail.com> <168841533190.542.8113031316523716543@lain.khirnov.net> <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> MIME-Version: 1.0 In-Reply-To: <168854896467.542.3745621457505615992@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="===============0471579596732715929==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0471579596732715929== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0WGqsT62A4RTsSXf" Content-Disposition: inline --0WGqsT62A4RTsSXf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 underlyin= g OS=20 > > > > > > provides, BCrypt for Windows, /dev/urandom for Linux, arc4rando= m() for=20 > > > > > > BSD/Mac. > > > > >=20 > > > > > IOW it's a jungle of various paths, some of which are not guarant= eed to > > > > > be cryptographically secure. I see no such guarantees for arc4ran= dom() > > > > > from a brief web search, and the fallback get_generic_seed() cert= ainly > > > > > is not either. Granted it's only used on obscure architectures, b= ut > > > > > still. > > > > >=20 > > > > > The doxy even says > > > > > > This function tries to provide a good seed at a best effort bas= es. > > > > >=20 > > > > > > You really think that these are significantly worse than > > > > > > OpenSSL/GCrypt, so it should not be allowed to fallback to? > > > > >=20 > > > > > I think we should be using cryptographically secure PRNG for gene= rating > > > > > 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. > > > >=20 > > > > "guarantees cryptographically secure randomness" ? > > > > If one defined "cryptographically secure" as "not broken publically= as of today" > > > >=20 > > > > Iam saying that as i think "guarantees" can be misleading in what i= t means > > >=20 > > > I feel your snark is very much misplaced. > > >=20 > >=20 > > > I recall way more instances of broken crypto caused by overconfident > > > non-experts with an attitude like yours ("those silly crypto librarie= s, > > > broken all the time, how hard can it be really") than by actual > > > vulnerabilities in actual crypto libraries. > > >=20 > > > 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. > >=20 > > 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 > >=20 > > 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 >=20 > 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 yea= rs just write it down on paper and burn and grind the paper when its not neede= d 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 numbe= rs is as good as not storing/transmitting or using bits from fliping a real fa= ir coin thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates --0WGqsT62A4RTsSXf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZKX0swAKCRBhHseHBAsP qwkDAJ95/0CvEYncnOb11/Itg8TOf+IFiwCfU9TVIFvaAwvnEPspOFKOr3He+9k= =hFu0 -----END PGP SIGNATURE----- --0WGqsT62A4RTsSXf-- --===============0471579596732715929== 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". --===============0471579596732715929==--