Crypto Agility: Why Now?

The Evolution of Cryptography: From TLS to Blockchain, From Regulation to Post-Quantum Cryptography (PQC) - A Corporate Perspective

KAI Informatics | Insight

Abstract

Cryptography moved beyond a state monopoly in the 1970s and became the foundational trust layer of the Internet and digital finance. Today, the widespread adoption of TLS 1.3, the pressure of standards such as PCI DSS 4.x, and the maturation of post-quantum cryptography (PQC) standardization turn cryptographic governance into an operational necessity for banks, payment systems, fintechs, and digital asset service providers. This article brings together cryptography’s major milestones, its impact on e-commerce and e-finance, its use in blockchain systems, and the practical implications of migrating to PQC within a corporate framework.

Executive Summary

TLS 1.3 is now the de facto standard on the Web; TLS 1.2 remains a controlled legacy layer. (Measured shares vary by metric and source.)

Regulation and audit requirements transform “crypto selection” from a purely technical decision into a governance decision (e.g., PCI DSS 4.x).

PQC is not a distant future: NIST has published standards for ML-KEM, ML-DSA, and SLH-DSA; crypto agility and cryptographic inventory work should start now.

The quantum threat matters, but it is not the only threat: weak randomness (seed/RNG), key lifecycle issues, misconfiguration, and side-channel vectors can break systems today.

A pragmatic corporate approach: cryptographic inventory -> risk scoring -> crypto-agility architecture -> hybrid/PQC migration roadmap -> key management governance (HSM/MPC).

1. Introduction: Building Trust Over Untrusted Channels

The modern Internet is inherently an untrusted communication environment. On open networks, data transmission faces three fundamental threats: eavesdropping (confidentiality), tampering (integrity), and impersonation (authentication). The digital economy (e-commerce, banking, payments, identity services) exists because cryptographic protocols can manage these threats mathematically.

Threats

Eavesdropping: unauthorized parties read network traffic.

Tampering: data is modified in transit.

Impersonation: one party communicates under a forged identity.

2. The Cryptographic Revolution and Political Context: “Crypto Wars”

Until the 1970s, cryptography was largely controlled by intelligence and military institutions. Breakthroughs such as Diffie-Hellman and RSA reshaped cryptography for civilian use; this shift naturally triggered debates about whether strong encryption should be broadly accessible. Strong encryption is indispensable for privacy and security; at the same time, due to its dual-use nature, it remains at the center of policy and regulatory discussions.

2.1. Public-Key Cryptography and Civilian Access

Public-key cryptography enables two parties to establish keys securely and authenticate each other without sharing a secret in advance. This is the cornerstone of the Internet’s scalable trust model.

2.2. Export controls, key-size debates, and their legacy

During the 1990s, several jurisdictions restricted the export and distribution of strong cryptography; weakened algorithms and short key lengths periodically became part of policy agendas. While many of these policies have been abandoned, legacy protocols and misconfigurations that remain as “technical debt” still create corporate risk today.

3. From SSL to TLS 1.3: The Evolution of Web Security

The SSL family emerged to provide confidentiality and integrity for the Web, and later evolved into TLS. TLS 1.3 (RFC 8446) reduces attack surface and accelerates the handshake by removing accumulated security debt from earlier versions.

TLS 1.3 Handshake (Summary)

TLS 1.0 and 1.1 have been effectively abandoned by modern security profiles; RFC 8996 officially deprecates these versions.

4. E-Commerce and E-Finance: Cryptography Is Now a Compliance Topic

Cardholder data, payment flows, customer identity, and financial messaging have pushed cryptography from a technical preference to a compliance requirement. With PCI DSS 4.0.1 keeping the effective date of v4.x future-dated requirements at 31 March 2025, cryptographic control maturity becomes a direct audit topic for many organizations.

In practice, this extends beyond TLS upgrades to certificate lifecycle management, key management, secure module usage (e.g., FIPS profiles), configuration standards (e.g., NIST SP 800-52r2), and traceable governance processes.

5. Current State of the TLS Ecosystem (2025/2026 Measurements)

“Usage share” depends on where the measurement is taken: some reports measure the negotiated version in real web traffic, while others measure server-side support or preference. The table below combines two widely used measurement perspectives.

QUIC is not “encryption” by itself; it is a transport protocol that relies on TLS 1.3 for its security handshake.

6. A Fork in the Road: Cryptography in Blockchain Systems

Traditional PKI and TLS rely on a trust model built around centralized Certificate Authorities (CAs). Blockchain networks distribute trust through protocol rules and consensus. This contrast shows how the same cryptographic building blocks can be used under different trust models.

6.1. Algorithm choices: curves, hash functions, and standardization

While NIST profiles dominate the Web and financial systems, some blockchain designs choose different curves or parameters. From a corporate perspective, what matters is to inventory where which algorithm is used, under which assumptions, and with what lifecycle controls.

6.2. The evolution of custody technologies: from HSM to MPC

Digital asset custody elevates key management to the center of operational security. HSMs provide physical security and certification advantages, while MPC avoids concentrating keys in a single place and can provide operational flexibility and resilience. The corporate choice should consider regulatory expectations, audit trail, business continuity, and the threat model together.

6.3. Public blockchains and PQC readiness: Bitcoin, Ethereum, Solana

Public blockchains rely heavily on public-key signatures for ownership and consensus. This makes them a useful lens for PQC—not as an investment topic, but as a stress test for crypto-agility under performance, compatibility, and governance constraints.

The snapshot below summarizes publicly discussed quantum-resistance initiatives and the practical migration friction points. Several items are proposals or research prototypes; organizations should treat them as signals, not guarantees, and maintain their own cryptographic dependency inventory across wallets, custody stacks, and integration layers.

Notes: The items above reflect publicly available proposals and experiments (see Appendix C [14]–[18]); maturity and timelines vary, and none should be treated as a guarantee. Use them to inform risk inventory and crypto-agility planning.

Within the Bitcoin ecosystem, quantum-risk discussions have increasingly converged on a staged approach: before attempting a full post-quantum signature migration, BIP-360 proposes Pay-to-Tapscript-Hash (P2TSH) as a first-step mitigation. P2TSH is structurally close to Taproot, but removes the ECDSA/Schnorr “key-path spend”, reducing the risk created by long-lived public keys that remain exposed in the UTXO set (long-exposure mitigation). Importantly, this is not the same as “Bitcoin is PQC-ready”: the proposal text explicitly notes that protecting against short-exposure attacks (e.g., public keys exposed in the mempool while awaiting confirmation) may still require post-quantum signatures, which the authors intend to address in a separate future proposal.

In 2025 the work was discussed under the name “P2QRH”; later in 2025 it was renamed to “P2TSH” to reflect a reduced scope and broader generality, while algorithm selection and on-chain verification cost / DoS considerations were deferred to later phases. For institutions, the right takeaway is not “public chains have migrated to PQC”, but “major ecosystems are exploring incremental, governance-compatible mitigations under hard performance constraints”.

7. PQC: The Quantum Threat and the “Time Dimension”

The maturation timeline of quantum computers is uncertain; physical constraints such as noise, error correction, and scalability keep significant uncertainty in place. However, the critical risk is the “harvest now, decrypt later” model: data requiring long-lived confidentiality can be collected today and decrypted in the future.

Therefore, before asking “when will quantum arrive?”, organizations should first ask: “Which data has long confidentiality lifetimes, and which cryptographic dependencies protect it?”

7.1. Standardization status: NIST’s PQC family

NIST has published standards for post-quantum key establishment and signatures: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). Corporate migration typically starts with hybrid approaches (classical + PQC), managing the performance and compatibility trade-offs step by step.

7.2. PQC and Lightweight Cryptography (LWC): complementary architectures

While PQC targets quantum resistance, the LWC family targets efficiency on constrained devices. In areas such as IoT, LWC on the symmetric side (e.g., ASCON) provides major value; on the asymmetric side, PQC costs must be managed more carefully.

8. It Can Break Without Quantum: Operational Cryptography Risks

Even with quantum risk in the spotlight, the most common failures in organizations come from operational and implementation issues: weak randomness (seed/RNG), faulty key generation, poor certificate lifecycle management, misconfigured TLS, vulnerable libraries, and hardware or application-driven side-channel attacks. A risk inventory must cover not only algorithm choices, but also implementation and operations.

