iframe-proxy

npaun · 2026-10-20T04:30:42Z

createCipheriv(alg, key, null): a null IV is now treated as an empty IV, matching Node.js, which documents null for ciphers without an IV (e.g. AES-ECB). Ciphers that need an IV still throw Invalid initialization vector, and undefined still throws ERR_INVALID_ARG_TYPE, as in Node.js.
publicEncrypt({ key: keyObject, padding }, data) (and publicDecrypt / privateEncrypt / privateDecrypt): a KeyObject or CryptoKey passed as the key property of an options object is now accepted. The four functions each had a copy of the key-resolution logic, and now share prepareAsymmetricKey().

Compatibility: both inputs previously threw ERR_INVALID_ARG_TYPE, so accepting them can't break a working Worker. No compat flag is needed.

Out of scope: Node.js also accepts a private key for publicEncrypt / publicDecrypt, deriving the public key from it. workerd still rejects that with ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE.

Test plan

New tests in crypto_cipher-test.js:

cipherivNullIv: AES-128-ECB with a null IV gives the same ciphertext as Node.js and round-trips. CBC with null and ECB with undefined still throw.
keyObjectInOptions: { key: KeyObject, padding: RSA_NO_PADDING } works with all four functions. The output matches Node.js and the PEM-string path, and a wrong-type key still throws.

createCipheriv() and createDecipheriv() rejected a null IV, even though Node.js documents null as the IV for ciphers that don't use one, such as AES-ECB. A null IV is now treated as an empty IV, so it behaves exactly like Buffer.alloc(0). Ciphers that require an IV still reject it, and undefined is still rejected, as in Node.js. publicEncrypt(), publicDecrypt(), privateEncrypt() and privateDecrypt() rejected a KeyObject or CryptoKey passed as the `key` property of an options object, e.g. publicEncrypt({ key: createPublicKey(pem), padding }, data). Node.js accepts this so callers can specify `padding` and similar options alongside a KeyObject. The four functions each had a copy of the key resolution logic; they now share prepareAsymmetricKey(), which also unwraps such an options object. Compatibility: both inputs previously threw ERR_INVALID_ARG_TYPE, so accepting them cannot change the behavior of a working Worker, and no compatibility flag is needed. Tests were not run locally because of an outage affecting the cfdata.org domains that edgeworker's bazel build depends on; CI is the verification for this change. Fixes #7772 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

clanky-the-clanker · 2026-10-20T04:55:53Z

✅ Approved — No issues found. A null IV now maps to an empty IV, and the new shared prepareAsymmetricKey() still checks the key type on every path, including a KeyObject or CryptoKey passed inside an options object. Tests cover both changes.

_{The decision is advisory: this comment never approves, blocks or requests changes on the pull request.}

✅ All checks passed

🔒 Security: ✅ LGTM

No exploitable issues found.

Key type check: prepareAsymmetricKey checks public vs. private on every path, including a KeyObject or CryptoKey unwrapped from options.key. A wrong-type key still throws ERR_CRYPTO_INVALID_KEY_OBJECT_TYPE.
Null IV: an empty IV matches Node.js behaviour for ECB modes. Ciphers that need an IV still reject it, so no IV-dependent mode is weakened.

📖 AGENTS.md: ✅ LGTM

No AGENTS.md updates are needed for this change.

📋 Code Quality: ✅ LGTM

Null IV: getIv() now treats a null IV as an empty Uint8Array (src/node/internal/crypto_cipher.ts:155).

undefined still throws ERR_INVALID_ARG_TYPE.
Ciphers that need an IV, such as CBC, still fail the IV-length check, and the new test covers that case.

prepareAsymmetricKey():

It behaves as before for a CryptoKey or KeyObject passed directly, and for PEM strings or options objects.
It adds support for { key: KeyObject | CryptoKey }.
For strings, buffers and null, the optional-chained .key read returns undefined, so those inputs still go through createPublicKey / createPrivateKey.
Each of the four callers still reads encoding from the original argument.

Tests:

The new tests cover a null IV, an undefined IV and CBC rejection.
They exercise all four asymmetric functions with a wrapped KeyObject, check the wrong-type error, and compare output against the PEM path and known Node.js output.
There is no test for { key: CryptoKey }. It uses the same code branch as KeyObject, so this is not a real gap.

⚡ Performance: ✅ LGTM

No performance concerns.

📝 Documentation: ✅ LGTM

The new comments describe the current behaviour and follow the repository's comment guidelines.

_{Reviewed commit: db3a6efb}

