Taking this rare opportunity to put OpenSSL on blast a little bit - I have experienced no other software library or vendor where seemingly benign patch updates have completely broken functionality at the system level (in the web world). Semver people! Use it properly (and be consistent with the rest of the ecosystem you operate in)!!
Golang doesn't typically use OpenSSL: there is a BoringCrypto mode which can be enabled, but it's unsupported outside Google [1]. Instead, they have a policy of implementing well-known cryptographic algorithms themselves, in Go.
The author in this case is the lead cryptographic maintainer for Go.
Possibly worth noting for folks that BoringCrypto is necessary if you're having to deal with FIPS certification (which hopefully you don't). There's the usual FFI penalty to using it, so Go-native code is preferred for most use cases.
Golang has its own native crypto implementations where possible. Having used openssl extensively and having read some of its source code[1], I would personally like good alternatives. The developer (Filippo Valsorda) is a cryptographer and Go maintainer (incl. of some well known Go crypto packages in its std lib).
In this particular instance he seems to have implemented this (ML-KEM-768) as an exercise (incl. educational), but still, just some context!
[1] openssl is a gift that keeps on giving (CVEs). Just look at all those nice (incl. recent) issues, incl. RCEs iirc. Also, very anecdotal, but I find it funny that they haven't updated this page for the last I don't know 15 years? https://wiki.openssl.org/index.php/Code_Quality
Beyond what the other replies have already pointed out, the most sensible way to deploy PQ crypto today is to use it as part of a hybrid scheme. This way, even if the PQ crypto is broken (either fundamentally, or due to implementation bugs), the scheme as a whole will still be secure under a pre-quantum threat model - so not worse than what you started with, assuming you were using pre-quantum crypto to begin with.
Because he's a security engineer/cryptographer. He's the maintainer of the crypto package in the Go standard library. https://words.filippo.io/hi/. It's literally his job to write the crypto code everyone else uses.
I always took that to mean, "don't come up with your own cryptographic schemes", not "don't implement well-specified and standardized algorithms which are accompanied by a reference implementation and test vectors".
Go can link to C but the process is a bit horrible. I wonder if Go's memory safety in comparison to C and the security implications reverses this a bit.
None of that is an actual implementation of the cryptography, that's just the interfaces. The actual implementations are elsewhere and use architecture specific assembly for anything that needs constant time properties.
No, we use assembly for access to specialized (e.g. AES-NI) or vector instructions, and we do so reluctantly. We much prefer writing cross-platform constant time Go. https://go.dev/wiki/AssemblyPolicy
