tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Towards design criteria for cprng_fast()



Thor Lancelot Simon <tls%panix.com@localhost> 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


Home | Main Index | Thread Index | Old Index