On Sun, Apr 16, 2017 at 2:19 AM, Mark R V Murray <ma...@freebsd.org> wrote: > This does not use DES' Chacha20 commit, as I had already completed the > testing for it, and received SO@ approval. > > DES's commit made Chaha20 a module. This is of no use to arc4random(9), > which needs the code to be standard. Also his API is different. > > I have no objection to reworking the arc4random/Chacha below to use DES' > version of Chacha, but his code needs to be standard library code, > not an optional module. > > Any objections to me doing this?
Hi Mark, I think you've taken the only sane approach possible here. arc4random cannot be loadable, and it needs a standard cipher. RC4 is undesirable because large parts of its early keystream are predictable and it is anticipated to have other weaknesses. I doubt Chacha comes out to much in the way of object code, and removing RC4 should subsidize even that number. From AMD64: chacha20.ko is 7 kB. Furthermore, I do not believe you should be harangued into rewriting how RNG use works in the kernel just to allow Chacha to be loadable. And if it is "loadable," so what? You can't boot without it; what good does a mandatory loadable module do? So: * I believe you've taken the right approach. But somehow your import of chacha should be reconciled with DES' import (i.e., keep only one copy in the tree). * I don't believe the chacha code being standard is an undue burden. Especially balanced by kicking out RC4. Thanks for doing this work. Best, Conrad _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
