proposal: crypto/ecdh: add package

[wbl]

Currently crypto/elliptic exposes an interface that uses points and x and y coordinates. This is convenient enough for many applications, but poses problems when trying to work within the constraints of FIPS 140-2.

I'd like to propose a crypto/ecdh package, that has a PublicKey and PrivateKey types.

The methods are GenerateKeypair(*elliptic.Curve) that returns a keypair, and PrivateKey.Agree(*ecdh.PublicKey) that returns bytes as in the NIST recommended generation method used in TLS. It could also take a KDF and apply that, but in that case I'd like to support auxillary input as SP 800-56C permits. Feel free to bikeshed this further.

My uninformed guess is many callers of elliptic outside the standard library are actually implementing something like the ecdh package and would benefit from having it in the standard library.

If I understand correctly currently dev.boringssl doesn't replace any of the functions in elliptic, but could easily replace these with calls to BoringSSL.

I think this is related to the questions in #30158

[DeedleFake]

Funny timing. I was just looking into this myself the other day and was surprised to find that an official package doesn't exist, even in x/crypto.

It should be noted, however, that some form ECDH is fairly easy to do manually with the existing system, though it's certainly far from convenient. For example,

// GenerateECDHKey takes your private key and the peer's public key and returns a symmetric key large enough for use with AES256.
func GenerateECDHKey(curve elliptic.Curve, priv []byte, x, y *big.Int) []byte {
  keycoord, _ := curve.ScalarMult(x, y, priv)
  return sha256.Sum256(keycoord.Bytes())[:]
}

Please note: I am not in any way a cryptography expert. If the above implementation is a bad, please take that as evidence that this should be implemented in the standard library.

[FiloSottile]

I don't have yet formed opinions on the color of the bikeshed, but I am interested in working on a set of APIs for NIST P curves that are []byte based. In fact, what would help a lot is a survey of what developers are using crypto/elliptic for, and how.

[santoshrokade]

Does that mean "package elliptic" is not using FIPS 140-2 boringssl code and thus can not be claimed as fips approved? Is there any plan to include boringssl support for elliptic package?

[santoshrokade]

I don't have yet formed opinions on the color of the bikeshed, but I am interested in working on a set of APIs for NIST P curves that are []byte based. In fact, what would help a lot is a survey of what developers are using crypto/elliptic for, and how.

@FiloSottile Do package elliptic now have a boringssl API support? Or it's still under the future roadmap?

[rsc]

Seems to be a duplicate of #52221.

[rsc]

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group