2017.07.23 19:19:39 (889173174151258112) from Daniel J. Bernstein, replying to "Colm MacCárthaigh (@colmmacc)" (889170130860523520):
Sure. But my point is that you're already doing a mix of miscellaneous microsecond-scale operations. This RNG is always faster than that.
2017.07.23 18:51:10 (889166005783711747) from Daniel J. Bernstein, replying to "Colm MacCárthaigh (@colmmacc)" (889162988724277249):
Typical RNG code (e.g., OpenSSL RAND_bytes) takes longer to generate 1 byte than a fast-key-erasure RNG takes to fill up a 768-byte buffer.
2017.07.23 19:03:48 (889169184663273472) from "Colm MacCárthaigh (@colmmacc)":
That's compelling, but I still don't want jitter. Seems easy enough to do.
2017.07.23 19:05:32 (889169623559553024) from "Colm MacCárthaigh (@colmmacc)", replying to "Colm MacCárthaigh (@colmmacc)" (889169184663273472):
I don't think you can compare so neatly to RAND_bytes, without thread/fork safety. Either need locks or thread-local storage + fork-guard.
2017.07.23 19:07:33 (889170130860523520) from "Colm MacCárthaigh (@colmmacc)", replying to "Colm MacCárthaigh (@colmmacc)" (889169623559553024):
Which will add slowness, or memory, or more likely a bit of both. Obviously the underlying algorithm is better, but locks esp can dominate.