> On 16 Apr 2017, at 13:07, Rodney W. Grimes <free...@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). > 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. 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. >> >> 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. M -- Mark R V Murray _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
