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 text was updated successfully, but these errors were encountered:
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?