Add function to expose pure ConcatKDF without EC multiplication

[coder5876]


Problem description

This library does not yet support ECDH with certain elliptic curves such as X25519. A helper function to expose just the ConcatKDF without the elliptic curve multiplication step would be useful for developers using external libraries for the elliptic curve multiplication.

Solution description


We can create & expose a function deriveFromShared or deriveFromZ which would be similar to the derive function found here



https://github.com/panva/jose/blob/master/lib/jwa/ecdh/derive.js#L66



but instead of taking privateKey and publicKey as inputs it takes a sharedSecret as input and applies the ConcatKDF function to that. The current derive function would not change its interface but could call the derivedFromShared functions internally.


Alternatives considered

The libsodium library supports key derivation but the KDF used there uses the blake2b hash rather than sha256. We would prefer to use the sha256 based KDF in this library for compatibility with other IETF standards.


• i have searched the configuration section for this feature and couldn't find it
• i have searched the issues tracker on github for similar requests and couldn't find anything related.

[panva]

@christianlundkvist even if the pure ConcatKDF function was exposed its output would not be usable by this library to form a JWE with the alg being "ECDH-ES", the library is just not set up to do these individual steps, its set up to do the whole flow for a developer who doesn't know / care how to derive keys etc...

Best course of action at the moment is chiming on the node thread here to add the native support ECDH in node using x25519 and x448 keys

Separately, i'm working on big refactoring that enables (to some extent) to register algorithm support. I'm using https://tools.ietf.org/html/draft-amringer-jose-chacha-01 as a guinea pig to verify that this refactoring is usable. Within a ~week there will be a new minor release with the refactoring and a chacha extension that registers these algorithms. I'll see if it's possible with this refactor to hijack the ECDH-ES family of algorithms when used with an OKP key to do x25519 secret derivation using libsodium as well. x448 is out of reach even with libsodium unfortunately.

edit: i have both working internally now - everything defined in the draft as well as ECDH-ES with x25519 keys.

[panva]

Plugins:

https://github.com/panva/jose-x25519-ecdh
https://github.com/panva/jose-chacha

[coder5876]

@panva thanks for the info! Actually those plugins are very interesting, I'll take a look at them. If you are expecting these algorithms to be supported shortly in your library then that would fulfill my needs, thanks again!

[panva]

If you are expecting these algorithms to be supported shortly in your library then that would fulfill my needs

These are my plugins, use them if you need those algorithms.

Until e.g. ChaCha is an RFC it won't land in the core library, but i maintain this plugin. Similar to that, unless X25519 and X448 ECDH lands in Node.js i won't be adding it to the core lib because to implement it, i have to include libsodium which beats the "no dependency" goal of this library.

The plugins are written in a way that if the algorithms they are for land in a new version you'll get a deprecation warning that they're no longer needed.