Gap
Payment Encrypt Data with DUKPT TDES data key produces different output from AWS Payment Cryptography for the same BDK/KSN/plaintext.
|
Output |
| CyberChef |
92A5157E4607D1B0 |
| APC |
124F7A32F3F84187 |
Root cause
CyberChef follows ANSI X9.24-1: the "Data" key variant XORs bytes 5 and 13 of the TDES key with 0xFF. APC applies an undocumented internal variant for data encryption. DUKPT MAC operations are unaffected and align correctly (both use the MAC Request / REQUEST variant).
Status
CyberChef behavior is standard-correct per ANSI X9.24-1. This is an APC deviation, not a CyberChef bug. However, it means DUKPT TDES data encryption cannot be cross-validated against APC.
Work required
- Investigate whether APC's variant is documented anywhere (AWS support, re:Post, ANSI liaison)
- If the APC variant can be identified, consider adding it as an optional mode
- Update
PAYMENT_RECIPES.md APC comparison table notes if new information is found
- See AWS re:Post question filed 2026-05-20 for any AWS engineer responses
Gap
Payment Encrypt Datawith DUKPT TDES data key produces different output from AWS Payment Cryptography for the same BDK/KSN/plaintext.92A5157E4607D1B0124F7A32F3F84187Root cause
CyberChef follows ANSI X9.24-1: the "Data" key variant XORs bytes 5 and 13 of the TDES key with
0xFF. APC applies an undocumented internal variant for data encryption. DUKPT MAC operations are unaffected and align correctly (both use the MAC Request /REQUESTvariant).Status
CyberChef behavior is standard-correct per ANSI X9.24-1. This is an APC deviation, not a CyberChef bug. However, it means DUKPT TDES data encryption cannot be cross-validated against APC.
Work required
PAYMENT_RECIPES.mdAPC comparison table notes if new information is found