crypto: X25519 and X448 and ECDH

[panva]

Is your feature request related to a problem? Please describe.

Implementing CFRG curves ECDH-ES

Resources:

• https://tools.ietf.org/html/rfc7748 - Elliptic Curves for Security
• https://tools.ietf.org/html/rfc8037 - CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)

Describe the solution you'd like

The following WIP on Node already paves the way for EdDSA signatures

• crypto: fix EdDSA support for KeyObject #26319
• crypto: add support for x25119 and x448 key pair generation #26774
• crypto: add crypto.sign() and crypto.verify() #26611

👇
To complete the implementation i'd like X25519 and X448 curves/functions to be usable with crypto.createECDH(curveName) to get JOSE ECDH-ES with these OKP keys working.

I understand from this thread (#18770), particularly this comment and the conversation below that it may end up being a separate API and that's fine.

It seems the curves are already somewhat in because the returned error differs when providing nonsense vs. valid crv/function name.

[bnoordhuis]

I don't think it makes sense to bolt X448/X25519 support onto crypto.createECDH() - that API is only expected to work with the curve names from crypto.getCurves().

Supporting them through crypto.generateKeyPair() however might be a good way forward.

It seems the curves are already somewhat in because the returned error differs when providing nonsense vs. valid crv/function name.

The difference is because "X448" and "X25519" are valid NIDs (identifiers.) That doesn't mean they're valid curve names, however.

To wit, crypto.createECDH('AES-128-ECB') and crypto.createECDH('valid') (!) throw the same error.

[panva]

@bnoordhuis Ed25519 and Ed448 keys through generateKeyPair is already on the way.
However, be it through createECDH or any other API the X448/X25519 functions are usable in Elliptic Curve Diffie-Hellman. createECDH is where i as a user would expect to look for its support.

The difference is because "X448" and "X25519" are valid NIDs (identifiers.) That doesn't mean they're valid curve names, however.
To wit, crypto.createECDH('AES-128-ECB') and crypto.createECDH('valid') (!) throw the same error.

Thanks for pointing that out.

[bnoordhuis]

For technical background: crypto.createECDH() currently is a wrapper around openssl's EC_KEY family of functions.

X448 and X25519 on the other hand are implemented through the EVP_PKEY functions - more specifically EVP_PKEY_keygen() - and that's precisely what crypto.generateKeyPair() is a wrapper around.

However, after thinking about it some more, extending crypto.createECDH() could be an option if it was possible to rewrite it using EVP_PKEY functions like EVP_PKEY_derive().

I don't know exactly how feasible that is but my gut feeling is that it's doable.

[DuBistKomisch]

I'm interested in migrating to this API from curve25519-n, it looks like the x25519 key generation has landed, are we just waiting for the equivalent of ECDH#computeSecret?

[panva]

I recall @tniessen wanted to take a stab at this a few months back.

[jurelik]

Any updates on this issue? If anyone has any information on when we can expect x25519/x448 included in crypto.createECDH(), it would be much appreciated.

[sam-github]

@jurelik I don't see that anyone volunteered to implement this, much less comitted to a timeline.

Are you interested in implementing the feature? We are always looking for more collaborators on crypto support, and there are people who would help get a PR in shape if you needed any help along the way.

[awoie]

Is anyone working on this?

Decentralized Identity Foundation (DIF) is very interested in using this feature. X25519 became quite popular in our community. We are about to finalize a spec that uses ECDH-ES (X25519) and it would be great to have a node reference implementation: https://github.com/decentralized-identity/did-siop/blob/master/docs/index.html.

[panva]

Resolved by crypto.diffieHellman(...) introduced in #31178