Introduction

The advent of Quantum Computing is generating more and more headlines. It promises leaps in solving very complex scenarios that require computing power not suitable for the, so far, dominant Von Neumann architecture.

Apart from going to provide a platform for new applications and improve on existing problems it will also add a challenge to IT security.

A reminder that the security community is already working on something …

After I started writing this article, I got my first taster. I logged into a Linux server and for the first time was greeted with the following warning:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

The topic has already caught up with me in a real-world scenario. But what does this message actually mean? Let’s move on from here for now and take a broader look at security, in particular encryption, and the relevance of quantum computing.

Cryptography - Encryption

Encryption is vital for various data handling use cases like proof of origin, identity or historic interaction. Also applies to secure data transfer, integrity of transfer as well as securing data at rest/in storage. Practical uses include web browsing (HTTPS), access to servers (ssh), backup of data, crypto currencies and much more.

There are in principle two families of encryption types. Those are frequently combined to implement standardized protocols.

Symmetric key cryptography

• Shared key secret
• Very fast
• AES standard widely used but also ChaCha20

Use cases (selection)

• Large files (including backups)
• SSL/TLS data transfer/in transit protocol
• VPN, SSH or HTTPS - data transfer following authentication/key exchange

Asymmetric key cryptography

• Public and private key pair
• Slower
• RSA standard widely used but also ECC (Ed25519, ECDSA)

Use cases

• Symmetric key exchange
• Digital signatures
• VPN, SSH or HTTPS - handshake, authenticate server and user

Attack Vectors

Attackers have different routes to compromise systems. I am going to focus on algorithm and key strength and not on governance issues.

The increase in computing power (faster CPUs, and more so GPUs and later on Cloud Computing) reduced attack time. Increased recommended key lengths were the mitigation; the principal algorithms did not change by much.

Store now, decrypt later

There are breaches where attackers are getting hold of encrypted data (LastPass and others) but have no means to decrypt because they did not get access to the keys.

Companies that suffer such a security breach and the loss of encrypted backup/archive data may feel confident that the data is not going to be exposed due to strong encryption. The perpetrator however may still hold on to stolen data in the hope of a future exploit. Storage is cheap enough and not a major cost factor.

This poses a tangible future risk for the victims.

Quantum Computing

Here comes the game changer, or at least something which can disturb the accepted order in security.

Quantum Mechanics

The scientific foundation for Quantum Computing is in quantum-mechanical theories. These have been around for much longer than electronic computers. Without any further explanation, here are some milestones:

timeline
    1900 : Max Planck introduces energy quanta
    1925-1926 : Heisenberg formulates matrix mechanics, Schrodinger publishes wave mechanics
    1935 : EPR paradox and Schrodinger's "entanglement" framing
    1964 : Bell derives inequalities testable in experiments

Arrival of Quantum Computing

It was only a matter of time to turn quantum theories into hardware. It is still very much in it’s infancy but R&D are making progress.

Quantum Computing will provide new opportunities for many industries.

Companies like IBM and Google are investing heavily in Quantum Computing and, surprisingly, consumer offerings are starting to become available even at this early stage.

On “IBM Quantum Cloud” users can already access a free tier alongside paid options. Basically SaaS interface with a PaaS development environment and remote quantum hardware access.

IBM made a Python package available, so surely quantum computing has arrived in the mainstream?

from qiskit import QuantumCircuit

Quantum Computing - Q-Day

Still, it is so far an experimental beginning, but we can expect something bigger and more powerful to arrive in the future.

The expected arrival date of large-scale quantum computing has a name: “Q-Day”.

Problems Quantum Computing could help further

• Weather and climate modelling
• Materials and drugs discovery
• Optimization problems in general
• Decryption

Challenge for Encryption: Quantum Computing Algorithms

And afer Q-Day tools will be available to have a go at the established cryptology.

Quantum computing is expected to break many current public-key systems (for example RSA/ECC) more quickly, while mainly weakening symmetric schemes (for example AES) rather than outright breaking them.

Sure, just make the keys longer? Quantum computing however offers new approaches which are not entirely depending on brute force which can be hampered by longer keys. PQC offers new algorithms.

