Change arc4random(9) over to using 3-BSD licensed Chacha20.

[markm]

Summary

Change arc4random(9) over to using 3-BSD licensed Chacha20.

Test Plan

Lots of temporary printfs.

[rgrimes]

I've been swayed that this is a short path to a solution for now, but still would like to see the arc4random eventually updated to allow for the crypto funtion use be pluggable and selectable without a kernel recompile.

I have also found that chacha is documented in RFC7539 and would like to ask have we made sure that we are conformant with the RFC?
I am especially concerned that the RFC says certain things shall be Little Indian, have we wrapped stuff in appropriate XtoX so that the functions in our chacha implemtation are always little indian, or documented the API clearly stating that as such? I know the chacha code
is not in this diffential, but those with there eyes on it are here, des/markm please lets make sure to document this indianess and make sure that the different arches have the right call wrappers if needed.

Thanks

[des]

sys/libkern/arc4random.c

105

The key length is in bytes, not bits.

134

This is something I didn't catch in the initial patch: you can't call your code chacha20. It is not chacha20. You can call it chacha20random or cc20rand something similar, preferably something that doesn't refer to a specific algorithm (e.g. fastrand) but not chacha20, because that's already the name of the cipher.

[des]

In D10440#216630, @rgrimes wrote:

I have also found that chacha is documented in RFC7539 and would like to ask have we made sure that we are conformant with the RFC? [...]

To be blunt, I find that question mildly insulting. The short answer is yes.

[des]

In D10440#216635, @des wrote:

In D10440#216630, @rgrimes wrote:

I have also found that chacha is documented in RFC7539 and would like to ask have we made sure that we are conformant with the RFC? [...]

To be blunt, I find that question mildly insulting. The short answer is yes.

Rod, I owe you an apology. The code to update the counter is wrong. Thank you for annoying me enough to make me double-check :) I have a patch ready to commit as soon as it passes unit tests.

EDIT: of course, now I can no longer reproduce the bug, and the only BE machine I have access to is so slow it's not even funny.

[des]

I found and fixed the counter bug last night.

BTW, this implementation complies with the original version of ChaCha, not the one described in RFC 7539. Assuming the caller will rekey before consuming 2^38 bytes of keystream (which it should do anyway, and the RFC clearly says so), the latter can be implemented without sacrificing the former by simply adding an alternate chacha20_reset() that takes a 96-bit nonce instead of a 64-bit nonce.

[markm]

DES,

(from hospital bed)

If you want to go ahead and replace the arc4random(9)'s chacha, please be my guest!

M

[markm]

Overcome By Events.