Open Problems in Cryptographic Security

Scope: an evidence-led scenario, not a prediction

This article treats the future of cryptographic security as a scenario analysis. It does not predict when a cryptographically relevant quantum computer (CRQC) will exist, whether every proposed capability will be achieved, or which future algorithmic profile will dominate. The cited evidence explicitly says that predictions vary on when, or if, such a device will exist, while also stating that organizations need to anticipate and prepare for the possibility. That combination matters: uncertainty about timing is not the same as evidence that preparation can be deferred.12

The analysis separates three layers. First are established technical and institutional facts in the cited documents, such as the mathematical basis of many current asymmetric algorithms, the publication of principal post-quantum standards in 2024, and the documented costs of hybrid deployment. Second are reasonable enterprise inferences, such as the need to prioritize systems according to data lifetime and replacement difficulty. Third are open questions, including the eventual capability of quantum computers, the performance and security of future algorithms, and how rapidly AI attack methods and mitigations will change. Keeping these layers separate prevents a risk program from turning uncertainty into either complacency or unsupported certainty.213

The current technical baseline

Many asymmetric algorithms used for key establishment and digital signatures rely on integer factorization or discrete logarithms over finite fields or elliptic curves. The IETF evidence states that Shor’s algorithm could attack these mathematical problems on a sufficiently large general-purpose quantum computer. NIST’s explanatory material describes the same baseline in more accessible terms: conventional systems can make multiplication easy while making reversal computationally difficult, whereas a sufficiently capable quantum computer could change that balance dramatically.12

The immediate confidentiality concern is not confined to future traffic. Data encrypted today with an algorithm vulnerable to a future CRQC can be collected and stored for later decryption. The cited RFC also identifies a long-term authenticity concern: signing algorithms in products expected to remain in use for many years, and that cannot be updated or replaced, may be at risk if a CRQC appears during the product’s operational lifetime. Consequently, an enterprise assessment should examine both confidentiality lifetimes and the expected lifetime of signed products, certificates, firmware, records, and other trust artifacts.1

The technical baseline is changing rather than empty. NIST released three principal post-quantum standards as FIPS in August 2024: ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for digital signatures. NIST says these are expected to provide the foundation for most deployments and can and should be put into use now. However, NIST is continuing to evaluate additional algorithms; Falcon and HQC were selected for ongoing standardization, and a longer-term effort solicited additional digital signature schemes for backup or special use cases. This means “standards exist” and “the standardization landscape is finished” are different statements.5

The principal open problems

The first open problem is migration discovery. Enterprises often need to find cryptographic dependencies across applications, devices, protocols, certificates, libraries, key-management systems, suppliers, and embedded products before they can select a replacement. The cited CSF evidence supports a structured approach: understand mission, stakeholders, dependencies, legal and contractual requirements, critical services, and risk priorities; then create current and target profiles, analyze gaps, and build an action plan. Applied to cryptography, this implies that a useful inventory must connect algorithms to business services, data lifetime, system ownership, replacement constraints, and external dependencies rather than merely listing software packages.3

The second open problem is protocol and interoperability design. ETSI describes cases in which hybrid TLS key exchange can protect long-lived sensitive data, while authentication may be handled through traditional or post-quantum certificate chains depending on the security requirement and design. For S/MIME, algorithm negotiation may not be available, so interoperability can require both traditional and hybrid encryption certificates for a recipient. These examples show why a migration cannot be reduced to changing one algorithm identifier: negotiation, certificate issuance, downgrade protection, recipient capabilities, and protocol security assumptions all matter.4

The third open problem is implementation correctness. Post-quantum algorithms may be more complicated to implement than traditional algorithms. The cited ETSI report gives examples including floating-point arithmetic in Falcon and careful state management for stateful hash-based signatures such as XMSS and LMS. Hybrid implementations must support both algorithm families and correctly combine secrets or perform additional verification logic. Errors in either component or in the combining logic can create vulnerabilities that weaken the intended scheme. More than two components can further increase testing and validation complexity through additional combinations and code paths.4

The fourth open problem is operational performance. ETSI reports that hybrid computational overhead varies with the algorithm, platform, and implementation. Its example says a hybrid exchange combining ECDH P-256 and ML-KEM-512 can require three times the computational resources of ML-KEM-512 alone under the cited comparison. Network latency may instead be dominated by handshake bandwidth, especially on links with long round-trip times or packet loss. Therefore, performance cannot be inferred from algorithm names alone; it must be measured in the actual deployment, including constrained devices, high-latency networks, and failure or retry behavior.4

The fifth open problem is assurance under changing evidence. The NIST process was open and involved international cryptographers, multiple evaluation rounds, and attention to devices with limited processor power. Yet the project continues to assess additional candidates. That is a healthy research posture, but it creates an enterprise requirement for controlled change: organizations need to know which decisions are reversible, which products can accept new algorithms, how supplier updates are validated, and what evidence would justify changing a selected profile. The open question is not only which algorithms resist quantum attacks; it is how to maintain trustworthy security while knowledge, standards, and implementations evolve.25