One example is “Shor’s algorithm”, a quantum algorithm published in 1994 that can be used for factorization, a key ingredient of Cryptography. It is capable to find prime factors of integers much more quickly.

The time “Shor’s” takes is not linearly proportional to the size of the input data unlike concential algorithms; It" becomes more efficient with growing input size, creating a so called superpolynomial speed-up. It’s ability to process data grows with the volume.

Comparision: Traditional brute force vs potential PQC

The chart below shows RSA key length and time it may take to compromise. Bear in mind this is just illustrative (not based on benchmark data) and does certainly have its shortfalls.

Well, we are of course still pre Q-Day. Security researchers however were not fast asleep and have been studying and working on the upcoming security problem …

Welcome to Post-Quantum Cryptography (PQC)

You may not be surprised that risks to industry encryption methods have been discussed by security researchers for a long time. A general discussion in context of quantum computing goes back to around 2006.

The National Institute of Standards and Technology (NIST) started a selection contest asking researchers to find solutions for the perceived future threat. These submissions were peer-tested; many failed, but eventually some were found to be suitable for the PQC era and selected to become standards.

New PQC Security Standards

PQC Security through Retirement

New standards will not be enough unless vulnerable legacy standards are retired as well.

NIST IR 8547 (initial public draft) outlines a transition approach. A commonly cited planning point in this draft is: RSA, ECDSA, and EdDSA (FIPS 186) targeted for deprecation after 2030 and disallowance after 2035 in NIST/federal guidance contexts. Treat these dates as draft planning guidance until final NIST transition publications confirm them.

Applications/Tooling - Present Day Situation

Let’s take a look at the state of play.

Data in Transit (servers and clients)

TLS is the default security layer for protecting data in transit across almost all modern networked systems. This protocol has been hardened through a hybrid TLS key exchange. Combines classical cryptography and PQC resilience in a single TLS 1.3 handshake when hybrid groups are enabled and negotiated (between cleint and server). Cloudflare has reported large and growing PQC adoption in its own traffic telemetry. The exact percentage depends on date and scope, so treat this as a moving metric:

• https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption

TLS Protocol Updates

TLS 1.3+

• Current baseline for deploying hybrid key exchange in practice
• Hybrid modes improve confidentiality against “harvest now, decrypt later”
• PKI identity/signature migration is still in progress

OpenSSL since v1.1.1 (2018)

• eventually earlier if distro patches were made
• 3.2+ Adds key building blocks; PQC behavior depends on the selected providers/libraries and endpoint configuration

Other SSL solutions

• GnuTLS, BoringSSL, etc. also provided support for TLS v1.3.

Servers and Services supporting Hybrid TLS

• Cloudflare
• Linux Distributions with OpenSSL v1.1.1
  • Debian 10, Ubuntu 18.04, RHEL 8
• NGINX - when build against OpenSSL 3.2+
• Apache 2.4.58+: mod_ssl with OpenSSL 3.2+
• Google (Search, Gmail, APIs, etc.)
• AWS (partially, manually configure for TLS 1.3)
• Oracle 26ai (ML-KEM, ML-DSA)

Clients

TLS 1.3 already supported by Chrome, Firefox, Edge clients.

Programming languages:

• Languages like C/C++, Java, Rust, Go, Python, JavaScript and others already have access to PQC libraries - the scope of support depends on those libs, of course.

Digital Certificates:

• PQC certificates exist in pilots/testing, but broad public Web PKI deployment is still in transition.

Crypto Chains:

• PQC poses a big challenge for blockchains in particular due to immutability and decentralization economics/governance.

Keys & Key Management

As shown above RSA (private) keys are vulnerable to Shor’s algorithm. The following article pubished during the World Quantum Summit 2025 projects RSA-1024 to be vulnerable by by 2028 and RSA-2048 by 2030: Neural-Network-Assisted Shor’s Algorithm: The Emerging Threat to RSA Encryption

timeline
    title Potential RSA Vulnerability through PQC (median estimates)
    2028 : RSA-1024
    2030 : RSA-2048
    2032 : Widespread practical capability to compromise RSA encryption increasingly likely

Key Management Protocol

