4 ms·
The article explains this rationale very clearly: > Using Go 1.20, that mistake is a serious security problem that merits a detailed investigation to understan
by bhawks 2y ago
The article explains this rationale very clearly:
> 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.
It is not masking a mistake - you should be using a CSPRNG in security sensitive contexts, however if you screw up the collateral damage is much lower. You should be detecting this mistake with static analysis and code audits rather then observing the random number generator on prod.
- XorNot 2y agoRight but that's the point. There's genuine and useful uses for predictable random number generators in a lot of contexts. This would be, conventionally, what I'm reach to a math/rand (or equivalent in other languages) for. Whereas `crypto/rand` is very obviously "the CSPRNG function". I understand the motivation, but if we're trying to find bad code why not go further and just require people to put //go:I AM NOT DOING CRYPTOGRAPHY at the top of files which use math/rand or something? It's unloading the gun but not worrying that people are still pointing it around and clicking the trigger.