cprng(9): Note ipl must be at most IPL_SOFTSERIAL now.

cprng(9): Forbid use in hard interrupt context.

May need access to the global entropy pool (infrequently). This way
the global entropy pool lock can be lowered to IPL_SOFTSERIAL too,
with a little additional work.

cprng(9): Remove trailing comma.

Update cprng_strong API documentation.

Should maybe just get rid of the flags arguments.

Update cprng(9) man page for CTR_DRBG -> Hash_DRBG change last year.

Fix cprng_fast64 return type to match code

branches: 1.10.16; 1.10.18;
Clarify advice about when to use what parts of cprng(9).

Add security model to specify the difference between cprng_strong and
cprng_fast.

Fix code references. cprng_fast now uses ChaCha8, not RC4.

XXX Would have been nice if they had been called cprng and cprng_weak
to reduce confusion about which one to use, or even random and
weakrandom. Too late for that now, though.

branches: 1.9.4;
Merge riastradh-drm2 to HEAD.

Rework cprng(9) man page to reflect the current state of affairs.

- Remove defunct cprng_strong_getflags/setflags.
- Remove defunct cprng_strong_ready.
- Document CPRNG_HARD.
- Omit cprng_strong structure, which is now opaque.
- Specify what can sleep and under what conditions.
- Be a little more consistent about some markup.

This is not the whole story (select/kqueue stuff for /dev/random is
still omitted), and I plan to change it some more (to split
cprng_strong into one routine that unconditionally guarantees as many
bytes as you asked, and another routine that may block or return
partial reads), but this will do until I find the time for those.

branches: 1.7.2;
Fix dangling sentence vestige in cprng(9).

branches: 1.6.2;
fix some signatures

branches: 1.5.4;
Use more markup. Bump date for previous.

Separate /dev/random pseudodevice implemenation from kernel entropy pool
implementation. Rewrite pseudodevice code to use cprng_strong(9).

The new pseudodevice is cloning, so each caller gets bits from a stream
generated with its own key. Users of /dev/urandom get their generators
keyed on a "best effort" basis -- the kernel will rekey generators
whenever the entropy pool hits the high water mark -- while users of
/dev/random get their generators rekeyed every time key-length bits
are output.

The underlying cprng_strong API can use AES-256 or AES-128, but we use
AES-128 because of concerns about related-key attacks on AES-256. This
improves performance (and reduces entropy pool depletion) significantly
for users of /dev/urandom but does cause users of /dev/random to rekey
twice as often.

Also fixes various bugs (including some missing locking and a reseed-counter
overflow in the CTR_DRBG code) found while testing this.

For long reads, this generator is approximately 20 times as fast as the
old generator (dd with bs=64K yields 53MB/sec on 2Ghz Core2 instead of
2.5MB/sec) and also uses a separate mutex per instance so concurrency
is greatly improved. For reads of typical key sizes for modern
cryptosystems (16-32 bytes) performance is about the same as the old
code: a little better for 32 bytes, a little worse for 16 bytes.

Spelling.

Whitespace fixes; new sentence, new line; better macro usage.
Sort SEE ALSO.

Add cprng(9) manual page, remove arc4random(9) manual page