Secure Randomness in Go 1.22 (Go Blog)

[Posted May 7, 2024 by corbet]

The Go Blog has a detailed article on the new, more secure random-number generator implemented for the 1.22 release.

For example, when Go 1.20 deprecated math/rand's Read, we heard from developers who discovered (thanks to tooling pointing out use of deprecated functionality) they had been using it in places where crypto/rand's Read was definitely needed, like generating key material. Using Go 1.20, that mistake is a serious security problem that merits a detailed investigation to understand the damage. Where were the keys used? How were the keys exposed? Were other random outputs exposed that might allow an attacker to derive the keys? And so on. Using Go 1.22, that mistake is just a mistake.

(Log in to post comments)

Secure Randomness in Go 1.22 (Go Blog)

Posted May 9, 2024 13:15 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

Overall, ChaCha8Rand is slower than the Go 1 generator, but it is never more than twice as slow, and on typical servers the difference is never more than 3ns. Very few programs will be bottlenecked by this difference, and many programs will enjoy the improved security.

I think this is a good way of thinking about the problem. It's not that performance is unimportant- they tried hard to make their secure RNG as performant as possible- but that security should be the default. The programmer should have to ask specifically for a faster but less secure version.

Secure Randomness in Go 1.22 (Go Blog)

Posted May 9, 2024 18:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I use math.Rand a lot in unit tests where I need reproducible outcomes. And I was always stressed that math.Rand is too easy to confuse with crypto.Rand. I wish the insecure random generator was named something like InsecureRand. Or SeedableRand.

Secure Randomness in Go 1.22 (Go Blog)

Posted May 9, 2024 20:44 UTC (Thu) by willy (subscriber, #9762) [Link]

math.pseudorand()

Everybody understands that's not actually random. Right?

Secure Randomness in Go 1.22 (Go Blog)

Posted May 10, 2024 0:21 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

I think the problem is not (just) that programmers fail to distinguish between secure and insecure PRNGs. It is also that programmers wrongly believe that they can get away with an insecure PRNG in many cases where a secure PRNG is necessary (or at least prudent):

* Hash randomization, randomly selecting a quicksort pivot, etc. (think of DoS attacks)
* Any game that will be played for money (either as an esport, or as some kind of gambling)
* Sample code that some other programmer will inevitably copy/paste without understanding

The other issue is that CSPRNGs are, while not quite as performant as general PRNGs, nonetheless pretty good these days, and for just about any application that is not a really big Monte Carlo simulation (or the like), you probably care more about the correctness (absence of bias) of your PRNG than the performance (and a CSPRNG has a much higher standard of correctness than a general PRNG). If you use a CSPRNG when a general PRNG would have sufficed, eh, maybe you left a little bit of performance on the floor. If you use a general PRNG where a CSPRNG should have been used, that could be a big problem.

Secure Randomness in Go 1.22 (Go Blog)

Posted May 10, 2024 13:44 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

It seems like a specific case of the old saw that premature optimization is the root of all evil. It may also reflect out of date ideas about how big a performance hit cryptographic security causes. Part of the reason it makes sense for language designers to think about these things rather than end users is because they're more likely to be up to date about what the real performance costs are.