KMIP (Key Management Interoperability Protocol) is a key management protocol (not a TLS key exchange protocol). It is algorithm-agnostic and can support new algorithm identifiers as ecosystems adopt PQC.

Hardware Security Module (HSM)

A more secure alternative to software-based key management are hardware modules designed to manage the keys (generate, store and use).

Cloud Providers

Cloud providers have their own internal approach to managing keys. In general they want to remain standard compliant, keep APIs stable (infrastructure concern, not application) and hide complexity.

Data At Rest

For symmetric encryption (including data at rest), the main known quantum concern is Grover’s algorithm. Unlike Shor’s algorithm, Grover provides only a quadratic (square-root) speedup for key search, so the effective security level of AES is reduced roughly by half in bits. Using longer symmetric keys (for example AES-256) is the standard mitigation.

NSA CNSA 2.0 guidance requires AES-256 for symmetric encryption in its scope, which aligns with the expected Grover-related security margin reduction.

The main focus for protecting data at rest is to have PQC-resilient key management - we looked at this in the previous chapter. So AES-256 encryption at rest with keys managed by a Key Management System (KMS), potentially secured by a Hardware Security Module (HSM).

Quantum Computing Milestones

Here is a timeline

timeline
    title Milestones in Quantum Computing
    1981 : Feynman proposes simulating physics with quantum computers
    1984 : BB84 quantum key distribution protocol introduced
    1994 : Shor's algorithm for factoring and discrete logs
    1996 : Grover's quantum search algorithm
    1998 : Early 2-qubit quantum computations demonstrated
    2001 : Shor's algorithm used to factor 15 experimentally
    2011 : First commercial quantum annealing systems appear
    2019 : Google reports "quantum supremacy" experiment
    2024 : NIST publishes first core PQC standards (FIPS 203/204/205)

Back to Opening Example

Remember this one?

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Text clearly says that the SSH session did not use a post-quantum key exchange (KEX).

We now have a bit more understanding.

Analysis

I turned on SSH verbosity and looked for the KEX algorithm line in the output.

ssh -vv <user>@<host>
 
  debug1: kex: algorithm: curve25519-sha256

A fast, modern, and very secure KEX algorithm by today’s standard. But it is not PQC safe.

PQC KEX Options for OpenSSH

OpenSSH introduced the following PQC-safe hybrid KEX algorithms:

• sntrup761x25519-sha512 (OpenSSH 9.0)
• mlkem768x25519-sha256 (OpenSSH 9.9; made default in OpenSSH 10.0)

None of those were used in the key exchange, hence the warning.

Let’s check the server’s OpenSSH version.

ssh -V

  OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021

The server runs on Alma Linux 8 with OpenSSH 8 installed. The distribution will receive security updates until 2029. The following command confirms the version.

ssh -Q kex

  diffie-hellman-group1-sha1
  diffie-hellman-group14-sha1
  diffie-hellman-group14-sha256
  diffie-hellman-group16-sha512
  diffie-hellman-group18-sha512
  diffie-hellman-group-exchange-sha1
  diffie-hellman-group-exchange-sha256
  ecdh-sha2-nistp256
  ecdh-sha2-nistp384
  ecdh-sha2-nistp521
  curve25519-sha256
  curve25519-sha256@libssh.org
  sntrup4591761x25519-sha512@tinyssh.org

Just for the sake of fun I looked up an Ubuntu 24.04 LTS machine:

ssh -V
  OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024

ssh -Q kex

  diffie-hellman-group1-sha1
  diffie-hellman-group14-sha1
  diffie-hellman-group14-sha256
  diffie-hellman-group16-sha512
  diffie-hellman-group18-sha512
  diffie-hellman-group-exchange-sha1
  diffie-hellman-group-exchange-sha256
  ecdh-sha2-nistp256
  ecdh-sha2-nistp384
  ecdh-sha2-nistp521
  curve25519-sha256
  curve25519-sha256@libssh.org
  sntrup761x25519-sha512@openssh.com

This looks good … sntrup761x25519-sha512@openssh.com KEX is available.

Connecting to that server using ssh -vv confirms that sntrup761x25519-sha512@openssh.com is automatically selected.

  debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

