svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys

[Pedro Giffuni]

On 04/16/17 09:26, Conrad Meyer wrote:
> On Sun, Apr 16, 2017 at 2:19 AM, Mark R V Murray <markm at 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.