arc4random_buf_large() is not exported as an API; this is intentional.
If you do arc4random_buf_large() for a small buffer size, say 8, you
are not winning the output performance vs output quality vs system
interactiveness tradeoff in any way. It is a loss in all respects.
2048 was estimated as a knee where it the setup cost for a seperate
RC4 is cheap enough so that PRNG data can be created for independent
kernel threads without contention/holding of the mutex.
This mechanism was invented to improving interactive performance. However
it is still expensive.
Right. the arc4random_buf_large() mechanism will still get used, though, by
anyone who calls arc4random_buf() with a big enough request, correct? And
the setup time in this case will also be affected by the multiplier we
choose for dumping initial keystream.
I think I need to code up some test cases...