I built a set of payment cryptography extensions for CyberChef using Codex. The fork is at github.com/J8k3/CyberChef and there's a hosted instance running at cyberchef.jacobmarks.com.

CyberChef is a browser-based data transformation and analysis tool from GCHQ. It's useful for a wide range of encoding, crypto, and parsing tasks, and the recipe model, where you chain operations together and run them in sequence, makes it well-suited for the kind of multi-step payment cryptography work that's otherwise done across several disconnected tools or scripts. In particular CyberChef is entierly browser based and you can freely download and run it locally making is a great tool for testing and prototyping without shipping your data off to a remote host.

The extensions add a Payments category, that follows the AWS Payment Cryptography API structure, to the operations panel. That includes encrypt, decrypt, and re-encrypt for AES and TDES profiles; MAC generation and verification across HMAC, AES-CMAC, TDES-CMAC, ISO 9797-1, AS2805, and DUKPT variants; EMV ARQC and ARPC; issuer-script MAC and PIN-change MAC; card validation data for CVV, CVV2, and iCVV; PIN block build, parse, and translate for ISO 9564 formats 0, 1, and 3; IBM 3624 PIN offset and VISA PVV; DUKPT and ECDH key derivation; KCV calculation; AS2805 KEK validation; and TR-31 and TR-34 B9 parsing.

This is software emulation, not a replacement for an HSM or HSM backed service. The intent is regression testing, interoperability work, and lab-level inspection of payment crypto flows without needing a cloud account or a hardware device in the loop. Each operation documents what it covers, what assumptions it makes, and where the implementation is an emulation helper rather than a full standards implementation.

The PAYMENT_RECIPES.md file in the repo has recipe starters for the most common chaining patterns: DUKPT MAC, ECDH key wrap, clear PIN block to encrypted PIN data, EMV ARQC and ARPC, and brand test card setup among others. The PAYMENT_VALIDATION_AUDIT.md documents how each operation was validated and what standard or vendor specification it maps to.

Codex handled most of the implementation. My role was directing it, reviewing the output against the relevant specifications, and pushing on edge cases and the DUKPT and EMV flows that required more precision. The approach was useful but it was not hands-off. Getting the payment-specific behavior right, especially for ISO 9797-1 padding and the DUKPT derivation chain, required iteration.

The fork is open. If you work in payments and find a gap in coverage, an operation that behaves differently against your hardware or spec, or a recipe pattern worth adding, open an issue or submit a PR.