Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcrypto: extend RSA-OAEP support with oaepHash #28335
Conversation
nodejs-github-bot
added
C++
lib / src
labels
Jun 21, 2019
tniessen
added
crypto
and removed
lib / src
labels
Jun 21, 2019
This comment has been minimized.
This comment has been minimized.
|
I'll give the branch it a try! Quick note, it would be great if the "support" for this was detectable, other than semver checking the process node version or trying and failing of course. If it would even fail with an unrecognized option. |
This comment has been minimized.
This comment has been minimized.
We don't have a unified approach for this yet.
We cannot patch this into existing Node.js releases, and I don't think we would if we could. It would most likely be a breaking change. |
tniessen
added
the
semver-minor
label
Jun 24, 2019
This comment has been minimized.
This comment has been minimized.
|
I think we should somehow mark node as supporting this new API. Backporting the throwing of errors is not possible, as you say, but some constant could be exported for crypto that could be checked for existence, that would be helpful. As-is, I think that it can only be detected by a fragile comparison against node version (fragile because as the feature is backported the comparison needs changing), or a speculative RSA key gen and encrypt then decrypt operation (using decrypt failure to indicate a mismatch of digest algs). Btw, did you consider allowing the OAEP digest to be set as a property of the private key, with |
This comment has been minimized.
This comment has been minimized.
Maybe something to the effect of |
This comment has been minimized.
This comment has been minimized.
Binding this to a key object would definitely be an obstacle for re-using the same key for different decryption schemes. I prefer an encrypt/decrypt option like this, very useful, very flexible. |
This comment has been minimized.
This comment has been minimized.
I agree, but I don't think we should use ad hoc solutions for something as important as feature detection. The same problem exists for many, many other features (CCM, OCB, RSA-PSS, PEM-level encryption, GCM validation, ...), and that's only counting crypto.
I did, but then we'd have to add the
Side note: Not being able to do that is considered good design by many cryptographers. It is often considered bad practice to use the same key for different algorithms. |
This comment has been minimized.
This comment has been minimized.
|
I know. In this case the same exposed public RSA JWK is used to encrypt messages with JWA RSA1_5 or RSA-OAEP(-256) and the recipient decrypts those. Were it vice versa i wouldn’t mention it. For instance: An OAuth 2 exposes the public key and accepts confidental signed and encrypted authorization requests from many relying parties. These may use different JWAs. |
This comment has been minimized.
This comment has been minimized.
|
Using crypto constants for feature detection is pretty common, we do it lots of places. Its how TLS1.3 is detected, and I assume the existence of crypto.constants.RSA_PKCS1_OAEP_PADDING can also be used to detect support for OAEP, but not of support for this new I think it would be consistent to add a constant, for example |
This comment has been minimized.
This comment has been minimized.
|
@sam-github Sorry for the late reply, I appreciate your concerns.
All hash functions returned by
True, it would help, but it would be inconsistent with other APIs that accept hash functions, and since all hash functions are accepted by OpenSSL, we would either have to manually restrict that or add constants for all hash functions.
That would make feature detection more difficult in ESM since undefined "constants" cannot be imported, yet this alone would only be a minor inconvenience and could be "solved" by adding the constant to |
This comment has been minimized.
This comment has been minimized.
Neither is this and it doesn't account for backports or custom builds. const [major, minor] = process.version.substr(1).split('.').map(x => parseInt(x, 10))
if (major > 12 || (major === 12 && minor >= xx) {
// yay support!
}
|
This comment has been minimized.
This comment has been minimized.
@panva That does not contradict what I said. As I wrote before, I can add such a constant, but that does not change the fact that I don't think it is an elegant solution. I would like to hear Sam's opinion on this. If he is in favor of such a constant, I'll add it and proceed to land this. |
This comment has been minimized.
This comment has been minimized.
|
@tniessen not trying to contradict ;) just saying we already have a kind of established way in crypto.constants |
This comment has been minimized.
This comment has been minimized.
|
The Are you sure none of CCM, OCB, RSA-PSS, PEM-level encryption, GCM validation are detectable using contants? I think RSA_PKCS1_PSS_PADDING exists for PSS, and If @panva and others find it impossible to detect the existence of the feature, the feature might not be used, which would be a shame. Note that a hard coded dependency on node > 12.x.y (where x.y is where it was released) would fail to detect backports, so would assume it was unsupported even if it was. But at this time, 10.x is so far behind that maybe this will never backport, so that's OK. I will do some thinking of a more general purpose feature detection system for Node.js, but that won't happen fast, if ever. If you can't think of an OpenSSL (or OpenSSL-like) constant you'd like to expose to indicate the feature's existence (or the XOF variable length feature, which is in the same category), lets get this landed. |
tniessen commentedJun 21, 2019
This adds an
oaepHashoption to asymmetric encryption which allows users to specify a hash function when using OAEP padding. This feature is required for interoperability with WebCrypto applications.Fixes: #25756
cc @nodejs/crypto @sam-github @panva
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes