- 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.
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.
