What makes it so much faster? Were there a few particular big wins or is it just tons of small optimizations?
If it's faster, fully API compatible, and maintains all the same guarantees, why isn't the implementation being upstreamed to crypto/rand?
Edit: Looked at the code. It's a little read-ahead cache wrapped around crypto/rand. Good idea! I can't help but wonder if this actually does have some security implications, since rand data is going to be sitting around in process memory potentially long before it's actually requested.
On Linux, there's no need to use this. Modern Linux kernels implement getrandom() in the vDSO, which does similar buffering, and keeps those buffers safe in the event of forks or VM forks and kernel reseed events.
The readme says:
> Maintains all cryptographic security guarantees of crypto/rand
I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.
4 comments
[ 2.8 ms ] story [ 20.9 ms ] threadIf it's faster, fully API compatible, and maintains all the same guarantees, why isn't the implementation being upstreamed to crypto/rand?
Edit: Looked at the code. It's a little read-ahead cache wrapped around crypto/rand. Good idea! I can't help but wonder if this actually does have some security implications, since rand data is going to be sitting around in process memory potentially long before it's actually requested.
The readme says:
> Maintains all cryptographic security guarantees of crypto/rand
I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.