Page MenuHomeFreeBSD

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

Authored by markm on Apr 20 2017, 7:22 PM.

Details

Summary

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

Test Plan

Lots of temporary printfs.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8818
Build 9190: arc lint + arc unit

Event Timeline

markm created this revision.Apr 20 2017, 7:22 PM
rgrimes edited edge metadata.Apr 21 2017, 4:01 AM

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 requested changes to this revision.Apr 21 2017, 6:35 AM
des added inline comments.
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.

This revision now requires changes to proceed.Apr 21 2017, 6:35 AM
des added a comment.Apr 21 2017, 6:38 AM

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 added a comment.EditedApr 21 2017, 6:35 PM
In D10440#216635, @des 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 added a comment.Apr 22 2017, 5:25 PM

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 added a comment.Sep 8 2017, 10:00 AM

DES,

(from hospital bed)

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

M

markm abandoned this revision.Mar 1 2019, 10:03 AM

Overcome By Events.