The author of the post happens to be the person who implements your crypto, so you don't have to roll your own: https://github.com/FiloSottile.

(I personally also wouldn't use OpenSSL as an example of good cryptographic code)

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.

[1] https://go.dev/src/crypto/internal/boring/README

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

Sibling comments have already addressed the fact that Filippo is one of the people you're probably "best leaving" cryptography implementation to.

The author has actually talked explicitly about "Don't roll your own crypto":

https://securitycryptographywhatever.com/2021/07/31/the-grea...

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.

FiloSottile is one of the handful of people in the world whose crypto code you use instead of rolling your own.

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".

This is a good point, most of Go's crypto library seems to be written in go: https://cs.opensource.google/go/go/+/master:src/crypto/crypt...

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.