Date: Sun, 16 Apr 2017 05:30:56 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Mark R V Murray <markm@freebsd.org> Cc: rgrimes@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys Message-ID: <201704161230.v3GCUujl016578@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <60A59E27-47CD-4552-8265-0E60C09E1966@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On 16 Apr 2017, at 13:07, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > > > >>> From 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. > >> > >> This may take a while, and I'm already behind on RNG jobs. > > > > 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). I would rather see a proper implementation later, than a poor design decision today. > > Also you can always compile in a module, you can not compile out > > a 'standard' file. > > > > 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. We dont have that many in base kernel configs do we? > RC4 has been standard for many years. Probably another rapid mode of design rather than a thoughful mode, we have a chance to correct this here, and imho, should. > >>> 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. > >> > >> 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. > > > > 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. And your wanting to just replace unconditional RC4 for unconditional chacha? Or actuall, aleady did? -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704161230.v3GCUujl016578>