Re: Towards design criteria for cprng_fast()

Thor Lancelot Simon <[email protected]> wrote:
> I would like to offer some observations about the use of cprng_fast()
> (once known as arc4random()) in our kernel and, from these, express
> what I believe are reasonable design criteria for that function.
> 
> O1) cprng_fast() is used in some performance-critical parts of the kernel:
> 
> 	<...>
> 
> 	D) It appears that it can be called per-packet by a few parts of
> 	   the networking stack in some cases -- ALTQ, possibly ip_id.

Port number randomisation as well, which is another frequent user.

> O4) We have non-cryptographic RNGs in the kernel (random(), mertwist))
> which seem to exist for two reasons: reproducible testing, and
> performance.

What is their real use?  They cause confusion; irresponsible use of them
may cause problems, and cprng_fast ought to be fast enough.  I strongly
suggest to delete them.

> With those observations in mind, I offer these design criteria for
> cprng_fast():
> 
> 	Strength criterion: At the time of the selection of an algorithm
> 			      for cprng_fast(), there should be no known,
> 			      practical cryptographic attack which either:
>       <...>
> 
> 	Speed criterion 1: cprng_fast() should be as fast as possible
> subject to the Strength criterion and the general mandates
> 			   of portability and code cleanliness which apply
> 			   throughout our tree.
> 	<...>
> 
> 	Speed criterion 2: cprng_fast()'s performance should be evaluated
> 			   primarily with regard to short requests.
>       <...>

I agree.

-- 
Mindaugas