In message <20030911224353.GA16365@rek.tjls.com>Thor Lancelot Simon writes
>On Fri, Sep 12, 2003 at 07:24:50AM +0900, Jun-ichiro itojun Hagino wrote:

[...]

>Almost every piece of this code, right back to the original
>arc4random() implementation, has had performance issues, and some of it
>has had security issues as well.  


Which is as good a time as any to raise another point which has been
bugging me for some time: NetBSD's pseudo-random number subsystem is
not up to contemporary standards.  I have two or three over-riding concerns:

1. We need some way to harvest the immediate output of (alleged) TRNG
hardware, in order to perform statistical checks on the distribution
of the output of the hardware random number generators.

2. We need better kernel APIs for randomness, that can distinguish
FIPS-quality random-number sources from non-FIPS quality.


3. Imposing arc4random() as a sole generator key material is, for many
 environments,  simply not acceptable.

(if dim memory serves, we got arc4 random(), over specific, explicit
objections that calling arc4random() by name was not appropriate; we
should have distinguished and separated, at least the following cases:

  a) ``please give me a fast PRNG and I don't care what the algorithm is''
  b) ``please give me a PRNG suitable for cryptographic purposes (key material''


Just for myself: arc4random() for key-material generation must die.  I
want FIPS 186-2 quality keys, and i want them *now*. If others can
life with arc4random(), then it has to be configurable (maybe by
sysctl, sysctl not changeable at high security levels? Thor?)  I have
no idea how to handle change-control with KAME, but we have to figure
out some solution in the immediate future.


(Of course at that juncture, just coping OpenBSD keymat changes is
simply Not An Option.)