A Strategic Reading of the Challenge of Cryptographic Agility in the Payments Ecosystem
Trust in payment methods ultimately rests on cryptography. Every time a cardholder enters a PIN, a merchant transmits a card number (PAN), or two entities exchange keys, an algorithm is protecting the confidentiality, integrity, and non-repudiation of that transaction. This cryptographic framework is as invisible as it is critical: when it works, nobody notices it; when it fails, confidence in the entire system erodes. For that reason, any fundamental change in the cryptographic foundations of payments is not merely a technical matter, but a strategic decision that affects risk, investment, and business continuity.
Quantum computing introduces precisely one of those fundamental changes. It is worth framing it without alarmism. There is currently no quantum computer capable of breaking the cryptography that protects payments, and there will probably not be one in the short term. However, the direction of change is clear and is supported by major standardization bodies: the public-key algorithms that underpin much of today’s security—RSA and elliptic curve cryptography (ECC)—are, in principle, vulnerable to a sufficiently powerful quantum computer. The strategic question, therefore, is not whether migration will be necessary, but when to begin and what priorities should guide it.
The “Harvest Now, Decrypt Later” Dilemma
The risk vector that makes the quantum challenge a matter of the present rather than the future is known as “harvest now, decrypt later” (HNDL): an adversary captures encrypted traffic today with the intention of decrypting it later, once quantum capabilities become available. For the payments ecosystem, this model deserves a nuanced reading because it has two sides that should be carefully weighed.On the one hand, the industry's most emblematic data element—the PAN—has a limited useful lifespan. Payment cards expire, are reissued, and receive new numbers. A PAN harvested today and decrypted eight or ten years from now, when relevant quantum capabilities may exist, will probably belong to a card that has already expired and been replaced. In that sense, the attractiveness of harvesting PAN traffic for very long-term decryption is lower than for other types of long-lived data.
On the other hand, the payments ecosystem protects much more than PANs through cryptography. Long-lived keys—such as Base Derivation Keys (BDKs) in DUKPT schemes or master keys stored in HSMs—along with certificates, signatures, and authentication material, often remain valid far longer than a payment card. Compromising one of these keys is not equivalent to decrypting a single PAN, but potentially to exposing entire transaction flows over extended periods. HNDL exposure, therefore, is not limited to the lifespan of a card.
Both considerations are valid and should be evaluated as part of the risk analysis of each organization. The strategic conclusion is neither that HNDL is a negligible issue nor that it constitutes an immediate emergency, but rather that its relevance depends on the type of data and the lifespan of the cryptographic material each organization protects.
A Lesson We Already Know: The Migration from 3DES to AES
The payments ecosystem does not need to imagine what a major cryptographic migration looks like—it is already experiencing one.The Triple DES (3DES or TDEA) algorithm, for decades the de facto standard for block encryption in the financial sector, now provides only 112 bits of effective security—exactly the minimum considered acceptable by current standards—and carries structural weaknesses. NIST has already disallowed it for the encryption of new data. However, neither the PCI SSC nor the payment brands have established a formal retirement date for its use within the payments industry. 3DES remains acceptable, with no declared end-of-life horizon, precisely because replacing it requires changing not only keys, but also hardware, formats, and protocols throughout the transaction chain.
That migration—conceptually straightforward because AES is a mature and available replacement—has been underway for years and has repeatedly seen its timelines postponed. If moving the ecosystem from one symmetric algorithm to another is this slow, the post-quantum migration, which affects public-key cryptography as a whole, will be an effort of an entirely different magnitude. The 3DES case, discussed in detail later, is the clearest preview of the challenge ahead.
Post-quantum cryptography (PQC) therefore touches the very foundations of payment systems. Understanding its scope requires examining several interconnected dimensions: the new NIST standards that are already available, the transition timelines that have begun to take effect, the way PCI SSC standards address—and do not yet address—the issue, and, above all, the decisions organizations can make today to avoid falling behind in a migration that will take years.
Fundamentals: What Is Post-Quantum Cryptography?
Post-quantum cryptography encompasses algorithms designed to resist attacks from both classical and quantum computers. This is not “quantum cryptography” nor some exotic technology: these are algorithms that run on today’s conventional hardware, but whose security relies on mathematical problems believed to be resistant to efficient solution by quantum computers.Differential Impact: Not All Cryptography Is Equally Affected
The quantum threat is not uniform, and understanding this asymmetry is essential for prioritization. Shor’s algorithm can, in theory, solve the integer factorization and discrete logarithm problems on which RSA and ECC are based in polynomial time. This means that public-key cryptography is fundamentally broken in the presence of a sufficiently powerful quantum computer. By contrast, Grover’s algorithm only provides a quadratic speed-up against symmetric cryptography, effectively reducing key strength by half. In practical terms, AES-256 retains a substantial security margin, while AES-128 becomes weaker but does not collapse.
The strategic consequence is straightforward. The highest migration priority should be public-key cryptography—key exchanges, digital signatures, certificates, and public key infrastructure—because this is where the impact is catastrophic rather than gradual. For symmetric cryptography, the response is more measured: migrate to AES with robust key lengths.
Why Key Size Does Not Save RSA or ECC
A common misconception is that increasing key length is sufficient to resist the quantum threat. This is not true for public-key cryptography. Shor’s algorithm breaks factorization regardless of key size. A longer RSA key modestly increases quantum hardware requirements, but it does not change the outcome or the long-term timeline. Neither RSA-4096 nor larger elliptic curves constitute a viable long-term refuge. This is why the solution is not to strengthen existing algorithms, but to replace them with algorithms based on fundamentally different mathematical assumptions.
PQC Is Not the Same as Quantum Key Distribution
It is important to clear up a common confusion. Post-quantum cryptography (PQC) and Quantum Key Distribution (QKD) are different technologies. PQC consists of algorithms that run on classical infrastructure, are standardized, and can be deployed using existing hardware. QKD is based on physical properties of quantum mechanics and requires specialized infrastructure, typically dedicated optical fiber, and has limited applicability. For the overwhelming majority of payment use cases, the standardization and deployment path is PQC, not QKD.
The New NIST Standards (August 2024)
Following a nearly decade-long international standardization process, NIST published the first three final post-quantum cryptography standards in August 2024. These standards, approved by the U.S. Secretary of Commerce, entered into force on August 14, 2024, and specify key establishment and digital signature schemes designed to resist attacks from future quantum computers. Their status as final standards—rather than drafts—allows organizations to begin adopting them with confidence.
FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). A key encapsulation mechanism derived from the CRYSTALS-Kyber algorithm and based on lattice problems. Its function is secure key establishment and it is intended to replace RSA and ECDH-style key exchanges. It is the most relevant component for protecting sessions, such as TLS.
FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm). A digital signature scheme derived from CRYSTALS-Dilithium, also based on lattice mathematics. It is the default recommended signature algorithm for most applications, replacing ECDSA and RSA signatures.
FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). A signature scheme based exclusively on the security of hash functions and derived from SPHINCS+. Its strategic value lies in serving as a conservative backup: because it does not depend on lattice hardness assumptions, it provides an independent security foundation that may prove valuable if weaknesses are ever discovered in lattice-based schemes.
The function-to-algorithm mapping is straightforward and should be kept in mind during planning: ML-KEM for key exchange and key encapsulation; ML-DSA as the primary signature scheme; and SLH-DSA as a backup signature scheme. The selection of one does not replace the need for the others, because they address different cryptographic operations.
The Transition Clock: Deprecation Timelines
Having replacement algorithms is only half of the equation; the other half is the timeline for retiring vulnerable algorithms. And that timeline has already begun to take shape, with one central fact for any strategic planning effort: there are specific deprecation and prohibition dates for RSA and ECC.
NIST IR 8547: The Deprecation Roadmap
In November 2024, NIST published the initial public draft of NIST IR 8547, Transition to Post-Quantum Cryptography Standards, which serves as a roadmap for retiring vulnerable cryptography and migrating to PQC standards. According to this draft, algorithms that provide approximately 112 bits of security—RSA-2048 and ECC P-256 being the primary examples—are designated for deprecation by around 2030: they will no longer be suitable for new deployments, although existing systems may continue operating during the migration window. By around 2035, all public-key algorithms vulnerable to quantum attacks would be prohibited in NIST standards and FIPS guidance, regardless of key size.
Note on the status of the document: IR 8547 is still in the Initial Public Draft (IPD) stage. Its dates, although aligned with U.S. federal directives such as National Security Memorandum 10 (which sets 2035 as a target), may be adjusted in the final version. It is advisable to verify the status of the document before citing specific dates as definitive.
The strategic interpretation of these dates extends beyond their formal scope. Although IR 8547 directly applies only to U.S. federal agencies and their contractors, in practice it serves as a planning anchor for the rest of the ecosystem because the guidance of other organizations and jurisdictions tends to converge with NIST standards. For an organization operating long-lived systems—as is often the case in payments—a deprecation horizon of 2030 implies that the effective execution window for the migration program is only a few years.
SP 800-131A: The Living Guide to Algorithms and Key Lengths
The document NIST SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths, is the reference that translates these transitions into specific status designations for each algorithm. The current final version is Revision 2 (March 2019), which already includes a strategy and timetable for retiring TDEA. There is also a draft Revision 3 (October 2024) that is directly relevant to the subject of this paper. It proposes the retirement of weak modes and schemes, establishes timelines for the withdrawal of SHA-1 and 224-bit hash functions, and—most importantly—discusses the transition from 112-bit to 128-bit security strength and toward quantum-resistant algorithms for digital signatures and key establishment. In other words, this is the point at which NIST begins to formally integrate the PQC transition into its general algorithm guidance.
Impact in a PCI DSS v4.0.1 Environment
The PCI DSS v4.0.1 standard does not yet mention post-quantum cryptography. However, it contains the requirements that currently provide the framework for managing the transition, and one of them in particular constitutes the strongest anchor point for any quantum-readiness strategy.
Requirement 4: Encryption in Transit
Requirement 4—"Protect cardholder data with strong cryptography during transmission over open, public networks"—requires under control 4.2.1 that strong cryptography and secure protocols be implemented to safeguard the PAN, including ensuring that the protocol in use supports only secure versions or configurations and does not allow the use of insecure versions, algorithms, or key sizes, and that the encryption strength is appropriate for the methodology employed. Of particular relevance to the post-quantum agenda is control 4.2.1.1, which requires maintaining an inventory of the trusted keys and certificates used to protect PAN in transit. In practice, this inventory is a first step toward cryptographic agility: it makes it possible to know where each algorithm is deployed and to respond quickly when one of them needs to be replaced.
Requirement 3: Encryption and Key Management in Storage
Requirement 3 governs the protection of stored PAN (control 3.5.1, including hashing and encryption) and the management of the lifecycle of cryptographic keys (controls 3.6 and 3.7). This is where the protection of data at rest resides and, with it, a significant portion of the long-lived cryptographic material whose exposure to the HNDL model must be assessed.
Requirement 12.3.3: The Anchor of Cryptographic Agility
The central anchor point is Requirement 12.3.3, enforceable as of March 31, 2025. Its text explicitly names the concept of “cryptographic agility” and requires documenting and reviewing, at least every 12 months, the encryption suites and protocols in use, with three elements: an up-to-date inventory of all cryptographic suites and protocols in use, including their purpose and location; active monitoring of industry trends regarding the continued viability of those algorithms; and documentation of a plan for responding to anticipated changes in cryptographic vulnerabilities.
The guidance accompanying the requirement defines cryptographic agility as the ability to monitor and manage the encryption and verification technologies deployed within the organization, and directly references NIST SP 800-131A.
In other words, although PCI DSS does not explicitly mention PQC, Requirement 12.3.3 turns awareness, inventory management, and migration planning into an auditable control. At present, it is the only formal mechanism within the standard available for structuring post-quantum readiness.
There is also a revealing structural parallel. The logic of Requirement 12.3.3—inventorying, monitoring, and maintaining a documented response plan—almost precisely matches the framework codified by the U.S. federal government in National Security Memorandum 10 as the foundation for its own PQC migration: inventory cryptographic systems, prioritize migration of the most vulnerable ones, and operate according to a plan with defined milestones.
Both frameworks reflect the same principle: cryptographic governance must be continuous, assigned, and responsive. In practice, that is the organizational capability that cryptographic agility requires.
The Definition of “Strong Cryptography” and the Quantum Challenge
PCI DSS defines “strong cryptography” (Appendix G) as cryptography based on industry-tested and accepted algorithms, with key lengths that provide a minimum of 112 bits of effective strength and appropriate key-management practices, recommending 128 bits for new implementations. This definition, centered on effective strength, is precisely what quantum computing challenges: Shor’s algorithm renders the concept of “effective bits” meaningless for RSA and ECC, while Grover’s algorithm reduces the security margin of symmetric encryption.
The conceptual framework on which the notion of cryptographic strength in PCI is based is therefore directly challenged by the quantum threat.
The Current Gap: PCI Still Does Not Explicitly Mention PQC
It is important to state the current situation candidly. As of the date of this document, the PCI SSC has not published a standalone guide on post-quantum cryptography. Requirement 12.3.3 requires inventory and monitoring, but it does not specify concrete PQC algorithms, migration timelines, or testing requirements. Organizations are therefore left to interpret the mandate to “monitor threats to current algorithms” as an implicit preparation requirement for PQC. This gap is itself a strategic fact: the responsibility for translating cryptographic agility into a concrete PQC plan currently rests with each individual organization.
The Real State of Algorithms in Payments: The 3DES/TDEA Case
The 3DES/TDEA case deserves detailed analysis because it encapsulates, in a single example, all the tensions that will also define the post-quantum migration: an algorithm that is technically questioned, formally disallowed by NIST, yet still accepted in payments without a retirement date due to the enormous cost of replacing it throughout the entire transaction chain.
The Technical Weakness
When TDEA is used with three independent keys, it provides a nominal key length of 168 bits. However, due to meet-in-the-middle attacks, its effective security is reduced to only 112 bits: exactly the minimum threshold established by Appendix G of PCI DSS. In addition to this, it suffers from a structural weakness: its 64-bit block size makes it vulnerable to collision attacks when large volumes of data are encrypted with the same key. This vulnerability, known as Sweet32 (CVE-2016-2183), affects long-lived encrypted sessions—such as HTTPS/TLS, SSH, and IPsec connections—and was the trigger for subsequent restrictions on the use of TDEA.
Status in NIST: Disallowed
NIST has already closed the door on 3DES for new data. According to SP 800-131A, two-key TDEA encryption is disallowed, and as of December 31, 2023, three-key TDEA was also prohibited for data encryption, unless specifically permitted by other NIST guidance. Decryption remains authorized only for legacy use—for example, to recover historical data protected before the retirement date. Within the U.S. federal environment, therefore, 3DES is an algorithm on its way out.
The PCI Mechanism: An Inevitable Retirement, but Without a Date
This is where the most delicate and strategically revealing point emerges. PCI does not prohibit 3DES through a specific deadline; instead, it pushes it toward retirement through an indirect mechanism. The definition of “strong cryptography” was updated in PCI DSS v4.0 to refer to the effective strength of the algorithm/key combination (minimum 112 bits) rather than to specific algorithms. According to PCI SSC FAQ #1570 (August 2023), because three-key TDEA can still provide 112 bits of effective strength when implemented with appropriate key management and operating modes, it still qualifies today as “strong cryptography” under PCI DSS. However, that same definition makes its validity conditional upon the use of industry-tested and accepted algorithms. That is the critical point: the day that NIST and the industry fully disallow TDEA, it will automatically cease to qualify as strong cryptography for PCI SSC purposes. Its retirement will occur because of loss of acceptance, not because of a mandated date.
PCI PIN: Forced Migration to AES, with Suspended Deadlines
In the area of PIN protection, the PCI PIN standard pushes migration from TDEA to AES through specific technical mechanisms, while still maintaining TDEA as an approved algorithm alongside AES. The three components of this migration are:
▪️Adoption of the ISO Format 4 PIN Block, the only ISO format that supports AES, a necessary condition for encrypting PINs with AES.
▪️Migration from TDEA DUKPT to AES DUKPT (in accordance with ANSI X9.24-1), with the corresponding replacement of Base Derivation Keys (BDKs).
▪️Migration of key block formats from ANSI X9.143 (TR-31) to AES-based wrapping schemes under ANSI X9.102.
PCI PIN has also already deprecated weak TDEA implementations: since January 2023, the use of TDEA fixed keys for PIN encryption has been prohibited, both in point-of-interaction devices and in host-to-host communications.
However, the migration timeline has been suspended, and this is where the strategic lesson lies. In March 2021, PCI SSC announced the suspension of the ISO Format 4 PIN Block support dates that had been communicated in Version 3.0 of the PIN standard. The original dates—January 2023 for decryption and January 2025 for encryption using Format 4—were removed from the requirements, and the Council explicitly acknowledged that “migration to AES is a major effort across the ecosystem,” committing to communicate revised timelines at a later date. In other words, there was a concrete timetable for exiting TDEA in PIN encryption, and it was postponed indefinitely.
The Clash with FIPS 140-3
An additional factor further complicates the landscape. The FIPS 140 standards govern the validation of hardware cryptographic modules (HSMs), which PCI SSC itself requires for PIN processing. As of December 31, 2023, FIPS 140-3 evaluations can no longer include TDEA, and modules validated under the previous FIPS 140-2 standard are restricted to using TDEA only for decryption. This creates a very specific operational tension: an HSM certified under the most recent standard can no longer provide TDEA as an approved algorithm, even though payment standards may still permit it. The coexistence of “TDEA still accepted by PCI” and “TDEA no longer permissible under FIPS 140-3” illustrates the type of regulatory misalignment that organizations must anticipate.
The Underlying Lesson
The contrast is striking. Within payments, 3DES survives without a retirement horizon because its replacement, although technically straightforward, requires replacing keys, formats, protocols, and hardware throughout the transaction chain, with all the associated costs. By contrast, RSA and ECC already have deprecation (2030) and prohibition (2035) timelines in NIST guidance. If a conceptually simple migration such as TDEA → AES takes more than a decade and sees its schedules suspended, then the post-quantum migration—which replaces the entire public-key cryptographic infrastructure with new algorithm families featuring larger keys and signatures—will be a considerably more complex challenge. Starting late is not a neutral option: it means accepting an increasing level of risk.
The Real State of Algorithms in Payments: The 3DES/TDEA Case
A strategic aspect that is often overlooked is that PCI does not itself define which algorithms are acceptable: it delegates that criterion to external guidance that changes over time. Requirement 4 itself refers, for strong cryptography and secure protocols, to NIST SP 800-52 (TLS configuration) and NIST SP 800-57 (recommendations on algorithms and key lengths). Requirement 12.3.3, in turn, refers directly to SP 800-131A. This means that the set of “accepted algorithms” is not static: it is redefined as NIST updates its guidance.
The implication for management is clear. Monitoring these guides is not a one-time documentation exercise, but rather an ongoing organizational capability that Requirement 12.3.3 itself makes an auditable obligation. When NIST deprecated TDEA, that decision should have been reflected in the trend-monitoring register of any diligent organization. Likewise, the finalization of FIPS 203/204/205 in August 2024 is exactly the type of industry development that the monitoring process required by Requirement 12.3.3 should have captured. An organization whose monitoring register does not reflect that awareness has, today, an audit gap.
Migration Roadmap for the Payments Ecosystem
From the above, a sequence of actions emerges that organizations can undertake now, without waiting for the PCI SSC to publish specific PQC guidance. The approach is one of risk management and prioritization, not the immediate deployment of algorithms that are still immature within the ecosystem.
▪️ Cryptographic discovery and inventory. This is the first step and is already mandatory: Requirements 4.2.1.1 and 12.3.3 require an inventory of keys, certificates, suites, and protocols, including their purpose and location. Without this map, no subsequent migration can be planned.
▪️ Prioritization by risk and data lifespan. Not everything should migrate at the same time. Priority should be given to asymmetric cryptography (RSA/ECC) and long-lived material whose exposure to the HNDL model would be significant, distinguishing it from short-lived data such as the PAN of a card that is close to expiration.
▪️ Hybrid deployment as a transition phase. The emerging pattern is hybrid TLS, which combines a classical algorithm with a post-quantum one (for example, ECDH together with ML-KEM), preserving backward compatibility throughout the transition. Hybrid terminology was standardized in RFC 9794 (June 2025), and IETF drafts exist for hybrid ECDH+ML-KEM key exchange in TLS 1.3.
▪️ Anticipating the hardware gap. A specific limiting factor is that payment ecosystem HSMs with certified PQC support are only beginning to emerge, and the expected window for FIPS 140-3 validations that include finalized PQC algorithms is around 2027. A reasonable strategy is a dual-track approach: test PQC algorithms in non-production environments now, while planning production deployment based on the availability of certified hardware.
▪️ Governance and cryptographic agility as the organizing principle. Beyond any specific algorithm, the objective is to design systems capable of replacing cryptographic primitives without redesigning the infrastructure. That capability—cryptographic agility—is the true strategic asset, because PQC will not be the last transition.
As practical guidance resources, NIST’s National Cybersecurity Center of Excellence (NCCoE) is developing the PQC migration project (SP 1800-38) and specific material on cryptographic agility considerations for migration to post-quantum algorithms, complementing the planning approach described above.
Conclusions and Recommendations for the Industry
The regulatory chain framing this transition is already in place, although not yet complete: PCI DSS Requirement 12.3.3 requires cryptographic agility and refers to SP 800-131A; this guidance defines which algorithms are being retired and when; NIST IR 8547 establishes the RSA/ECC deprecation schedule toward 2030 and 2035; and the FIPS 203/204/205 standards provide the replacement algorithms. The missing link is a PQC-specific guidance document from the PCI SSC itself, which is expected to be incorporated into future versions of the standard.
The pattern is also global and convergent. The European DORA regulation, applicable since January 2025, does not explicitly require PQC but does require the monitoring of cryptographic threats, including those arising from quantum advances. The Monetary Authority of Singapore (MAS) has required inventories and migration strategies without specifying algorithms or timelines. The same model—inventory and monitoring, without yet explicitly naming PQC—is being repeated across different jurisdictions, suggesting that the requirement for a formal migration plan will become widespread over the coming years.
The central strategic recommendation is therefore simple to state and demanding to execute: start now. Begin with the cryptographic inventory—which is already a mandatory requirement—prioritize based on actual risk, and build the cryptographic agility capability that will make it possible to address this migration and those that follow. The 3DES case demonstrates that, in payments, even “simple” migrations take years; the post-quantum migration will be larger. And although the exposure window of a PAN is limited by card expiration, long-lived cryptographic material and the inherent slowness of the ecosystem mean that the “harvest now, decrypt later” clock is already ticking. The transition will require years of careful preparation; waiting until a practical quantum computer exists before taking action is not a strategy, but rather a decision to forgo managing the transition altogether.
References
NIST Standards and Publications
▪️FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (agosto 2024).
▪️FIPS 204 — Module-Lattice-Based Digital Signature Standard (agosto 2024).
▪️FIPS 205 — Stateless Hash-Based Digital Signature Standard (agosto 2024).
▪️NIST IR 8547 — Transition to Post-Quantum Cryptography Standards (borrador público inicial, noviembre 2024).
▪️NIST SP 800-131A Rev. 2 — Transitioning the Use of Cryptographic Algorithms and Key Lengths (marzo 2019); Rev. 3 (borrador, octubre 2024).
▪️NIST SP 800-52 — Guidelines for the Selection, Configuration, and Use of TLS Implementations.
▪️NIST SP 800-57 Part 1 — Recommendation for Key Management: General.
▪️NIST SP 800-67 Rev. 2 — Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher.
▪️NCCoE (NIST) SP 1800-38 — Migration to Post-Quantum Cryptography; y consideraciones de agilidad criptográfica para la migración a PQC.
▪️NIST — What Is Post-Quantum Cryptography? (recurso divulgativo).
Estándares y documentos del PCI SSC
▪️PCI DSS v4.0.1 — Requirements and Testing Procedures (junio 2024): Requisitos 3, 4 (4.2.1, 4.2.1.1), 12.3.3 y Apéndice G.
▪️PCI PIN Security Requirements and Testing Procedures v3.1.
▪️PCI SSC FAQ #1570 — Does TDEA meet the requirements of "strong cryptography" as defined in PCI DSS? (agosto 2023).
▪️PCI SSC Security Standards Bulletin — Suspension of ISO Format 4 PIN Block Support Dates (11 de marzo de 2021).
Documentos de industria
▪️Mastercard — White paper sobre migración a criptografía post-cuántica (2025).
▪️FS-ISAC — The Impact of Quantum Computing on the Payment Card Industry.
▪️IETF RFC 9794 — Terminology for Post-Quantum Traditional Hybrid Schemes (junio 2025).
▪️Shor, P. W. (1997). Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM Journal on Computing, 26(5), 1484–1509. DOI: 10.1137/S0097539795293172. Preprint disponible en arXiv: quant-ph/9508027.
▪️Grover, L. K. (1996), A fast quantum mechanical algorithm for database search, Proceedings of the 28th Annual ACM Symposium on the Theory of Computing (STOC), pp. 212–219.
