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.
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.
When I request 1 random byte, the library fetches 512 bytes (for example) of random data from the OS, and then returns the first byte to me. When I request another 1 random byte, it just gives me the next byte that it already fetched without needing to make another syscall.
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.
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.
How does a read-ahead cache work and why is it so effective here?
When I request 1 random byte, the library fetches 512 bytes (for example) of random data from the OS, and then returns the first byte to me. When I request another 1 random byte, it just gives me the next byte that it already fetched without needing to make another syscall.
Thanks for the explanation
fcrand (fast crypto/rand) is a high-performance drop-in replacement for Go's crypto/rand.