Secure Randomness in Go 1.22

gnabgib wrote: post #2

This is close to your post yesterday [0] (139 points, 34 comments)... although it does go into more detail [0]: https://news.ycombinator.com/item?id=40224864

It's a different blog post about a different but related topic. Yesterday's post was about API design. This post is about random number generator design.

Re: Secure Randomness in Go 1.22

#6

Post by 38 » Fri, May 03, 2024, 11:33 PM UTC

If both are now crypto secure, what's the point of having both? Also seems like they've made math/rand slower, not a win in my book.

Re: Secure Randomness in Go 1.22

#7

Post by rsc » Mon, May 06, 2024, 12:40 PM UTC

38 wrote: post #6

If both are now crypto secure, what's the point of having both? Also seems like they've made math/rand slower, not a win in my book.

math/rand is not the speed bottleneck for just about anything, but it _is_ a security weak point in many systems, including systems where you wouldn't at first think there was a security aspect. It makes sense to improve the security at the cost of a (tiny) bit of speed.

Code that needs speed can still use rand.NewPCG of course.

As for why have two, for key generation the OS kernel (what crypto/rand provides access to) can take care of more sophisticated problems like suspend-resume state forking attacks and the like, so you are still better off in the limit using crypto/rand for key generation. But if you accidentally use math/rand, it's no longer as big a problem.