Secure Randomness in Go 1.22

https://go.dev/blog/chacha8rand

by spacey • 2 years ago

37 4 2 years ago

go.dev

gnabgib• 2 years ago

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

rsc2• 2 years ago

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.

38• 2 years ago

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.

rsc2• 2 years ago

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.

Secure Randomness in Go 1.22

Related Stories