From owner-svn-src-all@freebsd.org Sun Apr 16 12:13:25 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A52ACD41C7D; Sun, 16 Apr 2017 12:13:25 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 753FA9F3; Sun, 16 Apr 2017 12:13:25 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88 (FreeBSD)) (envelope-from ) id 1czj3S-000Q0o-Nf; Sun, 16 Apr 2017 13:13:24 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys From: Mark R V Murray In-Reply-To: <201704161207.v3GC7adp016485@pdx.rh.CN85.dnsmgr.net> Date: Sun, 16 Apr 2017 13:13:22 +0100 Cc: src-committers , svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <60A59E27-47CD-4552-8265-0E60C09E1966@FreeBSD.org> References: <201704161207.v3GC7adp016485@pdx.rh.CN85.dnsmgr.net> To: rgrimes@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-SA-Score: -1.0 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 12:13:25 -0000 > On 16 Apr 2017, at 13:07, Rodney W. Grimes = wrote: >=20 >>> =46rom replacing the rc4 algorithm with chacha20, this chalice has = now >> become poisoned with the job of redesigning the entire structure of >> kernel random-number generation. >>=20 >> This may take a while, and I'm already behind on RNG jobs. >=20 > I do not see how this is a complete redesign of RNG, and if it is > such a heart ache to change algorithms in this code then it probably > should be redesigned? The RC4 algorithm is standard. Making the alogorithm pluggable means = more code, more testing and more time (time which I am rather short of). > Also you can always compile in a module, you can not compile out > a 'standard' file. >=20 > For now could you just add > options chacha #Required by arc4random, do not remove > to your kernel and move on? For me this would be an acceptable > developement, even releasable, way to proceed while the more > complex issue of how to make the kernel RNG use plagable lkm > lower layers. It would have to be unconditionally added to *all* kernels. Could be done, I guess. RC4 has been standard for many years. >>> I am sure with careful though we can find a way to allow arc4random >>> to use a pointer that knows if the chacha code is avaliable, and use >>> it if so, and if not fall back to something else, or punt with an >>> error return. >>=20 >> Error return is out of the question; arc4random() is pretty = fundamental. >> The alternative is to return no or fake random numbers, which rather >> misses the point of what this is for. But it can be done. >=20 > Arc4random works today without chacha, why would adding support for = chache > as an optional loadable function break that? *truely confused* Up until now, arc4random worked with unconditional RC4. M --=20 Mark R V Murray