crypto: extend RSA-OAEP support with oaepHash #28335

tniessen · 2019-06-21T15:17:38Z

This adds an oaepHash option 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), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

This adds an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. This feature is required for interoperability with WebCrypto applications.

panva · 2019-06-21T15:25:29Z

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.

doc/api/crypto.md

tniessen · 2019-06-23T09:02:36Z

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.

We don't have a unified approach for this yet.

If it would even fail with an unrecognized option.

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.

doc/api/crypto.md

src/node_crypto.cc

test/parallel/test-crypto-rsa-dsa.js

sam-github · 2019-06-24T18:36:29Z

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 EVP_PKEY_CTX_set_rsa_oaep_md()/an-option-to-key-object-creation? Of would that be not as useful as doing it at time of encrypt/decrypt?

panva · 2019-06-24T18:42:43Z

I think we should somehow mark node as supporting this new API.

Maybe something to the effect of crypto.constants.RSA_PKCS1_PSS_PADDING and the like that is used to detect PSS support.

panva · 2019-06-24T18:47:55Z

Btw, did you consider allowing the OAEP digest to be set as a property of the private key, with EVP_PKEY_CTX_set_rsa_oaep_md()/an-option-to-key-object-creation? Of would that be not as useful as doing it at time of encrypt/decrypt?

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.

tniessen · 2019-06-24T20:49:43Z

I think we should somehow mark node as supporting this new API.

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.

Btw, did you consider allowing the OAEP digest to be set as a property of the private key, with EVP_PKEY_CTX_set_rsa_oaep_md()/an-option-to-key-object-creation? Of would that be not as useful as doing it at time of encrypt/decrypt?

I did, but then we'd have to add the padding to the key object as well. I am not necessarily opposed to that, but it would add a lot of complexity to KeyObject.

Binding this to a key object would definitely be an obstacle for re-using the same key for different decryption schemes.

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.

panva · 2019-06-24T21:30:56Z

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.

sam-github · 2019-06-24T21:52:35Z

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 oaepHash option. We'd be better off in some ways if a magic value had to be set in oaepHash, like crypto.RSA_PKCS1_OAEP_PADDING_SHA1, because then it would be testable for, but I'm not really suggesting that. Hm, unless we should do it? What happends when 'md2' is used as a digest? They (hopefully) are not all supported. Maybe exposing constants would allow testing for what digests are supported?

I think it would be consistent to add a constant, for example crypto.RSA_PKCS1_OAEP_PADDING_CONFIGURABLE = true, for feature detection, and I don't think we should not do it because we lack some kind of global Node.js feature registry.

tniessen · 2019-07-12T16:32:08Z

@sam-github Sorry for the late reply, I appreciate your concerns.

What happends when 'md2' is used as a digest? They (hopefully) are not all supported. Maybe exposing constants would allow testing for what digests are supported?

All hash functions returned by crypto.getHashes() are accepted by OpenSSL. (md2 is not supported on master.)

We'd be better off in some ways if a magic value had to be set in oaepHash, like crypto.RSA_PKCS1_OAEP_PADDING_SHA1, because then it would be testable for, but I'm not really suggesting that.

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.

I think it would be consistent to add a constant, for example crypto.RSA_PKCS1_OAEP_PADDING_CONFIGURABLE = true, for feature detection, and I don't think we should not do it because we lack some kind of global Node.js feature registry.

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 crypto.constants instead. I can add such a constant to crypto or crypto.constants if you would like. Personally, I think it is neither consistent nor an elegant or very "JavaScript-ish" solution.

panva · 2019-07-12T16:46:25Z

Personally, I think it is neither consistent nor an elegant or very "JavaScript-ish" solution.

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!
}

crypto.constants seems to me like a consistent way for crypto "options object" feature discovery for existing APIs, we already use it for RSASSA-PSS.

tniessen · 2019-07-18T23:32:05Z

Personally, I think it is neither consistent nor an elegant or very "JavaScript-ish" solution.

Neither is this and it doesn't account for backports or custom builds.

@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.

