Russell Cox consistently produces excellent technical blogs and proposals (and work). If you want to improve the clarity of your writing and thinking, he is a great place to start.
he makes nice video demos too https://research.swtch.com/acme
Secure Randomness in Go 1.22
71–80 of 98 posts
Re: Secure Randomness in Go 1.22
#72Earlier quoted context omitted.
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.)
How did you get to 64 bytes of state? Last I looked, Go's ChaCha8 implementation had 300 bytes of state. Most of that was spent on a buffer which was necessary for optimal amortized performance.
Fair enough. I was just thinking of base ChaCha state without the buffering. 300B is still significantly better than mt19937 (~2.5kB) or the old Go generator (4.9kB!).
Re: Secure Randomness in Go 1.22
#73Earlier quoted context omitted.
The "write out your imports" ship sailed with modules. Nobody wants to write out "code.internal.corporate.domain/bureaucratic/hierarchy/of/orgs/foo" when they're looking for "foo". Even GitHub-hosted modules have fairly long names. The tools need to get better though. I'd rather they fall back to asking me than guessing when the import is ambiguous. I also think they should only ever autoimport from the stdlib or wha…
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 think the tools need a lot of improvement in this regard.
Re: Secure Randomness in Go 1.22
#74I'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 work ... This package's outputs might be easily predictable regardless of how it's seeded. For random numbers suitable for security-sensitive work, see the crypto/rand package.
If that's the case, then why hint at using math/rand/v2 "for secrets" in the blog post? Is the short version that we should all still use "crypto/rand" for anything sensitive, and all of the improvements described here are a safety net should someone inappropriately use math/rand/v2?
Re: Secure Randomness in Go 1.22
#75Go 1's math/rand would more accurately be called an additive lagged Fibonacci generator. The first publication of it is due to Green, Smith, and Klem [1]. [1] https://doi.org/10.1145/320998.321006
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 implemented Marsaglia's LFSR-like generator."
I think both descriptions (lagged Fibonacci and LFSR-like) are accurate in different ways, so either would be fine, but for the post I decided to use the original author's description.
Re: Secure Randomness in Go 1.22
#76Why 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.
Re: Secure Randomness in Go 1.22
#77Go 1's math/rand would more accurately be called an additive lagged Fibonacci generator. The first publication of it is due to Green, Smith, and Klem [1]. [1] https://doi.org/10.1145/320998.321006
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.
Re: Secure Randomness in Go 1.22
#78From 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 also noticed when I tried to search for "secure password generation golang" nearly all examples use math/rand. And to make things worse all of them initialize seed with current time just before generating the password.
This was discovered after I found in our code someone used math rand and was curious where they copied it from :)
Re: Secure Randomness in Go 1.22
#79> a lightly modified version of Daniel J. Bernstein’s ChaCha stream cipher. ChaCha is widely used in a 20-round form called ChaCha20, including in TLS and SSH. Jean-Philippe Aumasson’s paper “Too Much Crypto” argues persuasively that the 8-round form ChaCha8 is secure too (and it’s roughly 2.5X faster) Call me paranoid but my mind immediately jumps to the question of whether this paper can be trusted or if it has bee…
> 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.
Re: Secure Randomness in Go 1.22
#80Why 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 quite slow.
Just now I tried benchmarking ChaCha8 in 256-byte chunks compared to AES-GCM in 256-byte chunks. With HW acceleration, AES-GCM is maybe 10% faster on my Apple M3 but 20% slower on my AMD Ryzen. Same ballpark as ChaCha8 though.
On the other hand, if I disable AES hardware acceleration, that same benchmark drops by about 20X. So using AES would not have been a good idea for systems without AES hardware.
Overall, not much win to AES in the best case, and quite a loss in the worst case.