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: ECDH interface and dev.boringssl #43656

Open
wbl opened this issue Jan 12, 2021 · 4 comments
Open

proposal: ECDH interface and dev.boringssl #43656

wbl opened this issue Jan 12, 2021 · 4 comments

Comments

@wbl
Copy link

@wbl wbl commented Jan 12, 2021

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

@gopherbot gopherbot added this to the Proposal milestone Jan 12, 2021
@DeedleFake
Copy link

@DeedleFake DeedleFake commented Jan 12, 2021

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
Copy link
Contributor

@FiloSottile FiloSottile commented Jan 12, 2021

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.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jan 13, 2021
@santoshrokade
Copy link

@santoshrokade santoshrokade commented Feb 5, 2021

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
Copy link

@santoshrokade santoshrokade commented Feb 8, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants