Cipheriv/Decipheriv update() and final() each turned their own bytes into a string with Buffer#toString(outputEncoding). The bytes one call returns need not end on a base64 group or a UTF-8 character boundary, so the usual Node.js pattern gives wrong output:

const key = Buffer.alloc(32, 1);
const iv = Buffer.alloc(16, 2);
const cipher = createCipheriv('aes-256-cbc', key, iv);
let out = cipher.update('The quick brown fox jumps over the lazy dog', 'utf8', 'base64');
out += cipher.final('base64');
// before:  'c3rTReM3oXRokPcV3jVbE74CIU3oEaaDtNtq2yNFnVs=BW0kVBRUWZOQcg+E3ysfXA=='
// Node.js: 'c3rTReM3oXRokPcV3jVbE74CIU3oEaaDtNtq2yNFnVsFbSRUFFRZk5ByD4TfKx9c'

The first string has = in the middle and is not valid base64, so decrypting it fails. Decrypting to 'utf8' turns a character split between update() and final() into U+FFFD ('€€€€€€' came back as '€€€€€���'). Block modes hit this with a single update(); stream modes such as GCM hit it across several update() calls.

Change

As in Node.js (getDecoder() in lib/internal/crypto/cipher.js), each instance now keeps one StringDecoder, created by the first call that asks for a string. update() writes to it and final() ends it, so bytes held back from one call come out with the next. Without an output encoding, or with null or 'buffer', both return a Buffer of that call's bytes, which does not include bytes the decoder holds (see the last bullet below).

Behaviour changes, so you can judge whether this wants a compatibility flag:

• Concatenated base64, base64url, utf8 and utf16le output is now correct. A single call's string is no longer padded or complete on its own, which is also how Node.js behaves.
• hex, latin1 and ascii output is unchanged; the decoder never holds bytes for them.
• Changing the output encoding between calls on one instance now throws ERR_INVALID_ARG_VALUE ("cannot be changed from ..."), as in Node.js.
• An unknown output encoding string ('bogus', say) now throws ERR_UNKNOWN_ENCODING even when the call returns no bytes (final() in GCM, for example), as in Node.js. Before, Buffer#toString() returned '' for an empty buffer without checking the encoding. Non-string falsy values such as false, which Node.js treats as no encoding, still throw here as before, now also on zero-byte calls.
• null and 'buffer' as the output encoding now return a Buffer, as no encoding does and as in Node.js. Before, they threw ERR_UNKNOWN_ENCODING when the call returned bytes, and returned '' when it returned none: final() in GCM, CTR or ChaCha20-Poly1305, or a CBC update() with no complete block to return. They have to be handled here, because the decoder checks the encoding on every call and those zero-byte calls would otherwise start to throw. Concatenating the empty Buffer onto a string gives the same result as '' did.
• '' still means utf8, as in Buffer#toString(); Node.js returns a Buffer for it, and I left that difference alone. Because of it, mixing '' with a string encoding other than utf8 on one instance now throws the encoding-change error, also on a call that returns no bytes (update(text, 'utf8', 'hex') + final('') in GCM, for example). Before, each call returned its own string; Node.js does not throw there. I can make '' return a Buffer as in Node.js if you prefer.
• Mixing string and Buffer output on one instance loses data, as it does in Node.js. After a call with base64, base64url, utf8 or utf16le output, a later update() or final() without an output encoding (or with null or 'buffer') returns only its own bytes, not the bytes the decoder still holds. A later call with the encoding returns those bytes out of order; if none follows, they are lost. For base64 and base64url this used to work, because each call's string carried all of its bytes: with the 43-byte text above, update(text, 'utf8', 'base64') followed by final() gave back all 48 ciphertext bytes and now gives back 46, and with aes-256-gcm, calling final() without an encoding only to finish the operation now drops the last byte. utf8 and utf16le output already lost a split character's bytes before. Passing the same encoding to final() avoids the loss, here and in Node.js. hex, latin1 and ascii are not affected.

I did not add a compatibility flag, although src/node/README.md mentions a "No Breaking Changes Without Compatibility Flags" policy. For the usual pattern the old concatenated output was invalid, and the changes match Node.js except for the '' case above. Code that worked before and now behaves differently: changing the output encoding on one instance (now an error, as in Node.js, and also with '', unlike Node.js), an unknown encoding on a zero-byte call (now an error, as in Node.js), a zero-byte call with null or 'buffer' (an empty Buffer instead of ''), and the mixed string/Buffer case with base64 or base64url output (last bullet). I can put the change behind a flag if you prefer.

Open PRs #7541 and #6923 change the inputEncoding check in the same two update() functions. They do not touch these lines and do not fix this bug, and both merge cleanly with this one. One thing to watch: #7541 removes the ERR_INVALID_ARG_VALUE import, which getDecoder() here uses, so whichever lands second needs to keep it.

Tests

Five new cases in src/workerd/api/node/tests/crypto_cipher-test.js:

• base64 and base64url output split across update()/final() (aes-256-cbc) and across two update() calls (aes-256-gcm), each with a decrypt round trip
• utf8 output with a character split across update()/final()
• the error when the output encoding changes between calls
• null and 'buffer' with aes-256-cbc: cipher and decipher update() calls that return no bytes, and final() calls that return bytes
• null and 'buffer' with final() of aes-256-gcm, aes-256-ctr and chacha20-poly1305, for both cipher and decipher, after string output from update()

All five fail on main and pass with this change, and they also pass on Node.js 26:

bazel test //src/workerd/api/node/tests:crypto_cipher-test@ //src/workerd/api/node/tests:crypto_cipher-test@all-compat-flags //src/workerd/api/node/tests:crypto_cipher-test@all-autogates

Also passing locally on macOS arm64: bazel test //src/workerd/api/node/tests/... //src/node/... (421 targets, including the @eslint ones), @gc-stress for crypto_cipher-test and string-decoder-test, and tools/cross/format.py --check on the changed files. Linux and Windows were not run.

This PR was prepared with an AI coding agent (Claude Code). I am responsible for it and will answer review.

🤖 Generated with Claude Code