panva · 2019-07-19T12:41:10Z

@tniessen not trying to contradict ;) just saying we already have a kind of established way in crypto.constants

sam-github · 2019-07-22T18:30:31Z

The crypto module by exposing OpenSSL macro/constants allows (sometimes) feature detection in the "C" style of OpenSSL. I'm not suggesting its elegant :-), but I think its consistent with OpenSSL and at least some current crypto features, and that its useful.

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 getCiphers() can be used to look for CCM and gcm ciphers. OCB and PEM-level enc I don't know how to detect.

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.

panva · 2019-07-26T11:29:13Z

... and proceed to land this.

Let's do it, i agree that v10 is so far behind with backports that checking major/minor is likely okay for checking the support.

This adds an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. This feature is required for interoperability with WebCrypto applications. PR-URL: #28335 Fixes: #25756 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]>

PR-URL: #28335 Fixes: #25756 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]>

Notable changes: * **crypto**: * Added an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding (Tobias Nießen) [#28335](#28335). * **deps**: * Updated V8 to 7.6.303.29 (Michaël Zasso) [#28955](#28955). * Improves the performance of various APIs such as `JSON.parse` and methods called on frozen arrays. * Adds the [`Promise.allSettled`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled) method. * Improves support of `BigInt` in `Intl` methods. * For more information: https://v8.dev/blog/v8-release-76 * Updated libuv to 1.31.0 (cjihrig) [#29070](#29070). * `UV_FS_O_FILEMAP` has been added for faster access to memory mapped files on Windows. * `uv_fs_mkdir()` now returns `UV_EINVAL` for invalid filenames on Windows. It previously returned `UV_ENOENT`. * The `uv_fs_statfs()` API has been added. * The `uv_os_environ()` and `uv_os_free_environ()` APIs have been added. * **fs**: * Added `fs.writev` and `fs.writevSync` methods. They allow to write an array of `ArrayBufferView`s to a file descriptor (Anas Aboureada) [#25925](#25925). * **http**: * Added three properties to `OutgoingMessage.prototype`: `writableObjectMode`, `writableLength` and `writableHighWaterMark` [#29018](#29018). * **stream**: * Added an new property `writableEnded` to writable streams. Its value is set to `true` after `writable.end()` has been called. (Robert Nagy) [#28934](#28934). PR-URL: #29210

Notable changes: * crypto: * Added an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. #28335 * deps: * Updated V8 to 7.6.303.29. #28955 * Improves the performance of various APIs such as `JSON.parse` and methods called on frozen arrays. * Adds the Promise.allSettled method. * Improves support of `BigInt` in `Intl` methods. * For more information: https://v8.dev/blog/v8-release-76 * Updated libuv to 1.31.0. #29070 * `UV_FS_O_FILEMAP` has been added for faster access to memory mapped files on Windows. * `uv_fs_mkdir()` now returns `UV_EINVAL` for invalid filenames on Windows. It previously returned `UV_ENOENT`. * The `uv_fs_statfs()` API has been added. * The `uv_os_environ()` and `uv_os_free_environ()` APIs have been added. * fs: * Added `fs.writev`, `fs.writevSync` and `filehandle.writev` (promise version) methods. They allow to write an array of `ArrayBufferView`s to a file descriptor. #25925 https://github.com/nodejs/node/pull/29186/files * http: * Added three properties to `OutgoingMessage.prototype`: `writableObjectMode`, `writableLength` and `writableHighWaterMark` #29018 * stream: * Added an new property `readableEnded` to readable streams. Its value is set to `true` when the `'end'` event is emitted. #28814 * Added an new property `writableEnded` to writable streams. Its value is set to `true` after `writable.end()` has been called. #28934 PR-URL: #29210

Notable changes: * crypto: * Added an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. nodejs#28335 * deps: * Updated V8 to 7.6.303.29. nodejs#28955 * Improves the performance of various APIs such as `JSON.parse` and methods called on frozen arrays. * Adds the Promise.allSettled method. * Improves support of `BigInt` in `Intl` methods. * For more information: https://v8.dev/blog/v8-release-76 * Updated libuv to 1.31.0. nodejs#29070 * `UV_FS_O_FILEMAP` has been added for faster access to memory mapped files on Windows. * `uv_fs_mkdir()` now returns `UV_EINVAL` for invalid filenames on Windows. It previously returned `UV_ENOENT`. * The `uv_fs_statfs()` API has been added. * The `uv_os_environ()` and `uv_os_free_environ()` APIs have been added. * fs: * Added `fs.writev`, `fs.writevSync` and `filehandle.writev` (promise version) methods. They allow to write an array of `ArrayBufferView`s to a file descriptor. nodejs#25925 https://github.com/nodejs/node/pull/29186/files * http: * Added three properties to `OutgoingMessage.prototype`: `writableObjectMode`, `writableLength` and `writableHighWaterMark` nodejs#29018 * stream: * Added an new property `readableEnded` to readable streams. Its value is set to `true` when the `'end'` event is emitted. nodejs#28814 * Added an new property `writableEnded` to writable streams. Its value is set to `true` after `writable.end()` has been called. nodejs#28934 PR-URL: nodejs#29210

Notable changes: * crypto: * Added an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. #28335 * deps: * Updated V8 to 7.6.303.29. #28955 * Improves the performance of various APIs such as `JSON.parse` and methods called on frozen arrays. * Adds the Promise.allSettled method. * Improves support of `BigInt` in `Intl` methods. * For more information: https://v8.dev/blog/v8-release-76 * Updated libuv to 1.31.0. #29070 * `UV_FS_O_FILEMAP` has been added for faster access to memory mapped files on Windows. * `uv_fs_mkdir()` now returns `UV_EINVAL` for invalid filenames on Windows. It previously returned `UV_ENOENT`. * The `uv_fs_statfs()` API has been added. * The `uv_os_environ()` and `uv_os_free_environ()` APIs have been added. * fs: * Added `fs.writev`, `fs.writevSync` and `filehandle.writev` (promise version) methods. They allow to write an array of `ArrayBufferView`s to a file descriptor. #25925 #29186 * http: * Added three properties to `OutgoingMessage.prototype`: `writableObjectMode`, `writableLength` and `writableHighWaterMark` #29018 * stream: * Added an new property `readableEnded` to readable streams. Its value is set to `true` when the `'end'` event is emitted. #28814 * Added an new property `writableEnded` to writable streams. Its value is set to `true` after `writable.end()` has been called. #28934 PR-URL: #29210

This is particularly useful because CloudFront's Field Level Encryption uses RSA_OAEP_SHA256_MGF1, which this library doesn't support yet. Support for oaepHash was added in node 12.9 (nodejs/node#28335), so this won't work for older node versions. It's still a backwards compatible change because by default `oaepHash` will be undefined, as before. I've updated the tests to cover use of the new parameter, but they're not very strict because they both encrypt and decrypt using the same parameter. This means if node silently ignores the oaepHash parameter (as it will in versions < 12.9) the tests will still pass, which isn't great. On the other hand, I think this project may still be being tested on an older version of node, so perhaps the fact the tests won't break is an unexpected blessing. I've also tested this manually against AWS CloudFront's Field Level Encryption and it seems to work. Resolves aws#198

Resolves #198 This is particularly useful because CloudFront's Field Level Encryption uses RSA_OAEP_SHA256_MGF1, which this library doesn't support yet. Support for oaepHash was added in node 12.9 (nodejs/node#28335), so this won't work for older node versions. It's still a backwards compatible change because by default `oaepHash` will be undefined, as before. Added oaepHash feature detection. It is important to be prescriptive in what options will work. Node.js versions that do not support `oaepHash` will silently encrypt data. This means that the encrypted data key would not have the security properties requested. So, `oaep_hash_supported.ts` will attempt to encrypt and report the success. This will happen only once, on initialization. The integration tests have also been updated to verify OAEP test vectors based on OAEP hash support in Node.js.

crypto: extend RSA-OAEP support with oaepHash

9c1a148

This adds an oaepHash option to asymmetric encryption which allows users to specify a hash function when using OAEP padding. This feature is required for interoperability with WebCrypto applications.

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Jun 21, 2019

tniessen added crypto Issues and PRs related to the crypto subsystem. and removed lib / src Issues and PRs related to general changes in the lib or src directory. labels Jun 21, 2019

panva reviewed Jun 21, 2019

View reviewed changes

doc/api/crypto.md Outdated Show resolved Hide resolved

panva reviewed Jun 21, 2019

View reviewed changes

doc/api/crypto.md Outdated Show resolved Hide resolved

bnoordhuis approved these changes Jun 22, 2019

View reviewed changes

BridgeAR reviewed Jun 22, 2019

View reviewed changes

doc/api/crypto.md Outdated Show resolved Hide resolved

doc/api/crypto.md Outdated Show resolved Hide resolved

fixup! crypto: extend RSA-OAEP support with oaepHash

0caa1e5

panva approved these changes Jun 23, 2019

View reviewed changes

jasnell approved these changes Jun 23, 2019

View reviewed changes

tniessen added the semver-minor PRs that contain new features and should be released in the next minor version. label Jun 24, 2019

sam-github reviewed Jun 24, 2019

View reviewed changes

doc/api/crypto.md Show resolved Hide resolved

src/node_crypto.cc Outdated Show resolved Hide resolved

test/parallel/test-crypto-rsa-dsa.js Show resolved Hide resolved

sam-github approved these changes Jul 22, 2019

View reviewed changes

panva approved these changes Jul 22, 2019

View reviewed changes

targos pushed a commit that referenced this pull request Aug 19, 2019

test: add test for OAEP hash mismatch

82edebf

PR-URL: #28335 Fixes: #25756 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]>

targos mentioned this pull request Aug 19, 2019

v12.9.0 release proposal #29210

Merged

codebytere mentioned this pull request Aug 26, 2019

crypto: don't expose OpenSSL internals #29325

Closed

4 tasks

seebees mentioned this pull request Aug 27, 2019

Use oaepHash to support additional padding options. aws/aws-encryption-sdk-javascript#198

Closed

richardTowers mentioned this pull request Jan 15, 2020

feat: Support sha256 and sha512 oaep algorithms aws/aws-encryption-sdk-javascript#240

Merged

1 task

panva mentioned this pull request Mar 18, 2020

doc,crypto: clarify oaepHash option's impact #32340

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

crypto: extend RSA-OAEP support with oaepHash #28335

crypto: extend RSA-OAEP support with oaepHash #28335

tniessen commented Jun 21, 2019

panva commented Jun 21, 2019 •

edited

Loading

tniessen commented Jun 23, 2019

sam-github commented Jun 24, 2019

panva commented Jun 24, 2019

panva commented Jun 24, 2019

tniessen commented Jun 24, 2019

panva commented Jun 24, 2019

sam-github commented Jun 24, 2019

tniessen commented Jul 12, 2019

panva commented Jul 12, 2019

tniessen commented Jul 18, 2019

panva commented Jul 19, 2019

sam-github commented Jul 22, 2019

panva commented Jul 26, 2019 •

edited

Loading

crypto: extend RSA-OAEP support with oaepHash #28335

crypto: extend RSA-OAEP support with oaepHash #28335

Conversation

tniessen commented Jun 21, 2019

Checklist

panva commented Jun 21, 2019 • edited Loading

tniessen commented Jun 23, 2019

sam-github commented Jun 24, 2019

panva commented Jun 24, 2019

panva commented Jun 24, 2019

tniessen commented Jun 24, 2019

panva commented Jun 24, 2019

sam-github commented Jun 24, 2019

tniessen commented Jul 12, 2019

panva commented Jul 12, 2019

tniessen commented Jul 18, 2019

panva commented Jul 19, 2019

sam-github commented Jul 22, 2019

panva commented Jul 26, 2019 • edited Loading

panva commented Jun 21, 2019 •

edited

Loading

panva commented Jul 26, 2019 •

edited

Loading