[pranavjain97]

Reject hostile v1 envelopes before they reach SJCL.

• EdDSA recovery helpers (no bitgo passed): enforce the 100,000 iter cap and ccm-only mode.
• decryptV1WithFallback: reject any explicit mode other than ccm, in browser and Node.

No signature changes. BitGo only wrote CCM with iter 10,000, so real keycards are unaffected.

Ticket: WCN-3831

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[linear-code]

WCN-3831

[pranavjain97]

@claude review

[github-actions]

Claude finished @pranavjain97's task in 22s —— View job

---

Review of #10070

No blocking issues. The change does what the title says, and I found no other raw sjcl.decrypt call sites in modules/*/src. The only ones left are the guarded calls in decryptV1WithFallback and the new decryptLegacyV1.

What I checked

• assertCcmMode (sdk-api/src/encrypt.ts) runs before both the browser and node paths, so a non-ccm mode can't reach SJCL. Absent mode is still allowed, so legacy envelopes keep working. Non-JSON input and JSON that isn't an object (null, a string) fall through to the existing decoder errors without crashing.
• decryptLegacyV1 (eddsaMPCv2.ts) applies the same iter cap (100,000) and mode check, and all three no-bitgo call sites now use it: isEddsaMpcV1SigningMaterial, getEddsaMpcV2RecoveryKeySharesFromReducedKey and getEddsaSigningMaterial.

Minor suggestions (non-blocking)

1. Duplicated cap. LEGACY_V1_MAX_ITER is a copy of sdk-api's V1_MAX_ITER, and the two can drift apart. If sdk-core can import from sdk-api without a dependency cycle, export and reuse the constant. Otherwise the comment is a fine stopgap.
2. Timing assertion. assert.ok(Date.now() - start < 200, ...) in the sdk-core test could be flaky on a slow CI runner. The /iter out of range/ rejection already shows the cap fired before SJCL ran, so I'd drop the timing check or loosen it a lot.
3. Error message mismatch. decryptLegacyV1 says iter out of range, expected an integer between 1 and N, while sdk-api's isIterCapViolation matches iter: expected integer|iter out of range. They agree today, but the messages are written separately, so a later wording change could break the match.
4. Test gap. There's no test for a non-integer iter (e.g. "10000" as a string or 1.5) in the sdk-core path. The code handles it, so a one-line case would pin it down.

I haven't run the tests here.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[github-actions]

⚠️ Unit tests are failing on Node 26.x (Current release line, non-blocking). This is not an LTS version yet, so it does not block merge, but it signals an incompatibility to fix before Node 26.x becomes LTS.

View run