The sixth open problem is the interaction between cryptography, software assurance, and AI. NIST describes AI security and resilience as active research areas in which challenges and potential solutions are changing rapidly. Existing frameworks and guidance do not comprehensively address evasion, model extraction, membership inference, availability, all machine-learning attacks, or the full complexity of AI attack surfaces and abuses. Many risks overlap with ordinary software and data risks involving confidentiality, integrity, and availability, but AI systems also require specific governance, mapping, measurement, and management. This does not establish that AI will break cryptography; it establishes that cryptographic programs increasingly operate within systems whose security assumptions and attack surfaces are changing.6

Dependencies and alternative outcomes

A useful scenario analysis identifies dependencies instead of assigning a single forecast. The quantum scenario depends on whether researchers overcome the major technical hurdles described by NIST, whether a sufficiently powerful device is built, and whether its capability is relevant to the algorithms and implementations an organization uses. The migration scenario depends on supplier support, standards adoption, certificate and protocol interoperability, available implementation expertise, hardware constraints, and the ability to test without disrupting critical services. The AI-security scenario depends on how quickly attack techniques, defensive methods, and governance practices develop.254

Several outcomes remain credible within the evidence. One outcome is an orderly migration in which standardized post-quantum algorithms become widely deployed, with hybrid operation used where organizations need an additional transition mechanism. A second is a prolonged mixed environment: traditional systems remain in service because of embedded devices, long-lived products, or interoperability constraints, while new systems adopt post-quantum algorithms. A third is uneven assurance, where algorithms are selected correctly but protocol integration, state handling, certificate operations, or implementation testing creates weaknesses. A fourth is that AI-related security risks absorb governance attention and compete with migration resources. These are scenario possibilities, not predictions; their value lies in exposing decisions that remain robust across outcomes.146

Decision signals should therefore be concrete and observable. Examples include a supplier announcing that a product cannot be updated or replaced during its expected lifetime; discovery of sensitive data whose confidentiality period exceeds the migration timeline; a protocol or certificate profile gaining the interoperability needed by a critical service; measured performance degradation in a constrained environment; a material change in standards status; or new AI-system deployments that alter the organization’s attack surface. The CSF’s emphasis on governance, risk strategy, dependencies, monitoring, assessment, improvement, and supply-chain risk provides a suitable management frame for recording these signals and assigning owners.3

What enterprises can do now

The first action is to establish governance before selecting a technical pattern. Define ownership for cryptographic risk, agree risk tolerance and priorities, document legal, regulatory, contractual, and stakeholder requirements, and identify services on which external stakeholders depend. Use a current profile and a target profile to document assumptions, identify gaps, and assign an action plan. This approach is consistent with the CSF evidence and avoids treating migration as an isolated engineering project.3

1. Create a cryptographic dependency inventory covering algorithms, protocols, certificates, keys, libraries, hardware modules, applications, devices, suppliers, and embedded products. Record service owner, data type, confidentiality lifetime, signing or trust lifetime, update path, replacement difficulty, and external dependencies.
2. Prioritize systems handling long-lived sensitive information and products that cannot be updated or replaced. Include stored ciphertext, archival records, firmware, software-signing infrastructure, and certificate ecosystems where the operational lifetime makes future compromise consequential.
3. Define a target profile that identifies where the NIST principal standards are appropriate, where hybrid schemes may be needed, and where a documented exception is required. Treat the profile as changeable because NIST’s additional standardization work continues.
4. Test protocol behavior and interoperability, not just primitive correctness. Examine negotiation, certificates, downgrade resistance, key combination, verification, state management, failure handling, and interactions with suppliers and recipients.
5. Measure resource use and latency on representative platforms and networks. Include constrained devices, high round-trip time, packet loss, large handshakes, retries, and operational capacity limits.
6. Build assurance into the software lifecycle: independent review, negative testing, validation of cryptographic libraries and modules, secure update paths, key and certificate lifecycle controls, and explicit review of any stateful signing requirement.
7. Monitor standards, supplier road maps, vulnerabilities, implementation evidence, and AI-system changes. Set decision triggers and revisit the current and target profiles as evidence changes.

How to measure progress without pretending uncertainty is solved

Progress should be measured by risk reduction and decision quality, not by a single percentage of algorithms replaced. Useful indicators include the proportion of critical services with an owner and complete cryptographic dependency record; the number of long-lived data stores assessed; the number of non-updatable products with a documented treatment; tested protocol and certificate paths; measured performance against service objectives; validated update and rollback procedures; and unresolved supplier dependencies. These indicators are management recommendations derived from the documented risks and CSF profile method, not additional standards requirements.3

Review should also distinguish evidence from assumptions. Record the source and status of each algorithm decision, the document version used, the threat model, expected data and product lifetimes, test conditions, and known limitations. Reassess when standards status changes, when a supplier changes support, when a new critical service is introduced, or when measured behavior contradicts planning assumptions. For AI-enabled systems, include security and resilience review because NIST characterizes the area as active research with rapidly changing challenges and potential solutions.2563

Conclusion

Open problems in cryptographic security are best understood as a sustained systems, governance, and assurance challenge. The possibility of a CRQC creates a credible reason to protect long-lived confidentiality and authenticity now, even though its timing and ultimate capability remain uncertain. Post-quantum standards provide a practical baseline, while ongoing standardization, hybrid complexity, implementation risk, interoperability, performance, supply-chain dependence, and AI-related security change prevent a one-time solution. Enterprises can act responsibly by inventorying dependencies, prioritizing lifetime-sensitive systems, defining adaptable target profiles, testing real deployments, and monitoring explicit decision signals.12543