On 04/16/17 09:26, Conrad Meyer wrote:
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?
FWIW, I would think the major advantage of making Chacha a
module would be making us cipher-agnostic. The end user doesn't
need to know what cypher is being used. It would still be mandatory
to use *a* cypher and chacha20 would be the default.
This said, I am fine with markm's approach and, not that it matters,
in most "sane" jurisdictions Public Domain is less restricted than
3-Clause BSD.
Pedro.
_______________________________________________
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"