9. Impact Domains: Finance, Identity, Critical Infrastructure

The table below summarizes how quantum-oriented risk conversations map to corporate domains. Note: several of these impacts can also be triggered by classical attack vectors.

10. A Corporate Roadmap: Inventory -> Agility -> Migration

Recommended action list:

Cryptographic inventory: protocols, algorithms, key sizes, certificate chains, KMS/HSM/MPC dependencies.

Data classification + confidentiality lifetime: connect “how many years must this data remain confidential?” to business criticality.

Crypto-agility target architecture: turn algorithm change into a capability, not a project (API/SDK abstraction, policy-as-code).

Hybrid migration plan: expand TLS 1.3 coverage -> pilot hybrid key establishment/authentication -> update certificate and key lifecycle controls.

Audit trail and governance: configuration standards (e.g., NIST SP 800-52r2), compliance requirements (e.g., PCI DSS 4.x), and third-party risk management.

11. Where Does KAI Fit?

In regulated organizations (banks, financial institutions, payment and digital asset ecosystems), deploying advanced technologies securely and auditable requires more than technical implementation - it requires governance and compliance-by-design. KAI Informatics aims to be a partner for organizations adopting advanced technologies such as digital assets, blockchain, and AI, supporting cryptographic risk inventory, architectural assessment, control design, and operational governance.

Note: When covering recent developments in quantum computing, it is essential to frame the topic not only as a speed/scale race, but also through physical constraints and uncertainty (decoherence/noise).

Appendix A: Cryptography Milestones (Selected Timeline)

Appendix B: Glossary (Selected)

PQC (Post-Quantum Cryptography): a family of algorithms designed to resist attacks by quantum computers.

PFS (Perfect Forward Secrecy): compromise of a long-term key does not compromise past sessions.

HSM (Hardware Security Module): cryptographic module that stores keys within hardened hardware.

MPC (Multi-Party Computation): shared computation approach where keys are not concentrated in a single point.

TLS (Transport Layer Security): family of secure transport protocols used on the Internet.

Appendix C: References

[1] HTTP Archive Web Almanac 2025 - Security Chapter (protocol versions)

[2] F5 Labs - The State of Post-Quantum Cryptography (PQC) on the Web (TLS telemetry, Top 1M)

[3] RFC 8446 - TLS 1.3 (IETF)

[4] RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 (IETF)

[5] NIST SP 800-52 Rev.2 - Guidelines for TLS (configuration guidance)

[6] PCI SSC - Just Published: PCI DSS v4.0.1 (31 Mar 2025 effective date unchanged)

[7] NIST - What is Post-Quantum Cryptography? (harvest now, decrypt later)

[8] NIST FIPS 203 - ML-KEM

[9] NIST FIPS 204 - ML-DSA

[10] NIST FIPS 205 - SLH-DSA

[11] Apple Security Research - iMessage with PQ3

[12] Cloudflare - State of the post-quantum Internet in 2025

[13] Cloudflare - The state of the post-quantum Internet (2024)

[14] Bitcoin Optech - Quantum resistance topic page (overview of Bitcoin-specific exposure and mitigations)

[15] BIP 360 – Pay-to-Tapscript-Hash (P2TSH) (proposal text)

[16] Ethereum.org roadmap - Future-proofing: Quantum resistance

[17] Ethereum Improvement Proposals - EIP-8051 (ML-DSA precompile) and EIP-8052 (Falcon precompile)

[18] Solana Improvement Documents - Discussion #226 (transaction size constraints; references to Winternitz signatures)

[19] Bitcoin Dev mailing list – Major BIP 360 Update (P2TSH)

[20] Bitcoin Optech Newsletter #385 (2025 Year-in-Review) – P2QRH → P2TSH rename note

[21] Ethereum.org – Trillion Dollar Security: quantum resistance and migration paths

[22] Solana – What would Solana need to change to become post-quantum secure? (engineering discussion)

[23] NIST IR 8547 – Transition to Post-Quantum Cryptography Standards

[24] UK NCSC – PQC migration timelines

[25] NIST NCCoE – Crypto-agility considerations for migrating to PQC