Replies: 4 comments
-
@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 edit: i have both working internally now - everything defined in the draft as well as ECDH-ES with x25519 keys. |
Beta Was this translation helpful? Give feedback.
-
Plugins: https://github.com/panva/jose-x25519-ecdh |
Beta Was this translation helpful? Give feedback.
-
@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! |
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
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
orderiveFromZ
which would be similar to thederive
function found herehttps://github.com/panva/jose/blob/master/lib/jwa/ecdh/derive.js#L66
but instead of taking
privateKey
andpublicKey
as inputs it takes asharedSecret
as input and applies the ConcatKDF function to that. The currentderive
function would not change its interface but could call thederivedFromShared
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.
Beta Was this translation helpful? Give feedback.
All reactions