feat(ext/node): add AES-CCM cipher support

[bartlomieju]

Summary

• Implements full AES-CCM (RFC 3610) authenticated encryption for 128/192/256-bit keys
• Adds AesCcmCipher struct with CBC-MAC + CTR mode per RFC 3610
• Supports CCM-specific setAAD with plaintextLength option (required by Node.js API)
• Buffers data in update() and processes in final() since CCM requires knowing plaintext length upfront for CBC-MAC
• Validates nonce length (7-13 bytes), tag length (4-16 even), and message size limits

This is the last extraction from #32745 -- sign/verify (#33083), GCM (#33079), and ChaCha20-Poly1305 (#33084) are already landed.

Test plan

• ./x test-compat parallel/test-crypto-authenticated.js passes
• ./x test-node crypto_cipher passes (existing GCM + cipher tests)
• cargo clippy -p deno_node_crypto clean
• ./tools/format.js clean
• ./tools/lint.js --js clean

🤖 Generated with Claude Code

[kajukitli]

security review pass:

• i don't see any new non-constant-time auth tag comparisons in the rust side. the tag checks that are in scope are using subtle::ConstantTimeEq (ct_eq) for gcm/chacha20-poly1305, so nothing jumped out there.

• i did find a blocking correctness/security issue though: the PR wires a lot of AES-CCM behavior into the js polyfill, but the rust backend ops don't appear to implement CCM at all.
• ext/node_crypto/lib.rs still exposes op_node_cipheriv_set_aad / op_node_decipheriv_set_aad with only (rid, aad) — the new js code passes a plaintextLength, but it never reaches rust.
• ext/node_crypto/cipher.rs doesn't appear to add any aes-*-ccm variants in Cipher / Decipher, constructor matching, or final/auth logic.
• so this currently looks like the js layer claims CCM semantics, but the crypto backend can't actually enforce/process them.

for an AEAD mode that's a problem, because plaintextLength is part of the CCM contract and the backend needs to own the MAC/encrypt/decrypt behavior. otherwise best case this is just broken, worst case the API surface suggests authenticated encryption support that isn't actually implemented correctly.

so: constant-time-wise this looks fine, but i don't think the PR is ready yet until CCM is implemented end-to-end in the backend and the js setAAD(..., { plaintextLength }) path is actually plumbed through.

[bartlomieju]

Thanks for the security review! The constant-time check is good to hear.

On the CCM concerns -- I think you may have been looking at main rather than the PR branch. Everything is implemented end-to-end:

• plaintextLength is plumbed through to Rust: Both op_node_cipheriv_set_aad and op_node_decipheriv_set_aad take plaintext_length: i32 as a third parameter (lib.rs:537, lib.rs:629) and forward it via context.set_aad(aad, pt_len).

• CCM variants exist in cipher.rs: Aes128Ccm, Aes192Ccm, Aes256Ccm are in both Cipher and Decipher enums, with constructor matching for "aes-{128,192,256}-ccm", nonce/tag validation, and a full AesCcmCipher struct implementing RFC 3610 (CBC-MAC + CTR mode) with encrypt/decrypt/auth-tag logic.

[miracatbot]

Problem: This accepts multiple update() calls in CCM mode by buffering all chunks and processing them in final(), but Node documents/tests CCM as single-shot (update() must be called exactly once).

Why here: The CCM-specific update() path just accumulates into _ccmDataLength / push_data() with no guard against a second call.

Impact: That creates a Node-compat divergence in observable behavior for callers that accidentally stream/chunk CCM input. Node rejects that usage; Deno would silently accept it, so compat tests may still miss a real behavioral mismatch.

Ask: Please add a one-shot guard for CCM update() (cipher + decipher), or add a targeted Node-compat test if the divergence is intentional.

[bartlomieju]

Good catch. Added a one-shot guard in f528765 -- both Cipher and Decipher now throw "message cannot be fragmented across multiple calls to update" on a second update() call in CCM mode, matching Node's behavior.

[miracatbot]

Overall, the AES-CCM implementation looks coherent and the Node docs/tests alignment is mostly good, but I found one Node-compat behavior gap around CCM chunking.

Recommendation: comment
Risk: moderate

Prioritized findings:

1. CCM currently appears to allow multiple update() calls by buffering all chunks until final(), while Node documents/tests CCM as single-shot (update() exactly once). I left an inline comment on that path because it changes observable compatibility behavior for callers that stream/chunk input.

I didn’t spot an obvious logic bug in the core AES-CCM flow beyond that compatibility concern.

[miracatbot]

Re-reviewed the updated AES-CCM PR.

The Node-compat gap I called out earlier is addressed now: CCM update() is guarded as single-shot on both cipher and decipher, which matches the Node CCM contract much better.

I don’t see a new high-confidence issue in the updated revision.

Recommendation: approve
Risk: moderate

[miracatbot]

One compatibility concern I’d flag: this replaces the old NodeError-based OpenSSL-style errors with a local class CipherError extends Error in internal/crypto/cipher.ts.

That means errors like:

• ERR_OSSL_EVP_WRONG_FINAL_BLOCK_LENGTH
• ERR_OSSL_EVP_BAD_DECRYPT
• ERR_OSSL_TAG_NOT_SET

no longer have the normal Node error abstraction/prototype behavior, and instead become plain Error instances with ad-hoc .code / .reason properties.

The crypto logic itself looks reasonable to me on this pass, but I think the JS-visible error shape change is worth calling out because callers sometimes do inspect these as Node-style errors, not just by message text.