Scheduling the Go 1.20 crypto job

As you may know, I left Google in the spring to try to make the concept of a professional Open Source maintainer a reality. I remain as a maintainer of the Go Cryptography Standard Library, and will seek funding from companies that depend on it, want to ensure its security and reliability, and would like to get a direct line to the maintainers of their critical business infrastructure . (If that sounds like you, reply to this email!)

In the meantime, however, Go's development cycle is moving forward inexorably, with Go 1.20 feature freezing in early November. Once the main Go tree is frozen, I plan to work on x/crypto/ssh and age, but in the meantime I have a few things I'm excited about for Go 1.20.

The most visible change will be the arrival of the new crypto/ecdh package that I proposed and implemented earlier this year. The package provides a safe, [] byte-based, easy-to-use API for Elliptic Curve Diffie-Hellman over Curve25519 and NIST curves (P-256 and company, but no P-224 if we can get away with it). /p>

crypto/ecdh was made possible through a lengthy refactoring of elliptic curve implementations in the standard library. Between Go 1.17 and Go 1.19 most critical code was moved to safer low level APIs under crypto/internal/nistec and crypto/internal/edwards25519, large chunks were replaced with code generated from templates formally verified from fiat-crypto, making every curve time constant, most group logics have been replaced with modern full formulas, and even assembly has been massaged to implement the same functions on all architectures and adapt to the nistec API. Some assemblies are gone, in fact!

(Here are all the changes. Some clever uses of generics if you're curious.)

The goal of the package is to replace the main use case of the now deprecated crypto/elliptical API, which has a hard-coded dependency on the large and complex variable-time math/big package. crypto/elliptic is now just a compatibility wrapper. Any more advanced use of crypto/elliptic can switch to filippo.io/nistec which is an exported version of crypto/internal/nistec, or filippo.io/edwards25519 which is an exported version of crypto/internal/edwards25519.

So what's left to do in Go 1.20?

First, upload the new package, which has already been submitted! Then the addition and review of new tests (including Roland's Wycheproof integration), which actually revealed that there are fewer (!!) edge cases than I had documented at the 'origin. Finally, review of BoringCrypto integration by Russ.

There is an even broader goal behind this work: moving the math/big completely out of the security perimeter, which means making it inaccessible to cryptographic APIs and protocols exposed to attackers.

math/big is a large general-purpose integer library, it's not constant time, and it's full of complex code which, while useless for cryptography, has repeatedly led to vulnerabilities security in encryption packages. While this is a convenient way to bootstrap the standard Go crypto library, math/big has no place in crypto code in 2022.

crypto/ecdh allows us to deprecate crypto/elliptic and allows us to bypass math/big in the ECDHE implementation of crypto/tls.

The next step is to modify crypto/ecdsa to use crypto/internal/nistec for group operations on known curves, discourage the use of custom curves, and replace scalar field operations with...something. That something could be fiat-crypto field implementations for each scalar field (P-256, P-384, and P-521) with t...