New blog post "Fast-key-erasure random-number generators": https://blog.cr.yp.to/20170723-random.html … An effort to clean up several messes simultaneously.
-
-
Replying to @hashbreaker
One problem with caching output, i.e. the 736 bytes, is jitter. Having every nth packet/record be inexplicably slower kills :(
2 replies 0 retweets 0 likes -
Replying to @colmmacc
Refilling the buffer is a small fraction of a microsecond on one of your server cores. Linux has vastly larger continual jitter than this.
1 reply 0 retweets 0 likes -
Replying to @hashbreaker
Networks today at 25gbit/sec, 100gbit/sec on the industry horizon. Few use Linux networking for encrypting that. Microbursts & incast a pain
2 replies 0 retweets 0 likes -
Replying to @colmmacc
Sure: I've used 40-gigabit Infiniband, and of course it tries hard to avoid poking the CPU. But what exactly do you think the RNG issue is?
1 reply 0 retweets 0 likes -
Replying to @hashbreaker
I like your RNG and its properties better, but caches cause jitter and use memory is all :/ does matter in some apps.
1 reply 0 retweets 0 likes -
Replying to @colmmacc @hashbreaker
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?
1 reply 0 retweets 0 likes -
Replying to @colmmacc
How about benchmarking the simple secure thing first, and then seeing whether there's a real argument for doing something more complicated?
1 reply 0 retweets 0 likes -
Replying to @hashbreaker
Caching RNG output is a common optimization, even for urandom, but I've had to remove it several times from things.
2 replies 0 retweets 0 likes
I don't think it's more complicated, just changes the scope of r, pos. In fastrandombytes. Same alg.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.