Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355

Closed
FiloSottile opened this issue May 11, 2018 · 16 comments
Closed

proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355

FiloSottile opened this issue May 11, 2018 · 16 comments
Labels
FrozenDueToAge Proposal Proposal-Accepted Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@FiloSottile
Copy link
Contributor

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:

  1. define Ed25519PublicKey and Ed25519PrivateKey types in crypto/x509, which are easy to cast to/from, as they're nothing but []byte; if/when we promote ed25519 to the stdlib, alias and deprecate them

  2. use []byte for both types, document it

  3. simply promote ed25519 to the stdlib

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.

See also: https://groups.google.com/forum/#!topic/golang-dev/FNfJzm-BDno

@FiloSottile FiloSottile added the Proposal-Crypto Proposal related to crypto packages or other security issues label May 11, 2018
@FiloSottile FiloSottile added this to the Go1.12 milestone May 11, 2018
@arunjohn99
Copy link

Thanks, @FiloSottile . I really like option 3, clean and consistent with existing approach. Followed your footsteps and ported the changes for ed25519 under crypto package to support option 3

@mattghali
Copy link

hi there, i am trying to get Wireguard key generation going inside terraform, using terraform-provider-tls, and ed25519 support in the x509 module would make it really easy.

@arunjohn99
Copy link

@FiloSottile Given that we are probably 2-3 weeks away from 1.12 release, can you confirm whether this would make it to 1.12

@FiloSottile
Copy link
Contributor Author

Definitely not, the proposal is not decided yet, and 1.12 has been in feature freeze for months.

@arunjohn99
Copy link

Bummer! Any thoughts on when this would be supported?

@FiloSottile
Copy link
Contributor Author

The more detailed reports of how this would be used we have, the more likely it is that it will be soon. It's a matter of prioritization, and of making sure we are not adding to the stdlib something we don't really need.

@lorenz
Copy link
Contributor

lorenz commented Feb 11, 2019

I would definitely switch over most internal certificate issuance if EdDSA (specifically Ed25519) is supported since its design is much more robust than ECDSA and RSA and it performs better than both.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/174945 mentions this issue: crypto/ed25519: promote from golang.org/x/crypto/ed25519

@FiloSottile
Copy link
Contributor Author

FiloSottile commented May 2, 2019

Discussed with @rsc, we're promoting crypto/ed25519 to the standard library. \o/

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/175478 mentions this issue: crypto/x509: add support for Ed25519 certificates and keys

gopherbot pushed a commit that referenced this issue May 6, 2019
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 <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
@jackivanov
Copy link

@FiloSottile In what version would it be included?

@lorenz
Copy link
Contributor

lorenz commented May 8, 2019

@jackivanov Ed25519 is going to be available in the standard library as of 1.13 (unless something drastic happens), the certificate support is still being reviewed, but will most likely end up in 1.13 too.

gopherbot pushed a commit that referenced this issue May 15, 2019
Based on RFC 8410.

Updates #25355

Change-Id: If7abb7eeb0ede10a9bb3d2004f2116e587c6207a
Reviewed-on: https://go-review.googlesource.com/c/go/+/175478
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/177698 mentions this issue: crypto/tls: add support for Ed25519 certificates in TLS 1.2 and 1.3

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/182698 mentions this issue: ed25519: turn into a wrapper for crypto/ed25519 beginning with Go 1.13

gopherbot pushed a commit to golang/crypto that referenced this issue Jun 18, 2019
Updates golang/go#25355

Change-Id: Id077d96749194943914d956bd8e79e5272477d7e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/182698
Reviewed-by: Russ Cox <rsc@golang.org>
@odiferousmint
Copy link

odiferousmint commented Sep 2, 2019

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?

@FiloSottile
Copy link
Contributor Author

We don't really see enough adoption for Ed448 to justify carrying a full implementation in the standard library.

I discuss how effectively applying memguard would be a much larger effort (and carry a large complexity cost) in #21865.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Proposal Proposal-Accepted Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
None yet
Development

No branches or pull requests

8 participants