Electrical engineering article

Quantum computer security: Post-quantum cryptography for developers

Technical guide to post-quantum cryptography and pragmatic PQC migration in real systems

What you will learn in this article

Table of contents

Why developers must act now

Classical public-key schemes such as RSA and ECC can be broken in the long run by quantum algorithms. Anyone encrypting only with classical schemes today risks sensitive data being decrypted later. That is what quantum computer security is about.

Note: This article stays technical but is deliberately practical for developer teams in app, backend, and infrastructure projects.

Basics: What makes quantum computers dangerous?

A quantum computer is not a classical processor with faster transistors but a physical computing system. It deliberately uses quantum-mechanical states of particles (e.g. electron spin, superconducting circuits, or photons) to process information.

Computing on quantum hardware therefore means: prepare a state, transform it with a gate sequence, then measure. Many algorithms are run repeatedly to obtain a reliable result from probabilistic measurements.

Practically central is decoherence: qubits lose their information quickly due to noise. That is why error correction, low temperatures, and very precise control are needed. This engineering hurdle is the main reason powerful quantum attacks are not yet broadly available.

Quantum computers use quantum-mechanical states directly as a computing resource. A qubit can represent multiple states at once in superposition, and qubits can be coupled through entanglement.

Shor solves factorization and discrete logarithms more efficiently than classical methods. That puts RSA, DH/ECDH, and ECDSA under pressure. Grover speeds up brute-force search, reducing the effective security of symmetric keys.

Why Shor’s algorithm is so dangerous

RSA security relies on the fact that splitting a large number N = p · q into its prime factors p and q is extremely costly for classical computers. For sufficiently large key sizes this is not realistically feasible in practice.

Shor’s algorithm does not attack this problem merely with more compute, but with a different mathematical strategy. It reduces factorization to a period-finding problem. Instead of searching for factors of N directly, you consider a function of the form:

f(x) = a^x mod N

Here a is a randomly chosen integer coprime to N. This function is periodic: there is a smallest r such that the same state is reached again:

a^r ≡ 1 mod N

This r is the sought period. That is the core of the algorithm: if this period is known, the factors of N can be computed with high probability.

How factors arise from the period

If the found period r is even and a^(r/2) is non-trivial, candidates for the factors can be computed via the greatest common divisor:

gcd(a^(r/2) - 1, N)
gcd(a^(r/2) + 1, N)

If these expressions yield non-trivial divisors of N, factorization has succeeded. This step is mathematically elegant: from the structure of the modular exponential you obtain information about the primes directly.

Why this is classically hard

Classical factorization methods such as the number field sieve scale very poorly with key length. For RSA-2048 this leads to a practically intractable effort. The issue is not that a single step is complicated, but that the overall search space is enormous.

Finding the period is also not efficiently solvable on classical machines. This is where quantum mechanics enters: a quantum computer can process many states in superposition at once and make periodicity visible with a quantum Fourier transform (QFT).

Simplified flow of Shor’s algorithm

1. Choose a number a coprime to N.
2. Evaluate f(x) = a^x mod N on many states in parallel.
3. Extract period information with a quantum Fourier transform.
4. Reconstruct the period r from the measurement outcome.
5. Compute non-trivial factors of N using r.

Why this is critical for RSA and ECC

RSA relies on factorization. ECC and classical Diffie–Hellman rely on the discrete logarithm problem. Shor’s algorithm can attack both problem classes efficiently. That is what makes it dangerous: it does not merely speed up classical attacks a little—it changes the complexity class of the problem.

For developers this means: The security of RSA, ECDSA, ECDH, and similar schemes is not stable in the long run once sufficiently large, error-corrected quantum computers exist.

Putting the time horizon in perspective

There is no exact date for practical quantum attacks on large production systems. A realistic uncertainty window is about 10 to 20 years for broad relevance, with earlier partial risks in special scenarios.

• Technical progress is fast, but hardware remains difficult.
• Standards and migration paths are already defined (NIST, CNSA).
• Lead time for a safe migration is usually longer than a single release cycle.

Post-quantum cryptography: standards and selection

Post-quantum cryptography (PQC) denotes algorithms that run on classical computers and are, to current knowledge, resistant to known quantum attacks. For teams this means: prepare architecture and protocols for algorithm agility now.

