exlim/cyberchef
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Trim upstream PR draft

Browse Source
This commit is contained in:
J8k3 2026-04-25 18:30:51 -04:00
parent e2dfbc475e
commit 535a466178
1 changed files with 31 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
UPSTREAM_PR_DRAFT.md
View File

@ -13,101 +13,61 @@ Suggested PR body:
```md ```md
## Summary ## Summary
This PR adds a payment-focused extension surface to CyberChef aimed at software emulation, testing, interoperability work, and education. This PR adds a payment-focused extension surface to CyberChef for software emulation, testing, interoperability work, and education.
It does **not** present CyberChef as a certified HSM or production key-custody platform. The added payment operations and recipe docs are explicitly framed as software-only tooling with inline validation, assumption, and security guardrails. It is intentionally documented as software-only tooling rather than a certified HSM or production key-custody surface.
## What This Adds ## What This Adds
### Payment-facing operations - A new `Payments` category with payment-facing operations for:
- data encryption / decryption / re-encryption
- Payment data wrappers: - MAC generation / verification
- `Encrypt Payment Data` - EMV ARQC / ARPC / MAC helpers
- `Decrypt Payment Data` - clear PIN block build / parse / translate
- `Re-Encrypt Payment Data` - card validation data
- MAC coverage: - DUKPT / ECDH / KCV helpers
- `Generate Payment MAC` - test PAN generation / parsing
- `Verify Payment MAC` - TR-31 / TR-34 inspection helpers
- `Generate EMV MAC` - Payment recipe and chaining docs:
- `Verify EMV MAC`
- `Generate EMV MAC For PIN Change`
- EMV cryptogram helpers:
- `Generate EMV ARQC`
- `Verify EMV ARQC`
- `Generate EMV ARPC`
- PIN workflows:
- `Build PIN Block`
- `Parse PIN Block`
- `Translate PIN Block`
- `Generate Payment PIN Data`
- `Translate Payment PIN Data`
- `Verify Payment PIN Data`
- `Generate IBM 3624 PIN Offset`
- `Verify IBM 3624 PIN`
- `Generate VISA PVV`
- `Verify VISA PVV`
- Card-validation helpers:
- `Generate Card Validation Data`
- `Verify Card Validation Data`
- Key / key-material helpers:
- `Calculate Payment KCV`
- `Derive DUKPT Key`
- `Derive ECDH Key Material`
- `Generate AS2805 KEK Validation`
- Test-data and parsing helpers:
- `Generate Test PAN`
- `Parse PAN`
- `Parse TR-31 key block`
- `Parse TR-34 B9 envelope`
### Recipe and documentation work
- Added payment recipe starters and chaining guidance:
- `PAYMENT_RECIPES.md` - `PAYMENT_RECIPES.md`
- `AWS_PAYMENT_CRYPTOGRAPHY_RECIPES.md` - `AWS_PAYMENT_CRYPTOGRAPHY_RECIPES.md`
- `PAYMENT_SIM_RECIPES.md` - `PAYMENT_SIM_RECIPES.md`
- Added a validation / release audit: - A validation audit with explicit guardrails:
- `PAYMENT_VALIDATION_AUDIT.md` - `PAYMENT_VALIDATION_AUDIT.md`
- UI improvements for payment operations:
### UI / usability work - inline recipe-card guidance
- visible validation / scope / security wording
- Added inline recipe-card guidance for payment operations. - built-in test-data population helpers
- Added visible validation/scope/security wording on higher-risk operations.
- Added `Populate test data` support and payment test-input generation helpers.
- Reorganized the `Payments` category so payment-facing wrappers appear before lower-level primitives.
## Validation / Guardrails ## Validation / Guardrails
This PR intentionally distinguishes between: The payment operations are explicitly classified in `PAYMENT_VALIDATION_AUDIT.md` as:
- verified against public standards / vectors
- vendor-aligned
- externally cross-checked
- emulation helpers
- behavior verified against public standards or public vendor docs That status is also surfaced inline on higher-risk operations so users can see scope and limitations in the recipe UI.
- behavior aligned to AWS Payment Cryptography semantics
- behavior externally cross-checked where the governing scheme spec is not public here
- explicit emulation / inspection helpers
That classification is documented in `PAYMENT_VALIDATION_AUDIT.md` and summarized inline in the payment operation descriptions.
## Scope Notes ## Scope Notes
- This is intended for software emulation, QA, interoperability, and educational use. - Intended for software emulation, QA, interoperability, and educational use.
- It is **not** a certified HSM implementation. - Not a certified HSM implementation.
- It is **not** presented as a PCI-scoped production key-custody or transaction-security surface. - Not presented as a PCI-scoped production key-custody surface.
- Some payment domains are necessarily profile-specific or emulated, and those limitations are surfaced directly in the UI/docs.
## Verification ## Verification
- Docker build completed successfully from this branch. - Docker build completed successfully from this branch.
- Payment-focused vectors and operation tests were added/expanded in `tests/operations/tests/Payment.mjs`. - Payment-focused vectors and operation tests were added/expanded in `tests/operations/tests/Payment.mjs`.
- Common recipe chains are documented rather than left implicit. - Common recipe chains are documented explicitly in the payment docs.
## Review Notes ## If This Is Too Broad
This is a broad feature addition. If maintainers prefer smaller upstream review units, I can split this into follow-up PRs along these lines: If maintainers would prefer smaller review units, I can split this into follow-up PRs by:
1. payment primitives and category plumbing
1. Payment core primitives and category plumbing
2. MAC / KCV / DUKPT / ECDH / PIN block operations 2. MAC / KCV / DUKPT / ECDH / PIN block operations
3. EMV / card-validation / issuer-verification helpers 3. EMV / card-validation / issuer-verification helpers
4. Test-data generators, docs, and validation guardrails 4. test-data generators, docs, and validation guardrails
``` ```
Submission notes: Submission notes: