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