Values are intentionally rough; concrete parameters depend on security level and implementation.

What does this mean for classical schemes?

For classical public-key schemes the difference is dramatic: a sufficiently capable quantum computer could attack RSA-2048 or ECC not just somewhat faster but fundamentally more efficiently. NIST illustrates this vividly: what would take classical computers billions of years could shrink to hours or days for a cryptographically relevant quantum machine.

Symmetric cryptography fares better: AES is not directly broken by known quantum algorithms, but Grover’s algorithm reduces effective security to roughly the square root of the original search space. Simplified: under quantum attack AES-256 behaves like about 128-bit security and remains very strong, while AES-128 offers much less margin. That is why NIST and NSA recommend PQC for public key for long-term protection, combined with AES-256 and SHA-384 or SHA-512 for additional margin.

Complexity comparison: classical vs. quantum

The decisive difference between classical and quantum-based attacks is not only speed but the complexity class of the underlying problem.

An algorithm is considered practically secure if computational cost grows very quickly with key length—typically exponentially or sub-exponentially. Today’s cryptography relies on that.

RSA factorization compared

For RSA, security rests on the difficulty of factoring a large number N = p · q.

Growth is extremely fast. Small increases in key length lead to vastly higher compute cost.

That is the crucial difference:

• Classical: cost grows extremely fast → practically intractable
• Quantum: cost grows moderately → practically feasible

Symmetric cryptography (AES) compared

Symmetric schemes such as AES are affected not by Shor but by Grover’s algorithm.

• Classical: cost = 2ⁿ
• Quantum (Grover): cost ≈ 2^n/2

Therefore:

• AES-128 → effectively ~64-bit security (risky)
• AES-256 → effectively ~128-bit security (still strong)

Hash functions

Hash functions are also affected, but less critically:

• Preimage attack: 2ⁿ → 2^n/2
• Collision attack remains ~2^n/2

Hence:

• SHA-256 → reduced but still usable
• SHA-384 / SHA-512 → recommended for long-term security

Why this difference matters so much

Modern cryptography assumes that certain problems are not efficiently solvable.

Quantum computers change that assumption:

• Factorization → efficiently solvable
• Discrete logarithm → efficiently solvable

The mathematical basis of many deployed systems then collapses.

Why lattice-based cryptography is considered quantum-resistant

Modern PQC schemes such as Kyber (ML-KEM) and Dilithium (ML-DSA) are not based on factorization or discrete logarithms but on problems from linear algebra—more precisely lattices.

You can picture a lattice as a regular grid of points in high-dimensional space. Each point is a combination of basis vectors.

Core idea: computing with noisy equations

The central problem behind many PQC schemes is learning with errors (LWE).

A linear system is deliberately perturbed with noise:

b = A · s + e

• A → known matrix
• s → secret vector (the key)
• e → random noise (small errors)

The goal is to reconstruct the secret vector s from A and b.

Why is this hard?

Without noise this would be an ordinary linear system and easy to solve. Noise makes the problem unstable:

• Small errors distort every equation
• Many solutions look plausible
• The search space becomes huge

Geometrically, this corresponds to finding a lattice point “close enough” to a noisy target.

Why quantum computers do not help here (today)

For problems like factorization, Shor provides an efficient quantum algorithm. For lattice problems such as LWE, that is not currently the case.

The best known attacks—classical and quantum—still require very high effort.

• No known polynomial-time solution
• Attacks remain exponential or sub-exponential
• Parameters can be increased deliberately

From LWE to real schemes (Kyber / Dilithium)

In practice optimized variants are used, e.g.:

• Ring-LWE (RLWE)
• Module-LWE (MLWE)

These reduce memory and improve efficiency without fundamentally changing security assumptions.

• Kyber → based on module-LWE (key exchange)
• Dilithium → also lattice-based (signatures)

Why these schemes use more data

A downside of PQC is larger payloads:

• Larger public keys
• Larger ciphertexts
• Larger signatures

Many vectors and matrices must be stored instead of single integers as in RSA or ECC.

Simple example (heavily simplified)

A minimal sketch might look like this:

