Re: cprng_fast implementation benchmarks

[<Paul_Koning%Dell.com@localhost>]

On Apr 22, 2014, at 11:59 PM, Thor Lancelot Simon <tls%panix.com@localhost> 
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