Quantum-Safe Security is a Toolbox, Not a Single Solution

The quantum threat is real

Cryptography underpins almost everything in modern networks: VPNs, TLS sessions, IPsec tunnels, DNSSEC, and routing security systems such as RPKI. Without strong encryption, trust in digital infrastructure simply collapses.

And yet this foundation is under threat. The risk is most often framed around quantum computing. Once sufficiently powerful quantum computers are available, they will be able to break widely deployed public-key algorithms such as RSA, Diffie-Hellman, and ECC. This would render much of today’s secure communication vulnerable.

At the same time, it’s important to recognise that classical computing power is also advancing quickly. While current algorithms remain secure, history shows that improvements in hardware, cryptanalysis, and algorithmic efficiency can erode security margins. Even without quantum computers, stronger classical attacks may emerge. Preparing for a quantum future should therefore also mean strengthening cryptographic agility and resilience against future classical attacks.

The urgency is already visible today in so-called Harvest Now, Decrypt Later (HNDL) attacks. Encrypted traffic is being collected and stored with the expectation that, once new cryptanalytic capabilities arrive (quantum or classical) the confidentiality of that traffic will be broken. For sensitive or long-lifetime data, this is a very real and present danger.

For network operators and engineers, the challenge is clear: waiting until the threat fully materialises is not an option. The time to evaluate, test, and deploy quantum-safe methods is now.

Quantum-safe options - two main paths (and alternatives)

When we talk about defending against quantum attacks, two main approaches dominate: Post-Quantum Cryptography and Quantum Key Distribution. Alongside these, there are alternative approaches including Distributed Symmetric Key Establishment, which might be less mature (for now) but potentially useful in certain contexts.

Post-Quantum Cryptography (PQC)

PQC aims to replace existing public-key algorithms with new ones designed to resist quantum attacks. NIST has selected several algorithms (including ML-KEM for key exchange and ML-DSA for signatures), and standardisation efforts in the IETF and other bodies are underway. Multiple networking vendors have already implemented PQC.

Pros:

• Software-based: deployable on existing networks, in many networks without requiring new hardware
• Designed to be integrated into protocols like TLS, IPsec, and SSH
• Strong global momentum and government backing

Cons:

• Larger key sizes might slow protocols down
• Heavier CPU/memory usage, which in practice may demand hardware upgrades
• Immature code bases: careful implementation and interoperability testing are needed before large-scale rollout

For most operators, PQC will be the first quantum-safe technology they encounter. It provides a path forward that looks familiar but requires careful planning for performance and deployment.

Quantum Key Distribution (QKD)

QKD takes a very different path by using quantum physics to distribute keys. The idea is elegant: if an attacker tries to observe the quantum state, the system detects the intrusion.

Pros:

• Provides information-theoretic security
• Resistant to both classical and quantum cryptanalysis
• Already widely available from multiple vendors
• Integrates with current widely deployed protocols via RFC8784

Cons:

• Requires specialised hardware
• Works only over optical fibre or satellite channels
• Limited in distance and scalability making Internet-wide (cross continent) deployment unrealistic

QKD is often considered for specialised high-value networks (government, finance, defence), but today, mainly due to it’s high price point, less relevant for the majority of operators who need scalable and interoperable solutions.

Distributed Symmetric Key Establishment (DSKE)

DSKE is a software-based approach. Instead of relying on asymmetric cryptography, it uses pre-shard random data to establish symmetric keys between endpoints.

Pros:

• Runs on existing IP networks, no need for quantum hardware
• Lightweight and efficient
• Doesn’t exchange any key material ‘over the wire’ but only sends instructions

Cons:

• To achieve true information-theoretic security, DSKE requires an initial physical delivery of pre-shared (PSRD) random data
• Still early-stage: needs more implementations, testing, and community review

DSKE should be seen as a complementary tool. For operators already experienced with symmetric key systems, or for those who prefer to avoid asymmetric cryptography, it offers an interesting alternative.

Why alternative methods like DSKE are interesting

While PQC and QKD dominate the headlines, alternative methods such as DSKE may fill important gaps:

• Distance: Unlike QKD, DSKE can scale across long-haul or internet-scale networks.
• Trust models: Some organisations are wary of asymmetric cryptography. DSKE provides a symmetric-only model.
• Complementary use: DSKE can be used in addition to PQC or QKD to add resilience by giving networks more than one tool to rely on.

The underlying ideas are documented in research: Quantum-Resistant Trustless Key Exchange and Secure Communication (arXiv:2407.20969).

Other quantum-safe approaches

Beyond PQC, QKD, and DSKE, two other approaches are worth highlighting:

Hybrid cryptography

Hybrid methods combine existing classical cryptography with quantum-safe algorithms. For example, a TLS handshake might use both an ECC key exchange and a PQC key exchange. The idea: even if one scheme is broken, the other continues to secure the session.

• Already being standardised in the IETF, particularly for TLS and IPsec
• Provides a smooth transition path to enable networks to gain quantum resistance without abandoning existing, well-tested cryptography immediately
• Likely to become one of the first practical steps toward quantum-safe deployments

Trusted courier / physical transport of keys

In some cases, the most robust solution is also the simplest; i.e., physically transporting keys via trusted couriers. Governments, militaries, and critical infrastructure operators often rely on this approach today.

• Offers information-theoretic security when combined with one-time pads or highly secure line encryptors
• Not scalable for the Internet, but very relevant for specific high-security use cases
• Relies on secured equipment and physical delivery of key material, meaning it’s highly secure but very costly and labor intensive at the same time

These methods show that quantum-safe security is not one-size-fits-all. Operators may end up combining multiple approaches to balance scalability, trust, and resilience.

Open source DSKE implementation

To take DSKE from research into practice, a first open-source reference implementation is being worked on. The goal is to make DSKE tangible, testable, and available to the community. However, it is not production ready (yet) as for example, side-channel attack protections are missing.

Architecture overview

The DSKE topology consists of clients and hubs:

• Clients are responsible for producing encryption keys and delivering them to encryptors:
  • Each client registers with all hubs in the network.
  • Clients receive large pools of Pre-Shared Random Data (PSRD) from each hub.
  • In a key establishment, one client acts as the initiator and another as the responder.
  • The initiator allocates a key, splits it into shares using Shamir’s Secret Sharing (SSS), and distributes the shares across multiple hubs.
  • Hubs relay the shares — one per hub — to the responder, using one-time-pad encryption based on the PSRD.
  • The responder reconstructs the key from the received shares, even if some are missing, thanks to the properties of SSS.
• Hubs act as relays. Their responsibilities include:
  • Allowing clients to register.
  • Distributing PSRD blocks to clients.
  • Relaying shares between clients using one-time-pad encryption based on their local PSRD.
  • Encryptors consume the produced keys from clients and use them for securing communication channels.

These roles communicate over three logical interfaces:

1. DSKE interface (between clients and hubs, for running the protocol)
2. Key delivery interface (between clients and encryptors, for providing usable keys)
3. Management interface (for configuration and orchestration; in early development)

Key takeaways

To get started, a detailed user guide is available to help you run the proof-of-concept and simulate DSKE interactions: DSKE Python User Guide.

The full repository, including code and documentation, is here: github.com/brunorijsman/dske-python

The current release is meant for experimentation, education, and community feedback. By working with the code, network engineers can better understand the design trade-offs and practical aspects of DSKE, and help shape its future direction.

This work is supported by the RIPE NCC Community Projects Fund.