proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355
Comments
FiloSottile
added
the
Proposal-Crypto
|
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 |
|
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. |
|
@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 |
|
Definitely not, the proposal is not decided yet, and 1.12 has been in feature freeze for months. |
|
Bummer! Any thoughts on when this would be supported? |
|
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. |
|
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. |
|
Change https://golang.org/cl/174945 mentions this issue: |
|
Discussed with @rsc, we're promoting |
|
Change https://golang.org/cl/175478 mentions this issue: |
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>
|
@FiloSottile In what version would it be included? |
|
@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. |
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>
|
Change https://golang.org/cl/177698 mentions this issue: |
|
Change https://golang.org/cl/182698 mentions this issue: |
Updates golang/go#25355 Change-Id: Id077d96749194943914d956bd8e79e5272477d7e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/182698 Reviewed-by: Russ Cox <rsc@golang.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? |
|
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. |
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:
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
use []byte for both types, document it
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
The text was updated successfully, but these errors were encountered: