Re: cprng_fast implementation benchmarks

On Apr 22, 2014, at 11:59 PM, Thor Lancelot Simon <[email protected]> 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