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 BADA846B84 for ; Tue, 4 Jul 2023 05:54:15 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7661F68C5A4; Tue, 4 Jul 2023 08:54:13 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5986F680534 for ; Tue, 4 Jul 2023 08:54:07 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 057F52404EC for ; Tue, 4 Jul 2023 07:54:07 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VGVKwxzwFu8n for ; Tue, 4 Jul 2023 07:54:06 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 4703C2404EA for ; Tue, 4 Jul 2023 07:54:06 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 2B7C51601B2; Tue, 4 Jul 2023 07:54:06 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20230703235057.GQ1093384@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> Mail-Followup-To: FFmpeg development discussions and patches Date: Tue, 04 Jul 2023 07:54:06 +0200 Message-ID: <168845004614.542.18132678959456829324@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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. -- Anton Khirnov _______________________________________________ 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".