# heavily simplified — illustration only
        
        import numpy as np
        
        A = np.random.randint(0, 100, (3,3))
        s = np.random.randint(0, 10, (3,1))
        e = np.random.randint(-1, 2, (3,1))  # small noise
        
        b = A @ s + e
        
        print("A:", A)
        print("b:", b)
        
        # Attacker sees only A and b → reconstructing s is hard

Why developers should bet on this

• No known efficient quantum attacks
• Standardization by NIST
• Already integrable into real systems

For developers this means: The future of public-key cryptography is very likely lattice-based.

Concrete attack scenarios with quantum computers

The quantum threat is not only theoretical. Many systems already face real risk—especially from “harvest now, decrypt later.”

Attack scenario 1: Recorded TLS connections

An attacker records encrypted connections today, e.g. HTTPS traffic.

• 2026: TLS handshake uses RSA or classical ECDH
• Attacker stores all traffic
• 2035+: quantum computer available
• → retrospective decryption becomes possible

Even if data looks safe today, confidentiality can be lost entirely in the future.

Attack scenario 2: Missing forward secrecy

Without forward secrecy the risk is even higher.

• Server uses a static RSA key
• Attacker obtains the private key later
• → all old connections can be decrypted

However: Forward secrecy does not protect against quantum attacks on the key exchange itself.

Attack scenario 3: Signatures and software updates

Digital signatures protect software updates, firmware, and container images today.

• Code is signed with ECDSA
• The public key is public
• A quantum computer computes the private key
• → attacker can forge valid signatures

This especially affects:

• IoT devices
• Industrial systems
• Software supply chains

Attack scenario 4: VPNs and long-lived keys

Many VPN systems use long-lived keys or certificates.

• Attacker records encrypted traffic
• Keys are broken later
• → entire communication can be reconstructed

Especially critical:

• Government communication
• Trade secrets
• Medical data

Attack scenario 5: PKI infrastructure

Public-key infrastructure relies on trusted certificates.

• Root CA uses RSA or ECC
• Quantum computer compromises the private key
• → entire certificate chain becomes untrustworthy

Why these scenarios matter already today

The critical factor is data lifetime.

• Short-lived data → low risk
• Long-term confidential data → high risk

Conclusion for developers

The greatest danger is not tomorrow’s attack but delayed migration.

• Attackers collect data today
• Attacks happen in the future

Performance and trade-offs of post-quantum cryptography

Post-quantum cryptography is not a simple drop-in replacement for RSA or ECC. It has real effects on performance, memory, and networking.

Size comparison: classical vs. PQC schemes

Size differences directly affect network protocols and storage needs.

Impact on TLS and networking

Larger keys and signatures lead to:

• Larger TLS handshakes
• More network packets
• Higher connection-setup latency

Example:

• ECDSA certificate → a few hundred bytes
• Dilithium certificate → several kilobytes

This can matter especially for:

• Mobile networks
• IoT devices
• High-frequency APIs

CPU and compute cost

PQC is not always slower—but cost is distributed differently:

• Key generation → often more expensive
• Signing → moderate
• Verification → sometimes faster than classical schemes

That means:

• Servers doing many verifications may benefit partly
• Low-CPU devices can be stressed

Memory and infrastructure cost

Larger keys impose extra requirements:

• More RAM for keys and buffers
• Larger certificates in PKI systems
• More database storage

Hybrid cryptography as a transition

In practice a hybrid approach is common today:

• Classical (e.g. X25519)
• +
• PQC (e.g. Kyber)

Both keys are combined so security holds against both threat models.

Typical practical mistakes

• Deploying PQC without performance tests
• Underestimating handshake size
• No fallback strategy
• Ignoring crypto agility

Engineering recommendations

• Always benchmark (TLS, API, load)
• Test hybrid crypto in staging first
• Measure bandwidth and latency
• Watch memory usage

Threat model: who attacks you and what is realistic?

Security decisions only make sense if you know who you defend against. In the quantum context attackers differ greatly in capability, time horizon, and resources.

Attacker classes

1. Passive attacker (traffic capture)

The simplest but often underestimated adversary:

• records encrypted traffic
• does not actively interfere
• waits for future decryption capability

