On Apr 22, 2014, at 11:59 PM, Thor Lancelot Simon <t...@panix.com> wrote:
> ... > RESULTS > > kernel cpb (32 bit) 4GB (1 way) 16GB (4 ways) Scaling > Factor > ------ ------------ ----------- ------------- > -------------- > arc4-mtx 35 42.58 398.83 0.106 > arc4-nomtx 24 42.12 2338.92 0.018 > arc4-percpu 27 33.63 41.59 0.808 > hc128-percpu 21 23.75 34.90 0.680 > hc128-inline 19 22.66 31.75 0.713 > chacha8 22 20.51 30.45 0.662 > chacha12 24 24.87 34.32 0.724 > chacha20 28 30.45 39.28 0.775 > > I believe ChaCha8 is suitable for our purpose: we were previously considering > ciphers with, at most, 128-bit security, and even 6-round ChaCha has 139-bit > strength against the best currently known attack (at present, there is no > attack better than brute force on ChaCha8, and the best attack on ChaCha7 > is 2^248). ChaCha8 appears to be somewhat faster than the old arc4 > implementation. I’ve been watching this long stream of messages flying by, and I’m a bit concerned about the approach. As I understand it, there is a strong RNG, based on RC4 (“ARC4”) in the kernel today. It is used by some things that require strong random numbers, and also by things that don’t (or at most, have weaker requirements than the cryptographic operations that require serious strength). It isn’t clear to me what fraction of the workload really requires the cryptographically strong generator. Replacing the existing strong generator by a new one that is faster is tempting. The question is: how much confidence do you need in the new algorithm? For things like port randomization, not much. One might argue that a PRNG is fine for that. On the other hand, for those spots where cryptographic random numbers are required, a lot. It isn’t at all clear to me that the proposed replacements are sufficiently well analyzed. If someone were to propose a replacement whose security is demonstrably that of the AES block cipher, I’d be a whole lot more comfortable, because AES is one of the very few cryptosystems out there that has had significant analysis. (RC4 may be another, though in that case there have been some results that raise concern.) It would probably also be useful to identify the various uses of kernel RNGs, and document clearly what their security requirements (if any) are. paul