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 18:15:36 (889157056376168449) from "Colm MacCárthaigh (@colmmacc)":
I like your RNG and its properties better, but caches cause jitter and use memory is all :/ does matter in some apps.
2017.07.23 18:17:57 (889157646615314432) from "Colm MacCárthaigh (@colmmacc)", replying to "Colm MacCárthaigh (@colmmacc)" (889157056376168449):
I'm going to implement it, but I think I'd cache internally only to the drbg_generate() equivalent, rekey each generate call. Make sense?
2017.07.23 18:31:26 (889161042118443008) from Daniel J. Bernstein, replying to "Colm MacCárthaigh (@colmmacc)" (889157646615314432):
How about benchmarking the simple secure thing first, and then seeing whether there's a real argument for doing something more complicated?
2017.07.23 18:39:11 (889162988724277249) from "Colm MacCárthaigh (@colmmacc)":
Caching RNG output is a common optimization, even for urandom, but I've had to remove it several times from things.