Secure Randomness in Go 1.22
1–10 of 98 posts
Re: Secure Randomness in Go 1.22
#2(This was posted last week by spacey at https://news.ycombinator.com/item?id=40237491 as well, but that post seems to have been incorrectly buried as a duplicate of https://news.ycombinator.com/item?id=40224864. The two go.dev blog posts are two in a series but quite different: this one is about efficient secure random number generator algorithms, while the earlier one was about Go API design.)
Re: Secure Randomness in Go 1.22
#3[deleted]
Re: Secure Randomness in Go 1.22
#4I've often thought about why the default implementation of many randoms around programming languages is to use LSFRs, MTs, and other fast RNGs in the 2020s.
It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)
Re: Secure Randomness in Go 1.22
#5I've often thought about why the default implementation of many randoms around programming languages is to use LSFRs, MTs, and other fast RNGs in the 2020s. It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)
Whats are other cases where you would need the former? I can only think of fixed seeding for things that need reproducible results (e.g tests, verifications).
I think theres another little force that pushes people towards the PRNG even when they don't need seeding: CSPRNG api always includes an error you need to handle; in case the sys call fails or you run out of entropy.
I'm curious how often crpyto.Rand read fails? How much random do I have to read to exhaust the entropy of a modern system? I've never seen it fail over billions of requests (dd does fine too). Perhaps a Must/panic style API default makes sense for most use-cases?
Edit to add: I took a look at the secrets package in python (https://docs.python.org/3/library/secrets.html) not a single mention of how it can throw. Just doesn't happen in practice?
Re: Secure Randomness in Go 1.22
#6Even in the worst case benchmark the new strategy is only about half as slow as an insecure random number generator. However most benchmarks were much closer.
Go is doing the right balance between safety and performance for the standard library (and for the apps built on top of it). Hopefully other ecosystems follow suit.
If an application needs fast insecure random numbers - they should implement an app internal generator themselves. Having insecure randoms within easy reach is a footgun we can put away.
Re: Secure Randomness in Go 1.22
#7I've often thought about why the default implementation of many randoms around programming languages is to use LSFRs, MTs, and other fast RNGs in the 2020s. It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)
One of the better arguments for using a CSPRNG (here, ChaCha8) is that they benchmark it within a factor of 2 of PCG. The state is still comparatively large (64 bytes vs 16), but not nearly as bad as something like mt19937 or the old Go PRNG. (If the CSPRNG was much much slower, which is generally true for CSPRNGs other than the reduced-round ChaCha variant, it becomes a less appealing default.)
Re: Secure Randomness in Go 1.22
#8I've often thought about why the default implementation of many randoms around programming languages is to use LSFRs, MTs, and other fast RNGs in the 2020s. It seems to be better to err on the side of 'people dont know if they want a PRNG or a CSPRNG' and switch the default to the latter with an explicit choice for the former for people that know what they need :)
Whats are other cases where you would need the former? I can only think of fixed seeding for things that need reproducible results (e.g tests, verifications). I think theres another little force that pushes people towards the PRNG even when they don't need seeding: CSPRNG api always includes an error you need to handle; in case the sys call fails or you run out of entropy. I'm curious how often crpyto.Rand read fails…
> CSPRNG api always includes an error you need to handle (in case the sys call fails or you run out of entropy).
> Perhaps a Must/panic style API makes sense?
Yes, CSPRNGs APIs should be infallible.
Re: Secure Randomness in Go 1.22
#9[dead]
Re: Secure Randomness in Go 1.22
#10Even in the worst case benchmark the new strategy is only about half as slow as an insecure random number generator. However most benchmarks were much closer. Go is doing the right balance between safety and performance for the standard library (and for the apps built on top of it). Hopefully other ecosystems follow suit. If an application needs fast insecure random numbers - they should implement an app internal gen…
Except this honestly seems worse.
Encouraging people to assume the "random" primitive is cryptographically secure is just encouraging bad practice. Making math/rand/v2 cryptographically secure might solve a problem, but it's now making something which doesn't look like it's promises security "okay".
`math/rand` functions in general though do not have the convention of being cryptographically secure - changing them so they are is just making a change to make bad code do the right thing, potentially masking the fact that if we're making that obvious mistake, what others are we also making?