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
crypto/ecdh: provide and/or implement an interface #56052
Comments
CC @golang/security |
@rautammi alternatively, APIs that need an ECDH private key could accept an interface instead of requiring |
For reference, go-piv has supported ECDH backed by a YubiKey for a while now: https://pkg.go.dev/github.com/go-piv/piv-go/piv?utm_source=godoc#ECDSAPrivateKey.SharedKey I don't think crypto/ecdh is the place to support this? E.g. crypto/rsa and crypto/ecdsa don't support out-of-process private keys. If there are packages that want to support both crypto/ecdh and external keys, that interface probably belongs with those packages or in the crypto package (like crypto.Signer/crypto.Decrypter) |
I think @ericchiang is right. |
I would say the person who invented crypto.Signer was a genius! Let she or he design an equally generic and future proof interface for key exchange too. |
/cc @golang/security |
This proposal has been added to the active column of the proposals project |
I agree that it would be nice to have an interface type for key exchanges, and while it might be too late to come up with one for Go 1.20, we should make sure the crypto/ecdh package design is not hostile to one. Looking forward, it would probably be appropriate for it to fit the shape of KEMs, to work with PQC KEMs. A KEM has three operations: KeyGen, Encap, and Decap.
With crypto/ecdh,
because ECDH is very symmetrical. While thinking about this I also started having doubts on whether ECDH should be a method on Curve or on PrivateKey. My initial thinking was that a method on PrivateKey like I'd be interested to hear proposals for KEM-friendly interfaces, and how crypto/ecdh might implement them. I went through a few options but found none that I liked so far. |
For existing PQC-KEMs, I think an interface would be very similar to crypto.Decrypter, And I would go as far as stating that it would not be too unintuitive to use crypto.Decrypter for that purpose. |
What would the API be specifically? |
Exchanger would be an opaque private key. |
Talked to @FiloSottile about this, and he believes we should move ECDH to the PrivateKey type, and then an interface can be defined (not necessarily in this package) that PrivateKey implements. |
To elaborate on my comment from last week, the idea is to take ecdh.PrivateKey, which already has Bytes, Curve, Equal, Public, and PublicKey methods, and move the ECDH method over there too. Then any hardware key can implement these methods, and code that wants to take either kind can define an interface listing the methods it needs. In this case we would not need to define an interface in the standard library. Does anyone object to that approach? |
Change https://go.dev/cl/450335 mentions this issue: |
Change https://go.dev/cl/451095 mentions this issue: |
For golang/go#56052 Change-Id: If34d01132e221ff525319e43d127ef14579f9054 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/451095 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Joedian Reid <joedian@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Run-TryBot: Joedian Reid <joedian@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
Reopening. |
This was marked as closed by the CL that moved the ECDH method. Now it is possible to define an interface outside the standard library that ecdh.PrivateKey implements, and hardware keys can implement it too. So it seems like we don't need to add an interface to the standard library right now. Do I have that right? |
Yeah, that sounds right to me. Eventually we might define a ECDH or KEM interface in the standard library if we need to consume it, but in the meantime hardware implementations can implement the PrivateKey methods and use their own interface. Sorry for jumping the gun on the proposal process, I hadn't realized this wasn't accepted yet and I wanted to get the changes in before the freeze since crypto/ecdh is new in Go 1.20. |
Sounds like no one objects, and since the work is already done, I'll just move it to accepted and close it. |
No change in consensus, so accepted. |
For golang/go#56052 Change-Id: If34d01132e221ff525319e43d127ef14579f9054 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/451095 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Joedian Reid <joedian@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Run-TryBot: Joedian Reid <joedian@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
I am very sorry for being very late with this one. Would it be possible to expose PrivateKey as an interface, allowing one to create implementations of Curve and PrivateKey which utilizes a static private key from an HSM for ECDH operation? Somewhat following the idiom from crypto.Signer.
The text was updated successfully, but these errors were encountered: