Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355
Ed25519 and Ed448 certificates are finally coming.
https://tools.ietf.org/html/draft-ietf-curdle-pkix-07 is the draft for X.509, and Ed25519/Ed448 are supported directly by TLS 1.3.
The implementation is not hard and I have a branch of it already: master...FiloSottile:filippo/ed25519
The problem is that we'll have to vendor golang.org/x/crypto/ed25519 for the primitive functionality (like we did with golang.org/x/crypto/curve25519), but that will mismatch the PublicKey and PrivateKey types, which are exposed to the user in tls.Certificate.PrivateKey and x509.Certificate.PublicKey. A user-supplied ed25519.PrivateKey would not type-assert to the vendored ed25519.PrivateKey, and a parsed ed25519.PublicKey would not type-assert to the application side one.
I can think of three decent solutions off the top of my head:
We also need to decide if we want to bring Ed448 on board at the same time. We don't have a Ed448 implementation yet.
The crypto/tls and crypto/x509 APIs leak PublicKey and PrivateKey types, so in order to add support for Ed25519 certificates we need the ed25519 package in the stdlib. It's also a primitive that's reasonable to use directly in applications, as it is a modern, safe and fast signing algorithm, for which there aren't higher level APIs. (The nacl/sign API is limiting in that it repeats the message.) A few docs changes will come in a follow-up, and a CL will land on golang.org/x/crypto/ed25519 to make it a type alias wrapper on Go 1.13+. Updates #25355 Change-Id: I057f20cc7d1aca2b95c29ce73eb03c3b237e413f Reviewed-on: https://go-review.googlesource.com/c/go/+/174945 Run-TryBot: Filippo Valsorda <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Adam Langley <email@example.com>
Updates golang/go#25355 Change-Id: Id077d96749194943914d956bd8e79e5272477d7e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/182698 Reviewed-by: Russ Cox <firstname.lastname@example.org>
Any progress on the Ed448 implementation? Perhaps https://github.com/otrv4/ed448 might help. I would rather have it in the official crypto library. Might want to take a look at SUPERCOP's implementation and https://sourceforge.net/p/ed448goldilocks/wiki/Home/ as well. The two may be identical, the author is Mike Hamburg in both cases.
By the way, is there a chance of integrating (and using it throughout the library of course) memguard (https://github.com/awnumar/memguard) into the crypto library?