ask-bonk · 2026-10-20T04:57:47Z

Review: 2 findings (1 blocking, 1 warning).

Adds Node-compatible null-IV and wrapped asymmetric-key handling with targeted tests.

_{Reviewed commit: db3a6efb · github run}

ask-bonk · 2026-10-20T04:57:49Z

 };

+export const keyObjectInOptions = {
+  test(_, env) {


[WARNING] This covers wrapped KeyObject values only, although prepareAsymmetricKey() has a separate inner instanceof CryptoKey branch. A regression that stops unwrapping a WebCrypto CryptoKey would still pass this test.

Suggested change

test(_, env) {

async test(_, env) {

const { publicKey: cryptoPublicKey, privateKey: cryptoPrivateKey } =

await crypto.subtle.generateKey(

{

name: 'RSA-OAEP',

modulusLength: 2048,

publicExponent: new Uint8Array([1, 0, 1]),

hash: 'SHA-256',

},

true,

['encrypt', 'decrypt']

);

const cryptoInput = Buffer.alloc(256);

cryptoInput.set(Buffer.from('hello'));

const cryptoEncrypted = publicEncrypt(

{ key: cryptoPublicKey, padding: constants.RSA_NO_PADDING },

cryptoInput

);

deepStrictEqual(

privateDecrypt(

{ key: cryptoPrivateKey, padding: constants.RSA_NO_PADDING },

cryptoEncrypted

),

cryptoInput

);

const cryptoSigned = privateEncrypt(

{ key: cryptoPrivateKey, padding: constants.RSA_NO_PADDING },

cryptoInput

);

deepStrictEqual(

publicDecrypt(

{ key: cryptoPublicKey, padding: constants.RSA_NO_PADDING },

cryptoSigned

),

cryptoInput

);

const pub = createPublicKey(env['rsa_public.pem']);

npaun marked this pull request as ready for review October 20, 2026 04:54

npaun requested review from a team as code owners October 20, 2026 04:54

ask-bonk Bot reviewed Oct 20, 2026

View reviewed changes

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

Accept null IV and wrapped KeyObject in node:crypto - #7837

Accept null IV and wrapped KeyObject in node:crypto#7837
npaun wants to merge 1 commit into
mainfrom
npaun/node-crypto-null-iv-keyobject

npaun commented Oct 20, 2026 •

edited

Loading

Uh oh!

clanky-the-clanker Bot commented Oct 20, 2026

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

📋 Code Quality: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

ask-bonk Bot commented Oct 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

ask-bonk Bot Oct 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-  test(_, env) {
+  async test(_, env) {
+    const { publicKey: cryptoPublicKey, privateKey: cryptoPrivateKey } =
+      await crypto.subtle.generateKey(
+        {
+          name: 'RSA-OAEP',
+          modulusLength: 2048,
+          publicExponent: new Uint8Array([1, 0, 1]),
+          hash: 'SHA-256',
+        },
+        true,
+        ['encrypt', 'decrypt']
+      );
+    const cryptoInput = Buffer.alloc(256);
+    cryptoInput.set(Buffer.from('hello'));
+    const cryptoEncrypted = publicEncrypt(
+      { key: cryptoPublicKey, padding: constants.RSA_NO_PADDING },
+      cryptoInput
+    );
+    deepStrictEqual(
+      privateDecrypt(
+        { key: cryptoPrivateKey, padding: constants.RSA_NO_PADDING },
+        cryptoEncrypted
+      ),
+      cryptoInput
+    );
+    const cryptoSigned = privateEncrypt(
+      { key: cryptoPrivateKey, padding: constants.RSA_NO_PADDING },
+      cryptoInput
+    );
+    deepStrictEqual(
+      publicDecrypt(
+        { key: cryptoPublicKey, padding: constants.RSA_NO_PADDING },
+        cryptoSigned
+      ),
+      cryptoInput
+    );
+    const pub = createPublicKey(env['rsa_public.pem']);

Sunbelt Computer Software

PL/B Language Development and Support

Conversation

npaun commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test plan

Uh oh!

clanky-the-clanker Bot commented Oct 20, 2026

🔒 Security: ✅ LGTM

📖 AGENTS.md: ✅ LGTM

📋 Code Quality: ✅ LGTM

⚡ Performance: ✅ LGTM

📝 Documentation: ✅ LGTM

Uh oh!

ask-bonk Bot commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ask-bonk Bot Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

npaun commented Oct 20, 2026 •

edited

Loading

ask-bonk Bot commented Oct 20, 2026 •

edited

Loading