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

81–90 of 98 posts

Re: Secure Randomness in Go 1.22

#81

Post by rsc »

rsc wrote: post #53
jedisct1 wrote: post #28

I've been using `math/rand` instead of `crypto/rand` where `crypto/rand` was absolutely needed. This resulted in static keys being used in early versions of dnscrypt-proxy2. The reason is that I'm using the VSCode extension that automatically adds imports. In all the source files requiring secure randomness, I carefully imported `crypto/rand` manually, but I forgot to do it in one of the files. Everything compiled an…

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.

Re: Secure Randomness in Go 1.22

#82

Post by rsc »

TimWolla wrote: post #24
supakeen wrote: post #4

I'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 :)

> 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 :) That’s exactly what we did in PHP 8.2 [1] with the new object-oriented randomness API: If you as the developer don’t make an explicit choice for the random engine to use, you’ll get the CSPRNG. Now unfortunat…

OpenBSD had a similar problem with people calling arc4random and getting RC4 randomness, but they just changed it to use ChaCha20 anyway and backronymed it to "a replacement call for random".

https://man.openbsd.org/arc4random.3

Re: Secure Randomness in Go 1.22

#83

Post by vlovich123 »

rsc wrote: post #80
vlovich123 wrote: post #76

Why is chacha8 used instead of a HW-accelerated AES block cipher (e.g AES-GCM) when that's available? Also AES-GCM only requires 12 bytes of random IV vs chacha8's 32 bytes not that that actually matters.

It's a good question. We probably could have designed something based on AES-GCM instead, but it would have had more limited impact. ChaCha8 is still very fast even without direct hardware acceleration. The 32-bit benchmarks at the end of the post are running with no assembly at all and still running within 2X of the 64-bit SSE2-based assembly. AES-GCM with hardware is pretty fast, but AES-GCM without hardware is qui…

I meant that you could use the AES branch when running on HW-accelerated AES systems and chacha8 otherwise. Given that the security properties of AES are better understood than chacha8, any issues with chacha8 would have more limited scope. And since this is a cryptographic RNG, the specific implementation doesn't actually matter. The math variant probably would probably need to use the chacha8 variant since that can have reproducability requirements for a given seed although it's arguable if that reproducability needs to be the same between totally different machines since the implementation of math/rng isn't actually defined to have that property & you're already changing this in 1.22 which indicates it's mutable.

I'm kind of surprised that it's slower on AMD Ryzen - it looks like only the Pro series have a an actual co-processor. Weird decision on AMD's part to implement AES-NI without HW acceleration on some CPUs instead of just not implementing the AES-NI instruction set. That being said, AES-CBC would be even better for this purpose since the authentication guarantees aren't needed.

On my Intel machine, it's 5.7 GiB/s for AES-GCM. I don't know how you benchmarked the chacha8 version so I can't run the equivalent on my machine.

Re: Secure Randomness in Go 1.22

#84

Post by tedunangst »

kbolino wrote: post #73
SamWhited wrote: post #68

Earlier quoted context omitted.

I mean, copy/paste is a thing, I'm not suggesting you have to always type out every single character. Just know what's being imported.

I don't see a functional difference between copy-paste and autoimport. They have more or less the same risks. Imports should rarely be manually managed directly in source. Doing that is the epitome of tedium and most imports are just boilerplate, so your eyes will glaze over and you'll miss the finer points unless a specific file warrants deeper scrutiny. That doesn't mean imports should never be reviewed, and again,…

I've never copy and pasted crypto/rand and gotten math/rand.

Re: Secure Randomness in Go 1.22

#85

Post by thadt »

vlovich123 wrote: post #76

Why is chacha8 used instead of a HW-accelerated AES block cipher (e.g AES-GCM) when that's available? Also AES-GCM only requires 12 bytes of random IV vs chacha8's 32 bytes not that that actually matters.

Related - a week or so ago I was playing with ASCON[1], a sponge based cipher and hash function aimed at embedded systems. A passing thought was that it might be handy to use as a random number generator. When I read this post a couple days ago, out of curiosity I picked up the ASCON permutation and benchmarked it vs this one.

It was unfortunately a bit slower: ~27 ns per 64-bit value (6 round permutation) vs ~4 ns for the included ChaCha8. I suspect it could be optimized, and run at the higher output rate (8 rounds per 128-bit output). One nice thing is that it does have a smaller state of only 40 bytes.

But - for the performance, this ChaCha8 implementation is awesome!

[1] https://ascon.iaik.tugraz.at

Re: Secure Randomness in Go 1.22

#86

Post by barnabee »

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.

Correct. I have no reason to believe Aumasson was compromised, but it’s certainly happened before that people in similar positions have been.

Regardless of whether there’s a third party with an ulterior motive or it’s (more likely) simply the author’s genuine opinion, the paper “Too Much Crypto” seems ok with limiting the security of cryptography to levels that may not be secure against the most advanced and well-resourced adversaries:

> “But what if your adversary is NSA or Mossad? Won’t they have the computing capabilities to run a 280 attack?” Such a question is irrelevant. If your problem is to protect against such adversaries, the answer is probably not cryptography.”

You may agree with that, too. But it’s quite an opinionated stance and one that I’d expect to see clearly signposted and explained in API docs, and for the more expensive and secure alternative to also be available.

Re: Secure Randomness in Go 1.22

#87

Post by pbsd »

pbsd wrote: post #77
rsc wrote: post #75

Earlier quoted context omitted.

That publication doesn't seem to mention the "lagged" part, or maybe I missed it. I am aware of https://www.leviathansecurity.com/blog/attacking-gos-lagged-... which also refers to it as a lagged Fibonacci generator. Rob Pike and I exchanged mail with Don Mitchell (who wrote the original C version of the Go 1 generator) a few months back to see how he would describe the algorithm, and he said "As I recall Jim and I i…

The name itself might be due to Knuth; they were initially known as additive generators in other early literature.

Actually it wasn't Knuth; only the 1997 3rd edition contains the lagged Fibonacci name. The first instance of the name I can find is Marsaglia-Tsay in 1985 [1] (and possibly Marsaglia's 1984 "A current view of random number generators", which is impossible to find online).

[1] https://doi.org/10.1016/0024-3795(85)90192-2

Re: Secure Randomness in Go 1.22

#88

Post by rsc »

vlovich123 wrote: post #83
rsc wrote: post #80

Earlier quoted context omitted.

It's a good question. We probably could have designed something based on AES-GCM instead, but it would have had more limited impact. ChaCha8 is still very fast even without direct hardware acceleration. The 32-bit benchmarks at the end of the post are running with no assembly at all and still running within 2X of the 64-bit SSE2-based assembly. AES-GCM with hardware is pretty fast, but AES-GCM without hardware is qui…

I meant that you could use the AES branch when running on HW-accelerated AES systems and chacha8 otherwise. Given that the security properties of AES are better understood than chacha8, any issues with chacha8 would have more limited scope. And since this is a cryptographic RNG, the specific implementation doesn't actually matter. The math variant probably would probably need to use the chacha8 variant since that can…

For benchmarking ChaCha8, I ran:

    go test -bench=Block internal/chacha8rand
For benchmarking AES-GCM, I edited src/crypto/cipher/benchmark_test.go:51 to add 256 to the length list, and then I ran:

    go test -bench=GCM/-128-256 crypto/cipher
    GODEBUG=cpu.aes=off go test -bench=GCM/-128-256 crypto/cipher
You're right that we could use AES where available in the places where reproducibility doesn't matter, although that's a second implementation to debug and maintain. ChaCha8 seems fine.

Re: Secure Randomness in Go 1.22

#89

Post by rsc »

vlovich123 wrote: post #83
rsc wrote: post #80

Earlier quoted context omitted.

It's a good question. We probably could have designed something based on AES-GCM instead, but it would have had more limited impact. ChaCha8 is still very fast even without direct hardware acceleration. The 32-bit benchmarks at the end of the post are running with no assembly at all and still running within 2X of the 64-bit SSE2-based assembly. AES-GCM with hardware is pretty fast, but AES-GCM without hardware is qui…

I meant that you could use the AES branch when running on HW-accelerated AES systems and chacha8 otherwise. Given that the security properties of AES are better understood than chacha8, any issues with chacha8 would have more limited scope. And since this is a cryptographic RNG, the specific implementation doesn't actually matter. The math variant probably would probably need to use the chacha8 variant since that can…

> I'm kind of surprised that it's slower on AMD Ryzen - it looks like only the Pro series have a an actual co-processor. Weird decision on AMD's part to implement AES-NI without HW acceleration on some CPUs instead of just not implementing the AES-NI instruction set.

I meant that AES-GCM is 20% slower than ChaCha8 on that system, not that HW-accelerated AES-GCM is 20% slower than a software implementation. On the contrary, the HW-accelerated AES-GCM is 20X faster than software on that system.

Re: Secure Randomness in Go 1.22

#90

Post by kbolino »

tedunangst wrote: post #84
kbolino wrote: post #73

Earlier quoted context omitted.

I don't see a functional difference between copy-paste and autoimport. They have more or less the same risks. Imports should rarely be manually managed directly in source. Doing that is the epitome of tedium and most imports are just boilerplate, so your eyes will glaze over and you'll miss the finer points unless a specific file warrants deeper scrutiny. That doesn't mean imports should never be reviewed, and again,…

I've never copy and pasted crypto/rand and gotten math/rand.

Yeah that's a legit gripe but I wasn't really talking about the standard library which uses nice short import paths.
Post reply on HN