This attacker is already realistic today (e.g. internet backbone, nation-state actors).

2. Active attacker (MITM)

An active attacker can manipulate connections:

• performs man-in-the-middle attacks
• forces weaker algorithms
• exploits implementation bugs

With quantum computers this attacker can additionally:

• reconstruct keys
• actively decrypt connections

3. Nation-state actor (high-end adversary)

The most relevant opponent in the quantum context:

• has large compute resources
• can store data for years
• has access to future technology

Attack targets

Not all data is equally critical. What matters is protection lifetime.

• Short term (minutes–days): low risk
• Medium term (months–years): moderate risk
• Long term (10+ years): high risk

When is PQC really necessary?

A simple decision rule for developers:

if (protection_lifetime > time_until_quantum_computer):
    deploy PQC now
else:
    plan migration

“Time until quantum computer” is deliberately vague—that is what makes planning hard.

Typical misconceptions

• “Quantum computers are far off” → migration takes longer than you think
• “Our data is not interesting” → often underestimated
• “Forward secrecy is enough” → does not cover all scenarios

Risk assessment in practice

A realistic model combines several factors:

• Data value
• Protection lifetime
• Attacker capability
• System exposure (internet, internal network, IoT)

That yields:

• High risk: deploy PQC / hybrid immediately
• Medium risk: prepare migration
• Low risk: monitor and plan

Practical implementation: from theory to prototype

Post-quantum cryptography is not only a research topic—it is already available in libraries, test environments, and early integrations. For developers it is essential to classify the examples correctly:

• Educational examples explain the mathematical principle
• PoC examples show the API and flow
• Integration examples show how PQC fits into TLS, services, and infrastructure

Educational example: noisy linear equations as the core idea of LWE

The following code is not a real crypto library—only a simplified illustration of the math behind lattice schemes. It shows why a linear system with small noise suddenly becomes hard to reconstruct.

import numpy as np

# Educational example: heavily simplified
# A = public matrix
# s = secret vector
# e = small noise
# b = observed value

A = np.random.randint(0, 100, (3, 3))
s = np.random.randint(0, 10, (3, 1))
e = np.random.randint(-1, 2, (3, 1))

b = A @ s + e

print("Public matrix A:")
print(A)
print("Observed vector b:")
print(b)

# An attacker only knows A and b here.
# Without noise, s would be easy to compute.
# The extra noise makes reconstruction much harder.

PoC: post-quantum KEM and signature in Python with liboqs

This example shows a minimal proof of concept with liboqs. It helps you understand the basic flow of a quantum-resistant key exchange and a signature:

• Generate a key pair
• Encapsulate and decapsulate a shared secret
• Sign and verify a message

Such tests are especially useful in early evaluation phases for backend services, security gateways, or internal toolchains.

import oqs

# -----------------------------
# 1) KEM / key exchange
# -----------------------------
# Goal: two parties derive a shared secret without sending it directly.

with oqs.KeyEncapsulation("Kyber768") as kem_alice:
    public_key = kem_alice.generate_keypair()

    # Peer encapsulates a shared secret with the public key
    ciphertext, shared_secret_enc = kem_alice.encap_secret(public_key)

    # Original party decapsulates the secret again
    shared_secret_dec = kem_alice.decap_secret(ciphertext)

    assert shared_secret_enc == shared_secret_dec
    print("KEM OK: shared secrets match")

# -----------------------------
# 2) Signature / authenticity
# -----------------------------
# Goal: sign a message so authenticity and integrity can be verified.

with oqs.Signature("Dilithium5") as sig:
    public_sig_key = sig.generate_keypair()

    message = b"Confidential message"
    signature = sig.sign(message)

    valid = sig.verify(message, signature, public_sig_key)
    print("Signature valid:", valid)

Integration example: PQC in Go with CIRCL

The same idea in Go—especially for developers working on services, gateways, or security components who want to integrate PQC early into existing backends.

package main

import (
    "bytes"
    "crypto/rand"
    "fmt"

    "github.com/cloudflare/circl/kem/kyber/kyber1024"
)

