Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
1–7 of 7 posts
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#2fcrand (fast crypto/rand) is a high-performance drop-in replacement for Go's crypto/rand.
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#3What 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.
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#4On 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.
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#5What 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 implicatio…
How does a read-ahead cache work and why is it so effective here?
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#6What 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 implicatio…
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.
Re: Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster
#7Earlier quoted context omitted.
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