You can also force KEX algorithm through the client.

ssh -o KexAlgorithms=sntrup761x25519-sha512@openssh.com <user>@<host>

Unable to negotiate with x.x.x.x port 22: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,kex-strict-s-v00@openssh.com

Risk Assessment

A reality check:

I am not concerned about PQC risk exposure at present, and there is no need to prepare for a “store now, decrypt later” attack. The server doesn’t store any valuable data.

As a result I am not upgrading the OS just for a more recent OpenSSH server with support for PQC-safe key exchange. It is almost certain that by the time it becomes relevant the server will have been retired.

This may be different for organizations that hold critical information and need to maintain certain security levels due to legal and contractual responsibilities. In this case a server upgrade may be required in support of an SSH server supporting PQC KEX.

Cyber Essentials: Requirements for IT Infrastructure

A bit more due diligence … I checked this established security standard: as of version 3.3 it does not include PQC requirements.

Rectify

With the risk assessment done, I simply silenced the KEX warning. This is a client-side (not server-side) OpenSSH configuration change.

Add the WarnWeakCrypto option to the SSH call, or make it permanent via the SSH config file. This option was added in OpenSSH 10.1; on older clients you can use IgnoreUnknown WarnWeakCrypto to avoid config errors.

ssh -o WarnWeakCrypto=no username@x.x.x.x

~/.ssh/config:

Host myserver
    HostName x.x.x.x
    User username
    WarnWeakCrypto no

Does PQC already Matter today?

In my opinion it is a clear Yes in particular for those who carry responsibility.

A fact is that security protocols are already changing.

PQC comming anyway or arrived already regardless on whether I take action or not (TLS 1.3 for the web for example). Some time in the future older protocols will be retuired. But there are cases where an active decission is important.

Organisations that hold and manage highly sensitive data with statutory requirements, such as long-term archiving, have incorporated PQC Risk Management into their security planning for some time. However, if this has not yet been on your radar, the following may help.

If PQC-related security issues have the potential to expose you or your organisation to risk, then due diligence is advisable. For many organisations, this may not require immediate action, but the topic should at least be on the radar and included in longer-term monitoring and planning.

flowchart TD
    S@{ shape: sm-circ, label: "Start" } --> A[Put PQC security on the agenda for next security meeting]
    A --> B[PQC Security Review - Identify risks to systems and data]
    B -- risks --> B1[Decide and document]
    B1 --> C{Action?}
    C -- Yes --> Implement@{ shape: processes, label: "Implement mitigation(s)" }
    C -- No --> Review
    Implement --> Review[Schedule next PQC Security review]
    Review --> X@{ shape: framed-circle, label: "Stop" }
    style S fill:#fff,stroke:#333,stroke-width:2px
    style X fill:#fff,stroke:#333,stroke-width:2px

Final thoughts

I hope you found this useful.

Happy also to take on feedback - I am not the ultimate expert, just a curious interdisciplinary Informatiker.

Additional Reading

By no means complete.

• NCSC - Timelines for migration to post-quantum cryptography
• NIST IR 8547 - Transition to Post-Quantum Cryptography Standards (IPD)
• Wikipedia - Shor’s algorithm
• NSA Commercial National Security Algorithm Suite 2.0
• IBM - Shor’s algorithm (on a quantum computer)
• Oracle Security Blog - Preparing for Post Quantum Cryptography
• DigiCert - Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST
• Bundesamt fuer Sicherheit in der Informationstechnik (BSI) - Kryptografie quantensicher gestalten
• Cyber Essentials: Requirements for IT Infrastructure v3.3 (pdf)
• Shor’s Algorithm: A Quantum Threat to Modern Cryptography (2017)
• Neural-Network-Assisted Shor’s Algorithm: The Emerging Threat to RSA Encryption
• Hochsicherheitsschloss - “Wie quantensichere Kryptografie Computer langfristig absichert” - by Wilhelm Drehling - published in Heise c’t magazine 23/2025

• Quantum Computing
• Post-Quantum Cryptography
• Encryption
• Cryptography
• Cybersecurity
• RSA
• OpenSSH