func main() {
    // Generate key pair for KEM
    pub, priv, err := kyber1024.GenerateKeyPair(rand.Reader)
    if err != nil {
        panic(err)
    }

    // "Sending" side encapsulates a shared secret
    ct, ssEnc := pub.Encapsulate(rand.Reader)

    // "Receiving" side decapsulates the shared secret
    ssDec := priv.Decapsulate(ct)

    if !bytes.Equal(ssEnc, ssDec) {
        fmt.Println("Error: shared secrets do not match")
        return
    }

    fmt.Println("KEM OK: shared secrets match")
}

Integration example: hybrid TLS in lab or staging

PQC migration rarely starts at the application layer; it often starts with transport encryption. A sensible first step is a hybrid TLS test environment where classical and post-quantum schemes are evaluated in parallel.

The following is not a full production rollout but a typical lab/staging approach:

• Check OpenSSL with PQC extensions
• Configure hybrid groups
• Test connection setup and interoperability

# List available providers
openssl list -providers

# Example: point OpenSSL config so a PQC provider (e.g. oqsprovider) loads
export OPENSSL_CONF=/etc/ssl/openssl.cnf

# Then test hybrid groups and PQ-capable TLS configs in a test environment.

A minimal Python client for a first connection test might look like this:

import ssl
import socket

# Strong TLS context
context = ssl.create_default_context()
context.set_ciphers("TLS_AES_256_GCM_SHA384")

# Optional: enable hybrid group if available locally
# Note: syntax and availability depend heavily on the build
# context.set_ecdh_curve("X25519:MLKEM768")

with context.wrap_socket(socket.socket(), server_hostname="example.com") as conn:
    conn.connect(("server.example.com", 8443))
    conn.send(b"GET / HTTP/1.0\r\nHost: example.com\r\n\r\n")
    response = conn.recv(4096)
    print(response.decode(errors="ignore"))

What to test in PQC code

The value of PQC prototypes comes not from merely running the library but from targeted technical tests.

• API stability: how do libraries and parameter names change?
• Performance: CPU time, RAM, and latency?
• Handshake size: how much do keys, ciphertexts, and certificates grow?
• Error paths: what happens with unsupported groups or versions?
• Interoperability: do clients, servers, proxies, and load balancers work together?

PQC migration checklist for teams

Successful PQC migration does not start by swapping every algorithm at once but with a clean inventory and a controlled rollout plan. This checklist is for developers, architects, and infrastructure teams.

Migration flow (visual)

The typical order for a clean migration: gain visibility, prioritize risks, test hybrid schemes, then roll out in a controlled way.

What if you do nothing?

Skipping a PQC strategy means not only future cryptographic risk but also architectural and operational risk.

The most dangerous mistake is therefore not running classical schemes today, but deferring migration until it must be done under time pressure without clean architecture.

Conclusion and next steps for developers

Quantum computers are no longer an abstract future idea but a real planning factor for cryptography in modern systems. The real danger is not that every encryption breaks tomorrow, but that today’s assumptions for public-key schemes are not stable long-term.

Technically the difference is fundamental: Classical cryptography such as RSA and ECC rests on problems that are practically intractable for classical computers. Quantum algorithms such as Shor change that assumption. At the same time, post-quantum schemes such as ML-KEM and ML-DSA show that quantum-resistant alternatives on classical hardware are implementable today—with real trade-offs in key sizes, signature sizes, network overhead, and integration effort.

For developers and architects this means: The top priority is not an immediate rebuild of all systems but building crypto agility. Making algorithms swappable, testing hybrid schemes, managing the key lifecycle cleanly, and knowing critical data flows lays the groundwork for controlled PQC migration.

The most sensible next step is therefore clear:

• inventory existing cryptographic dependencies
• identify data that needs long-term protection
• build hybrid PQC prototypes in staging
• test performance, interoperability, and rollback paths

Starting these steps today reduces future risk and avoids the organization having to migrate later under extreme time pressure.

Sources and notes

Recommendations in this article follow public guidance from NIST, NSA/CNSA, BSI, IETF, and the Open Quantum Safe ecosystem.

License note: Code samples rely on open-source libraries (e.g. liboqs: MIT, CIRCL: BSD-3-Clause). Examples are simplified for illustration. Production use requires security reviews, HSM strategy, key lifecycle management, and regular updates.