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 @hashbreaker
Now that I think about it, those apps don't need RNG or the cache anyway. Really only CBC is common in requiring per-packet RNG today.
1 reply 0 retweets 0 likes
And it's slow anyway, and only uses 10s of bytes between rekeys.
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.