‘The fixes are architectural, not bigger pipes’: OpenSSL President on what businesses can expect and how to prepare for a post-quantum internet

Knowing what ‘quantum’ is and why it affects the internet may not be something most people understand.

<![CDATA[ <article> <p>Knowing what ‘quantum’ is and why it affects the internet may not be something most people understand. How a physics concept changes the security of the internet isn’t really at the forefront of most people’s worries.</p><p>But the change is already happening. The internet is preparing for a post-quantum world that renders much of the encryption the world has relied on obsolete. To understand just how powerful post-quantum decryption is, think of enigma: an encryption machine that took the entire secret operation of Bletchley park over a year to crack would be solved almost instantly. For today’s standard public-key encryption algorithms, it's a matter of days or hours.</p><p>By some estimates, the viability of quantum computers capable of this level of decryption are still several years away. But preparations are already happening - and not just by the good guys.</p><h2 id="how-the-good-guys-and-bad-guys-are-preparing-for-q-day">How the good guys and bad guys are preparing for Q-Day</h2><p>Given that quantum computers capable of decrypting the current algorithms many businesses rely on today are all but inevitable, <a href="https://www.techradar.com/pro/security/forget-ransomware-most-firms-think-quantum-computing-is-the-biggest-security-risk-to-come" target="_blank">hackers have begun stealing troves of files</a> that they cannot currently crack but will have huge value once commercially available quantum computers become available.</p><p>To get ahead of the curve, <a href="https://www.techradar.com/pro/security/g7-tells-businesses-to-get-ready-for-quantum-cybersecurity-threats" target="_blank">governance bodies have begun introducing regulations</a> to ensure businesses and services are fully protected ahead of time, using longer, more robust encryption methods that can hold up against the quantum threat. </p><p>But the shift to protecting against quantum threats introduces new problems for the wider internet. Longer signatures during exchanges add to congestion, and when multiplied by the millions of terabytes of data transferred across the internet each day, this could compound into a serious logistical problem if the necessary steps are not taken.</p><p>OpenSSL is one of the world's most widely deployed open source cryptographic libraries. It has been developing open-source post-quantum cryptography to help secure businesses (and the internet) in the billions of secure online interactions that happen every day.</p><p>Ahead of OpenSSL Conference 2026, I spoke to Tim Hudson, President of OpenSSL Corporation, about the post-quantum challenges and how organizations can best prepare for a post-quantum internet.</p><ul><li><strong>What challenges will infrastructure providers face in trying to handle a quantum-safe internet that requires significantly larger digital signatures? What sort of capacity, bandwidth, and latency increases could we expect to see and how can they be addressed?</strong></li></ul><p>It helps to separate two migrations that are usually collapsed into one. Key exchange is largely solved and already deployed — hybrid post-quantum key agreement has been running in mainstream browsers and CDNs for well over a year, and most people reading this have been using it without noticing. Signatures are the unsolved part.</p><p>The numbers drive everything. An ML-DSA-44 signature is 2,420 bytes with a 1,312-byte public key, against 64 bytes for ECDSA P-256. Add certificate chain signatures and the two Certificate Transparency timestamps browsers require, and a naive substitution adds somewhere between 7KB and 10KB to every new connection.</p><p>The problem is not aggregate bandwidth, which is cheap. It is that this pushes handshakes past the initial congestion window — roughly 14KB — and past QUIC's anti-amplification limit. Cross those and you buy an extra round trip on every fresh connection. That is a tail-latency problem, and it lands hardest on mobile, satellite, lossy links and constrained devices.</p><p>The fixes are architectural, not bigger pipes: Merkle Tree Certificates, trust anchor negotiation, and suppressing intermediates. This is a PKI redesign, not a library upgrade.</p><ul><li><strong>How would you recommend CISOs navigate budgetary constraints when trying to secure their business for the quantum era? What are the critical assets to secure?</strong></li></ul><p>Two principles save real money. First, inventory before procurement. You cannot budget a migration you have not scoped, and the discovery phase in a complex estate runs six to twelve months. A cryptographic bill of materials is now explicitly on the regulatory agenda, so this work is not optional in any case.</p><p>Second, buy agility rather than algorithms. Products marketed as "quantum-safe" are a poor investment. The ability to change algorithm without redesigning the surrounding system will still be valuable in fifteen years; any specific algorithm choice may not be.</p><p>For prioritisation, the useful distinction is between confidentiality and authentication. Recorded traffic can be decrypted retrospectively, so anything requiring long-term secrecy is urgent today. Signatures cannot be forged retroactively — a signature made in 2026 and verified in 2026 is not at risk — so authentication is a scheduling problem, not an emergency.</p><p>That points at the genuinely critical assets: hardware roots of trust, firmware and code-signing keys, HSM-held key material, PKI roots with twenty-year validity, and long-lived embedded or operational technology. Those are the things you cannot retrofit later. Everything else is a software update.</p><ul><li><strong>Are there any technologies that businesses can leverage now to maintain backwards compatibility with their existing data and processes as they adopt quantum-safe cryptography?</strong></li></ul><p>Several, and most are already in production. Hybrid key establishment is the obvious one. TLS 1.3 negotiates it cleanly and falls back to classical algorithms when the peer does not support post-quantum, so deployment carries little compatibility risk. For certificates, composite and dual-chain approaches let a single deployment satisfy both old and new relying parties during transition.</p><p>The less visible but more important layer is cryptographic abstraction. The OpenSSL Library provider architecture exists precisely so algorithm implementations can be replaced without touching application code, and that is the mechanism that makes the transition survivable for anyone with a large codebase. </p><p>On the interface side, PKCS#11 v3.2 defines post-quantum mechanisms so HSM-backed applications share a common API, and KMIP handles key lifecycles across multi-vendor estates. I work on both of those standards, and the aim is the same: rotate the algorithm without re-plumbing the system.</p><p>One caution. Hybrid is a transition, not a destination — the Australian Signals Directorate is explicit on that point. If you deploy a hybrid, budget for the second migration now rather than discovering it in 2029.</p><ul><li><strong>What role will open source infrastructure play in the post-quantum internet, and are there any unique challenges or opportunities open-source technologies face?</strong></li></ul><p>Interoperability is the whole problem, and open source is where interoperability actually gets settled.</p><p>Agreeing on an algorithm is necessary but nowhere near sufficient. A working internet migration requires implementations that genuinely interoperate at the byte level, across every vendor, under real conditions. </p><p>That agreement gets reached in shared, publicly testable code far more reliably than in specification documents. The practical consequence is that a handful of open source implementations effectively set the pace of the entire transition.</p><p>The opportunity is scrutiny. Post-quantum algorithms are new, and most real-world cryptographic failures are implementation defects rather than mathematical ones. Side-channel weaknesses are found by people who can read and attack the code.</p><p>The challenges are the familiar ones, and unresolved. Funding remains disproportionate to dependency. Validation lag is the sharper issue: FIPS and Common Criteria validated modules trail published standards by years, so regulated organisations facing 2030 deadlines may find conformant code exists but validated code does not.</p><p>That ecosystem problem is a large part of why the OpenSSL Conference in Prague in October each year is scoped across cryptography and security generally rather than around any single project.</p><ul><li><strong>In your opinion, is regulation and governance moving fast enough to prepare businesses of all sizes for Q-day? Are there any shortfalls you would like to see addressed?</strong></li></ul><p>The direction is right; the coverage is uneven. The pace has changed materially in 2026. In June the US issued Executive Order 14412 and OMB Memorandum M-26-15, setting hard dates for federal civilian systems and putting cryptographic bills of materials on the agenda. </p><p>Australia's Signals Directorate holds one of the more demanding positions globally, expecting a refined transition plan by the end of this year and traditional asymmetric cryptography retired by the end of 2030. The EU roadmap runs national plans to end-2026, high-risk systems to 2030, and full transition to 2035.</p><p>Four shortfalls. Guidance is written for large regulated enterprises; smaller organisations receive exhortation rather than tooling. Validation throughput is a binding constraint that no mandate addresses. </p><p>Nothing credible covers deployed embedded and operational technology with fifteen to twenty-five year service lives and no update path — that is a replacement program, not a migration, and nobody has funded it. And procurement rules should require demonstrated agility and CBOM (Cryptographic Bill of Materials) disclosure rather than algorithm checkboxes.</p><p>I would also retire the "Q-day" framing. The deadlines that will actually bind organisations are being set by regulators, insurers and procurement teams, not by physics.</p><ul><li><strong>What should those outside of the business world expect to see changing as we approach a quantum-safe internet, and what can they do to prepare?</strong></li></ul><p>Mostly, they should expect not to notice. The browser and operating system on your desk have very likely been performing post-quantum key exchange for more than a year without announcing it. That is what a well-run infrastructure migration looks like.</p><p>The visible effects will be modest and mostly indirect: slightly larger handshakes, occasionally slower first connections over poor mobile or satellite links, more frequent firmware updates, and some devices losing support earlier than owners expect because their hardware cannot be upgraded to support the new algorithms. </p><p>The practical advice is unglamorous. Keep software current - that genuinely is most of it. Expect shorter useful lifetimes for anything with a hardware root of trust. And treat consumer products marketed as "quantum-safe" with scepticism; there is very little a consumer can buy that addresses a risk not already being handled upstream.</p><p>The one real personal consideration is long-lived confidential data. Anything that must stay secret for fifteen years or more and is transmitted today could be recorded now and read later. That is a reason to care which services have migrated, not a reason to buy anything.</p> </article> ]]>