Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Randomness in Go 1.22

go.dev

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Secure Randomness in Go 1.22

#91

Post by meling »

rsc wrote: post #81
rsc wrote: post #53

Earlier quoted context omitted.

I'm not sure what happened in your case, but it probably wasn't what you describe. We changed goimports in 2016 to prefer crypto/rand over math/rand ( https://go-review.googlesource.com/24847 ), and that was before there was VSCode support for Go.

Filippo and I dug into this a bit more, and it is possible that VSCode auto-complete (which also adds imports for the auto-completed things) is the culprit here. Apologies if that's what happened to you. We will look into fixing that. Now that math/rand.Read is marked deprecated, at least if it does get selected, you get a nice strikethrough rendering as well.

It is probably not related, but gopls has a known issue with its heuristic for picking imports: https://github.com/golang/go/issues/61208

Re: Secure Randomness in Go 1.22

#92

Post by Mawr »

fl0ki wrote: post #69
arp242 wrote: post #38

Earlier quoted context omitted.

I've also had some report a vulnerability because they thought math/rand was being used when it wasn't. They just mixed something up with a few different files – not a big deal – but it just goes to show how confusing the entire thing is. text/template and html/template are similar. In hindsight this package name shadowing was a bad idea.

This is one of my bigger remaining issues with day-to-day use of Go. I love how neat Go `package.Symbol` usually looks -- that objective was met -- but it has at least these problems: * It is syntactically identical to `variable.Member` so even at a glance it's ambiguous. After shadowing occurs, diagnostics get really confused. Go could at least include more error information when this is a possible cause. * The best…

> * Dot imports were designed in a way that ensures they never get used

Good, unqualified imported names are horrible for readability.

Re: Secure Randomness in Go 1.22

#93

Post by d-z-m »

akira2501 wrote: post #79
d-z-m wrote: post #60

Earlier quoted context omitted.

> Call me paranoid You're being too paranoid. If you have a substantive disagreement with the content of the "Too Much Crypto" paper then we can talk about it, but to posit that Aumasson was compromised by a TLA(with no evidence) and that this paper is the result is pure conspiracy thinking. Aumasson designed BLAKE[0], as well SipHash[1] and SPHINCS+[2](both of which he designed with DJB, btw). [0]: https://www.blake…

> but to posit that Aumasson was compromised by a TLA(with no evidence) and that this paper is the result is pure conspiracy thinking. Except we have some evidence that the NSA has compromised processes in exactly this way before. The OP was just asking a question and suggesting a likely and known mechanism for perfidy, he didn't actually posit that it was true.

There comes a point when "just asking questions" crosses a line into conspiratorial theory crafting. I can ask all kinds of crazy questions, like: "what if the world is run by a species of lizard people who live underground?". In the absence of evidence, it's pointless to debate such things. In general, people should be allergic to thinking in this way. That's not to say that conspiracies never happen, they do. However, it's on you to substantiate your insane claims, it isn't on your interlocutors to prove that they aren't true.

Re: Secure Randomness in Go 1.22

#94

Post by beautron »

fl0ki wrote: post #69
arp242 wrote: post #38

Earlier quoted context omitted.

I've also had some report a vulnerability because they thought math/rand was being used when it wasn't. They just mixed something up with a few different files – not a big deal – but it just goes to show how confusing the entire thing is. text/template and html/template are similar. In hindsight this package name shadowing was a bad idea.

This is one of my bigger remaining issues with day-to-day use of Go. I love how neat Go `package.Symbol` usually looks -- that objective was met -- but it has at least these problems: * It is syntactically identical to `variable.Member` so even at a glance it's ambiguous. After shadowing occurs, diagnostics get really confused. Go could at least include more error information when this is a possible cause. * The best…

This is a great analysis that gave me a lot to think about.

I've always loved the way Go's packages work. With care, I can organize large codebases that end up feeling so clean and nice to deal with.

I usually get to pick all my own package names, so the issues you bring up are manageable for me. But you explained them well, and I can imagine the frustration of inheriting public API packages that were not carefully designed.

And this one is a perennial little naming hiccup:

> Who among us hasn't wanted to shadow the name `url` or `path`?

I still prefer Go's packages to other languages' ways of code organization, but I think you convinced me that giving packages their own separator (and not sharing '.') might have been a better design. Though strangely, as you mentioned, any other separator is uglier.

Re: Secure Randomness in Go 1.22

#95

Post by gchaincl »

nickcw wrote: post #19

From the article > Go aims to help developers write code that is secure by default. When we observe a common mistake with security consequences, we look for ways to reduce the risk of that mistake or eliminate it entirely. In this case, math/rand’s global generator was far too predictable, leading to serious problems in a variety of contexts. > For example, when Go 1.20 deprecated math/rand’s Read, we heard from deve…

I had a similar goimport issue importing the wrong pkg. I've added a forbidigo linter rule to fail when certain packages were imported.

Re: Secure Randomness in Go 1.22

#96

Post by camkego »

Great article!

One nit.

I think statistical randomness seems to be conflated with pseudo-random number generators here. (PRNGs)

The wiki definition of statistical randomness is: "A numeric sequence is said to be statistically random when it contains no recognizable patterns or regularities"

Does this apply to true random number generators (TRNGs)?

You better hope it does. At least in the long-run or "in the limit". Otherwise, it is not a TRNG.

A TRNG should generate, in the long-run, "A number sequence containing no recognizable patters or regularities.

So, I think we can say: statistical randomness does not imply PRNGs, but can apply to TRNGs also.

I think the issue comes from the fact there are a large number of statistical randomness TESTs for PRNGs to qualify PRNGs with a qualified form of statistical randomness.

So, I think psuedo-random number generators would have been more appropriate than "statistical randomness" to identify PRNGs.

But, it's really a small nit.

Again, great article!

Re: Secure Randomness in Go 1.22

#97

Post by SAI_Peregrinus »

LVB wrote: post #74

I'm still trying to interpret the recommendations regarding security and this new v2 option. The blog post makes statements like, "For secrets, we need something different." and then goes into detail about cryptographic randomness, ChaCha8, and how it is seeded with system randomness. It gives the impression of being very "secure". But then the package docs state: >... but it should not be used for security-sensitive…

Correct. math/rand/v2 isn't optimal, but it's not an immediate catastrophic flaw to use it when you should have used crypto/rand any more. From the article:

> It’s still better to use crypto/rand, because the operating system kernel can do a better job keeping the random values secret from various kinds of prying eyes, the kernel is continually adding new entropy to its generator, and the kernel has had more scrutiny. But accidentally using math/rand is no longer a security catastrophe.

Re: Secure Randomness in Go 1.22

#98

Post by PullJosh »

Complete novice question: Would it be possible to build a language that could read your source code and tell you, at compile time, which expressions have values that depend on RNG? And on cryptographically secure RNG?

So that you could annotate a variable as needing to be cryptographically secure and the language could check that, somewhere along the way, its value depends on an adequate RNG function?

Post reply on HN