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

[Conrad Meyer]

Furthmore:

chacha20.ko: 7 kB
GENERIC w/out chacha20: 27095416
GENERIC w/ chacha20: 27097976

device chacha20 adds 2560 *bytes* to the kernel.  That's +0.009%.  Not
worth bikeshedding about.

Best,
Conrad



On Sun, Apr 16, 2017 at 7:26 AM, Conrad Meyer <cem at freebsd.org> 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?
>
> 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