crypto/ecdh: provide and/or implement an interface

[rautammi]

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.

[ianlancetaylor]

CC @golang/security

[ericlagergren]

@rautammi alternatively, APIs that need an ECDH private key could accept an interface instead of requiring *ecdh.PrivateKey. There is already crypto.PrivateKey and crypto.PublicKey.

[ericchiang]

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)

[rautammi]

I think @ericchiang is right.
It has been awesome, that well-behaving packages are using crypto.Signer, allowing one to, for example, very easily add PKCS#11 support for TLS or SSH authentication, without any changes to those packages at all.
So, what we need, in addition to this crypto/ecdh, is some kind of crypto.Exchanger interface, which crypto/ecdh then implements, and which usage is recommended for any package agreeing shared secrets using a static private key.

[rautammi]

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.

[rsc]

/cc @golang/security

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[FiloSottile]

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.

KeyGen() -> public key, secret key
Encapsulate(public key) -> ciphertext, shared key
Decapsulate(secret key, ciphertext) -> shared key

With crypto/ecdh,

• KeyGen is ecdh.P256().GenerateKey()
• Encap is ecdh.P256().GenerateKey() followed by ecdh.P256().ECDH(privateKey, peerPublicKey)
  • the ciphertext is just the generated public key
• Decap is ecdh.P256().NewPublicKey() followed by ecdh.P256().ECDH(privateKey, peerPublicKey)

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 KeyExchange(publicKey []byte) would make it possible for it to implement a Signer-like interface, but that only works for DH-like symmetrical KEMs that don't have a separate Encap and Decap. If we had such a method on PrivateKey, it would also make sense to move ECDH to PrivateKey.

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.