From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 25 Aug 2020 19:10:29 +0200 (CEST) Date: Tue, 25 Aug 2020 10:10:26 -0700 From: Eric Biggers Message-ID: <20200825171026.GA8389@sol.localdomain> References: <20200825024450.GB810@sol.localdomain> <20200825145929.GA2811@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200825145929.GA2811@tansi.org> Subject: Re: [dm-crypt] Encryption speed and reversing the direction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arno Wagner Cc: dm-crypt@saout.de, John Lee McMahon On Tue, Aug 25, 2020 at 04:59:29PM +0200, Arno Wagner wrote: > On Tue, Aug 25, 2020 at 04:44:50 CEST, Eric Biggers wrote: > > On Tue, Aug 25, 2020 at 02:05:35AM -0400, John Lee McMahon wrote: > [...] > > Also if you actually care about random number generation performance, you > > shouldn't be going through the kernel at all, except to read an initial > > seed. > [...] > > Not anymore. /dev/urandom has pretty good performance now. > On my very old Phenom II fileserver, I get about 270MB/sec > with a 5.x kernel. Sure, just using /dev/urandom (or getrandom()) should be the first choice. I was talking about the rare case where those still aren't fast enough. - Eric