README:
- Added DUKPT AES key derivation to current coverage (ANSI X9.24-3, 12-byte KSN, AES-128)
- Expanded DUKPT TDES line to include standard/KSN details for clarity
- Removed AES DUKPT from Future extensions (it shipped)
PAYMENT_RECIPES:
- Replaced "deprecated" with "removed" for Translate Payment PIN Data (issue #4 was resolved)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
AGENTS.md:
- Added npm start (dev server), npm run build (prod), and NODE_OPTIONS heap-size tip from upstream Getting-started wiki
Card Validation Data Generate/Verify:
- Added Profile behaviour note to both descriptions: CVV2 forces service code 000, iCVV forces 999, the arg is ignored for those profiles
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- PIN Data Verify: add Output as JSON toggle (was always returning JSON with no way to get plain boolean; all other verify ops have this toggle)
- EMV Verify MAC: fix inlineHelp to say "session integrity key" (was "session key", inconsistent with arg name and description body)
- DUKPT Derive TDES Key: replace stale "AES DUKPT not implemented" note with pointer to DUKPT Derive AES Key operation
- EMV Generate MAC (PIN Change): replace "Emulation helper" / "This emulation" with "Test helper" / "This operation" throughout description, inlineHelp, and arg comment
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PVV Verify, IBM 3624 Verify PIN, and EMV Verify ARQC all previously took
the long preimage data as input and the short cryptogram/offset as an arg,
which broke natural recipe chaining from their Generate counterparts.
Swapped each: the short output (PVV, offset, ARQC) now flows in as input;
the preimage/PIN data moves to an arg. Also added an Output as JSON toggle
to EMV Verify ARQC for consistency with other verify operations.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Both HSM Parse Thales Command and HSM Parse Futurex Command parse
message framing and field structure only; they do not interpret,
validate, or execute command payloads. Added a prominent Scope note
to this.description and this.inlineHelp on both operations so users
see the limitation before relying on the output for semantic analysis.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The per-bit loop was setting the FULL counter value on every hit instead
of OR-ing in one bit at a time. For any counter with more than one set
bit the two calls to nonReversibleKeyGen received the same ksnReg and
produced wrong derived keys. The existing test vector used counter 0x08
(one set bit), which masked the bug.
Fix: accumulate bits with |= so ksnReg grows one bit per iteration:
ksnReg[7] |= (bit >> 16) & 0x1F
ksnReg[8] |= (bit >> 8) & 0xFF
ksnReg[9] |= bit & 0xFF
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- CalculatePaymentKCV: fix HMAC SHA-224 using SHA-512/224 (forge.md.sha512.sha224)
instead of standard SHA-224 (now uses "sha224" string, consistent with other HMAC methods)
- PaymentMac: collapse 3-clause DUKPT variant ternary to single expression; the
ISO 9797-1 fallback to "MAC Request" was already correct and is now explicit
- AGENTS.md: renumber steps 1-7 sequentially; add step 6 — review and update
this.description/inlineHelp/testDataSamples whenever changing a recipe
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two bugs in generateBrandPan:
1. For networks with multiple prefix rules, always picked the same rule
(Mastercard always 2-series, AmEx always 37, Discover always 6011)
2. Always used the start of the range as the prefix, so Mastercard
generated 51xxxxx or 2221xxxxxx every time instead of any value
in 51-55 or 2221-2720
Fix both: pick a random prefix rule and a random prefix within start..end.
Add a "Mastercard series" arg to PAN Generate so callers can explicitly
request 5-series (51-55), 2-series (2221-2720), or leave it random.
The curated sample path is unaffected.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Rename two ops to follow the domain-prefix-first convention:
"Parse TR-31 Key Block" -> "TR-31 Parse Key Block"
"Parse TR-34 Key Transport" -> "TR-34 Parse Key Transport"
Sort all 33 Payments category entries alphabetically in Categories.json.
With domain-prefix names the prefixes cluster related ops naturally, so
alphabetical order is also logical order.
Update PAYMENT_RECIPES.md UI Arrangement section to document alphabetical
ordering. Fix stale lowercase references in AWS_PAYMENT_CRYPTOGRAPHY_RECIPES.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
After the op-rename batch, the runtime threw 'f[e.module][e.name] is not
a constructor' for every renamed op because Payment.mjs and index.mjs are
gitignored generated files that were never regenerated after this.name
was updated.
Add a rule to AGENTS.md step 6 naming the three generated files, the
symptom of a stale registry, and the two-command fix.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace six static inputs that held hardcoded keys or PINs with the
appropriate __RANDOM_*__ placeholder so the populate button delivers a
fresh value each time rather than a fixed test vector:
- PIN Data Generate, IBM 3624 Generate PIN Offset, VISA PVV Generate
→ __RANDOM_PIN_4__
- DUKPT Derive TDES Key, AS2805 Generate KEK Validation
→ __RANDOM_TDES_16_HEX__
- DUKPT Derive AES Key → __RANDOM_AES_128_HEX__
Add a recipeConfig chain sample to two ops where the output of
Key Generate flows directly into the next op as input:
- Card Validation Data Generate: Key Generate → Card Validation Data Generate
- Payment Calculate KCV: Key Generate → Payment Calculate KCV
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
All 31 payment operation display names now lead with their domain prefix
(EMV, DUKPT, PIN Block, PAN, etc.) so they sort and scan by topic in the
UI list. 8 upstream CyberChef ops (AES Encrypt/Decrypt, Triple DES,
AES Key Wrap/Unwrap, HMAC, CMAC) removed from the Payments category.
Updated: op this.name fields, Categories.json, Payment.mjs tests,
PAYMENT_RECIPES.md, AWS_PAYMENT_CRYPTOGRAPHY_RECIPES.md, AGENTS.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
