CVS commit: syssrc/sys/lib/libkern

[Thor Lancelot Simon <tls%netbsd.org@localhost>]

Module Name:    syssrc
Committed By:   tls
Date:           Sun Oct  6 06:47:40 UTC 2002

Modified Files:
        syssrc/sys/lib/libkern: arc4random.c

Log Message:
This commit includes two major changes:

1) Speed up arc4random().  We make arc4randbyte() inline, which makes this
   not much slower than, say, the other arc4 implementation in our kernel.

   We also replace four calls to arc4randbyte() with a loop, saving about
   20% on some processors where the "unrolled" arc4randbyte() calls would
   needlessly stomp the cache.

2) Address various problems with the initialization/"stirring" code,
   primarily in the area of handling of the source data from the kernel
   entropy pool.  We used to:

        a) Ask the entropy pool for 32 bytes

        b) If we got zero bytes, key with junk from the stack (ouch!)
           which has some nasty implications, to say the least.  For
           example, we're most likely to get zero bytes at boot time,
           when the stack contents are even more predictable than usual.

        c) If we got less than 32 bytes but more than zero bytes, use
           however many bytes we got as the arc4 key, copying it
           repeatedly as per usual arc4 key setup.

           Because of the way NetBSD's entropy pool works, this was
           mostly harmless, because if you ask for RND_EXTRACT_ANY,
           you always get as many bytes as you ask for.  However,
           this is probably a security hole in the original FreeBSD
           code, where AFAICT you might end up using an 8-bit arc4
           key -- not good, much worse than using the output of the
           entropy pool hash function even when it thinks it only
           has 8 bits of entropy to give you.

           One thing this code could do on NetBSD that was not so
           good was to replace a key with a lot of entropy with
           one with less entropy.  That's clearly counterproductive.

   The new code, instead:

        a) Asks for 32 good bytes.  If it gets them, use them as the
           arc4 key in the usual way.

        b) Tracks how many entropy bytes the key it's replacing had.
           If the new entropy request got less bytes, leave the old
           key in place.  Note that the first time through, the "old
           key" had zero bytes, so we'll always replace it.

        c) If we get less then 32 bytes but more than we had, request
           EXTRACT_ANY bytes from the entropy pool, padding the key
           out to 32 bytes which we then use as the arc4 key in the
           usual way.

This is still really all rather backwards.  Instead of this generator
deciding to rekey itself using a basically arbitrary metric, it should
register a callback so that the entropy pool code could rekey it when
a lot of bits were available.  Details at 11.

Finally, rename the "stir" function (which did not stir) to "rekey",
which is what it actually does.


To generate a diff of this commit:
cvs rdiff -r1.6 -r1.7 syssrc/sys/lib/libkern/arc4random.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.