The shift to quantum-resistant cryptography in the payment industry is urgent. With China's 2025 cryptographic standards requiring 128-bit, 256-bit, and 512-bit security levels, your compliance team must evaluate lattice-based key encapsulation mechanisms (KEMs) now. This checklist guides you through assessing your payment infrastructure's readiness for post-quantum cryptography, focusing on NTRU-based KEMs that balance security with practical implementation.
Checklist Overview
You'll validate your cryptographic inventory, assess quantum vulnerabilities in your cardholder data environment, and set criteria for evaluating next-generation KEMs. The focus is on lattice-based mechanisms that meet emerging security levels while fitting within your existing infrastructure.
Prerequisites
Before using this checklist, ensure you have:
- A complete inventory of cryptographic operations involving cardholder data (per PCI DSS Requirement 3.5.1)
- Documentation of your key management hierarchy and encryption points
- Performance baselines for key exchange operations in your production environment
- Access to your organization's cryptographic standards approval process
- Authority to engage with hardware security module (HSM) vendors about firmware roadmaps
Cryptographic Readiness Checklist
1. Inventory Current Key Exchange Mechanisms
Document every system using RSA or elliptic curve cryptography for key agreement in your cardholder data environment. Map these to specific PCI DSS requirements they satisfy.
Good looks like: A spreadsheet listing each system, the algorithm (e.g., RSA-2048, ECDH P-256), the PCI DSS requirement it addresses (e.g., 3.6.1 for key distribution), and the business process it supports. You know which systems handle ephemeral versus long-term keys.
2. Calculate Quantum Vulnerability Timeline
Estimate how long encrypted data must remain confidential for each cryptographic operation. Compare this to your organization's quantum threat horizon.
Good looks like: Systems are classified into "harvest now, decrypt later" risk categories. P2PE session keys have short confidentiality windows; archived transaction logs with long-term keys are higher risk. You have a written justification for prioritization.
3. Establish Security Level Requirements
Define minimum security levels for different data classifications. China's framework specifies 128-bit, 256-bit, and 512-bit levels; determine which applies to your cardholder data protection needs.
Good looks like: A written policy stating "Primary Account Number (PAN) encryption requires 256-bit security equivalent; transaction metadata requires 128-bit minimum." This aligns with current PCI DSS requirements and anticipated post-quantum standards.
4. Evaluate Ring Structure Compatibility
Check if candidate KEMs support multiple ring structures. DTRU supports power-of-two cyclotomic rings, tricyclotomic rings, and large-Galois-group prime-degree prime-ideal number fields (LPPNF). Determine which structures your cryptographic libraries and HSMs can implement.
Good looks like: You've tested whether your current HSM firmware supports the necessary algebraic structures, or you have a vendor commitment for future support. You understand that LPPNF options mitigate potential cyclotomic ring vulnerabilities.
5. Measure Bandwidth Constraints
Quantify acceptable ciphertext and public key sizes for your payment channels. Mobile point-of-sale devices, EMV terminals, and API integrations have different tolerance for message expansion.
Good looks like: You know your current RSA-2048 public key is 256 bytes and your target KEM must fit within 512 bytes for backward compatibility with existing message formats. You've identified that DTRU achieves 49%-52% better compactness than NTRU-HRSS at equivalent security levels.
6. Benchmark Key Exchange Performance
Establish performance baselines for ephemeral key exchange in your production environment. Measure round-trip time under realistic transaction loads.
Good looks like: You have metrics showing current key exchange adds 15ms to transaction latency. You've calculated that a mechanism 3.84× to 15.69× faster than NTRU-HRSS would reduce this to under 5ms, improving authorization response times without infrastructure changes.
7. Assess Decoding Complexity Requirements
Determine if your low-power devices (payment terminals, mobile SDKs) can handle the computational requirements of error correction in lattice-based KEMs. Double E₈ encoding provides efficient error correction with lower complexity.
Good looks like: You've profiled CPU and memory usage on your lowest-specification payment terminal. You know that mechanisms requiring complex coefficient compression will exceed available resources, making simpler encoding schemes necessary.
8. Verify Decryption Failure Tolerance
Calculate acceptable decryption failure probability for your payment flows. A failed key exchange triggers transaction retry; too many failures degrade customer experience and create fraud detection noise.
Good looks like: You've set a maximum decryption failure rate of 2⁻⁶⁴ based on your transaction volume and retry logic. You require KEMs to provide detailed failure probability analysis under their chosen encoding mechanism.
9. Review Parameter Set Diversity
Confirm that candidate KEMs offer parameter sets across all required security levels without relying on sparse noise distributions, which can introduce side-channel vulnerabilities.
Good looks like: You've verified the KEM provides distinct parameter sets for 128-bit, 256-bit, and 512-bit security. The documentation explicitly states noise distributions avoid sparsity patterns that could leak information through timing or power analysis.
10. Plan Circuit and Code Reuse
Evaluate whether the KEM design allows reusing implementation components across key generation, encapsulation, and decapsulation operations. This reduces audit surface and simplifies certification.
Good looks like: Your implementation review shows that the same base arithmetic operations support all three KEM operations. You won't need separate code paths for different security levels, simplifying FIPS 140-3 module validation.
Common Mistakes
Waiting for NIST finalization. NIST's post-quantum standardization process informs but doesn't replace your obligation to meet jurisdiction-specific requirements. China's 2025 mandate operates on a different timeline.
Ignoring implementation platform constraints. A theoretically optimal KEM that requires AVX2 instructions won't work on your ARM-based payment terminals. Validate architecture support early.
Treating all encrypted data equally. Not every system needs 512-bit security immediately. Prioritize based on data sensitivity and confidentiality timeline, then phase migration.
Skipping decryption failure analysis. Lattice-based KEMs have non-zero failure probabilities. If you don't understand the failure modes, you can't design appropriate retry logic or fraud detection rules.
Next Steps
Schedule a technical review with your HSM vendor to discuss post-quantum roadmap alignment. Begin pilot testing with a non-production cardholder data environment to validate performance assumptions. Update your cryptographic standards document to include evaluation criteria for lattice-based KEMs.
Your quantum-resistant migration timeline should align with your next major infrastructure refresh, not wait for a compliance deadline. Organizations that start technical evaluation now will have working implementations when standards become mandatory.
