Post-Quantum Cryptography: Building Resilience Against Tomorrow’s Threats

Modern cryptographic systems such as RSA, ECC (Elliptic Curve Cryptography), and DH (Diffie-Hellman) rely heavily on the mathematical difficulty of certain problems, like factoring large integers or computing discrete logarithms. However, with the rise of quantum computing, algorithms like Shor's and Grover's threaten to break these systems, rendering them insecure.

Quantum computers are not yet at the scale required to break these encryption methods in practice, but their rapid development has pushed the cryptographic community to act now. This is where Post-Quantum Cryptography (PQC) comes in — a new wave of algorithms designed to remain secure against both classical and quantum attacks.

Why PQC Matters

Quantum computers exploit quantum mechanics principles like superposition and entanglement to perform calculations that would take classical computers millennia2. This threatens:

• Public-key cryptography: Algorithms like RSA rely on factoring large primes or solving discrete logarithms-problems quantum computers could crack using Shor’s algorithm.
• Long-term data security: Attackers may already be harvesting encrypted data to decrypt later ("harvest now, decrypt later") once quantum computers mature.

Figure1: Cryptography evolution

 

How PQC Works

The National Institute of Standards and Technology (NIST) has led a multi-year standardization effort. Here are the main algorithm families and notable examples.

Lattice-Based Cryptography. 

Lattice problems are believed to be hard for quantum computers. Most of the leading candidates come from this category.

• CRYSTALS-Kyber (Key Encapsulation Mechanism)
• CRYSTALS-Dilithium (Digital Signatures)

Uses complex geometric structures (lattices) where finding the shortest vector is computationally hard, even for quantum computers

Example: ML-KEM (formerly Kyber) establishes encryption keys using lattices but requires more data transfer (2,272 bytes vs. 64 bytes for elliptic curves)

The below figure shows an illustration of how Lattice-based cryptography works. Imagine solving a maze with two maps-one public (twisted paths) and one private (shortest route). Only the private map holder can navigate efficiently

Code-Based Cryptography

Based on the difficulty of decoding random linear codes.

• Classic McEliece: Resistant to quantum attacks for decades.
• Pros: Very well-studied and conservative. Cons: Very large public key sizes.

Relies on error-correcting codes. The Classic McEliece scheme hides messages by adding intentional errors only the recipient can fix.

How it works:

1. Key generation: Create a parity-check matrix (public key) and a secret decoder (private key).
2. Encryption: Encode a message with random errors.
3. Decryption: Use the private key to correct errors and recover the message

Figure3: Code-Based Cryptography Illustration

Multivariate & Hash-Based Quadratic Equations

Multivariate

These are based on solving systems of multivariate quadratic equations over finite fields and relies on solving systems of multivariate equations, a problem believed to be quantum-resistant. 

Hash-Based

Use hash functions to construct secure digital signatures.

• SPHINCS+: Stateless and hash-based, good for long-term digital signature security.

 

Challenges and Adoption

• Integration: PQC must work within existing TLS, VPN, and hardware stacks.
• Key sizes: PQC algorithms often require larger keys. For example, Classic McEliece public keys can exceed 1MB.
• Hybrid Schemes: Combining classical and post-quantum methods for gradual adoption.
• Performance: Lattice-based methods are fast but increase bandwidth usage.
• Standardization: NIST has finalized three PQC standards (e.g., ML-KEM) and is testing others. Organizations must start migrating now, as transitions can take decades.

 

Adopting PQC with BIG-IP

As of F5 BIG-IP 17.5, the BIG-IP now supports the widely implemented X25519Kyber768Draft00 cipher group for client-side TLS negotiations (BIG-IP as a TLS server). Other cipher groups and capabilities will become available in subsequent releases.

Cipher walkthrough 

Let's take the supported cipher in v17.5.0 (Hybrid X25519_Kyber768) as an example and walk through it. 

• X25519: A classical elliptic-curve Diffie-Hellman (ECDH) algorithm
• Kyber768: A post-quantum Key Encapsulation Mechanism (KEM)

The goal is to securely establish a shared secret key between the two parties using both classical and quantum-resistant cryptography.

Key Exchange

X25519 Exchange:

• Alice and Bob exchange X25519 public keys.
• Each computes a shared secret using their own private key + the other’s public key:

Kyber768 Exchange:

• Alice uses Bob’s Kyber768 public key to encapsulate a secret:
  • Produces a ciphertext and a shared secret
• Bob uses his Kyber768 private key to decapsulate the ciphertext and recover the same shared secret:

Both parties now have:

• A classical shared secret
• A post-quantum shared secret

They combine them using a KDF (Key Derivation Function):

Why the hybrid approach is being followed: 

• If quantum computers are not practical yet, X25519 provides strong classical security.
• If a quantum computer arrives, Kyber768 keeps communications secure.
• Helps organizations migrate gradually from classical to post-quantum systems.

Implementation guide

F5 published article Enabling Post-Quantum Cryptography in F5 BIG-IP TMOS to implement PQC on BIG-IP v17.5

Create a new Cipher Rule

1. To create a new Cipher Rule, log in to the BIG-IP Configuration Utility, go to Local Traffic > Ciphers > Rules.
2. Select Create.
3. In the Name box, provide a name for the Cipher Rule.
4. For Cipher Suits, select any of the suites from the provided Cipher Suites list. Use ALL or DEFAULT to list all of the available suites.
5. For DH Groups, enter X25519KYBER768 to restrict to only this PQC cipher
   For Example:
   X25519KYBER768
6. For Signature Algorithms, select an algorithm.
   For example:
   DEFAULT
7. Select Finished.

Create a new Cipher Group

1. In the BIG-IP Configuration Utility, go to Local Traffic > Ciphers > Groups
2. Select Create.
3. In the Name box, provide a name for the Cipher Group.
4. Add the newly created Cipher Rule to Allow the following box or Restrict the Allowed list to the following in Group Details.
5. All of the other details, including DH Group, Signature Algorithms, and Cipher Suites, will be reflected in the Group Audit as per the selected rule.
6. Select Finished.

Configure a Client SSL Profile

1. In the BIG-IP Configuration Utility, go to Local Traffic > Profiles > SSL > Client.
2. Create a new client SSL profile or edit an existing.
3. For Ciphers, select the Cipher Group radio button and select the created group to enable Post-Quantum cryptography for this client’s SSL profile.

 

NGINX Support for PQC

We are pleased to announce support for Post Quantum Cryptography (PQC) starting NGINX Plus R33. 

NGINX provides PQC support using the Open Quantum Safe provider library for OpenSSL 3.x (oqs-provider). This library is available from the  Open Quantum Safe (OQS) project. The oqs-provider library adds support for all post-quantum algorithms supported by the OQS project into network protocols like TLS in OpenSSL-3 reliant applications. All ciphers/algorithms provided by oqs-provider are supported by NGINX. 

To configure NGINX with PQC support using oqs-provider, follow these steps:

• Install the necessary dependencies

sudo apt update 
sudo apt install -y build-essential git cmake ninja-build libssl-dev pkg-config

 

• Download and install liboqs

git clone --branch main https://github.com/open-quantum-safe/liboqs.git 
cd liboqs 
mkdir build && cd build 
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON .. 
ninja 
sudo ninja install

 

• Download and install oqs-provider

git clone --branch main https://github.com/open-quantum-safe/oqs-provider.git 
cd oqs-provider mkdir build && cd build 
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl .. 
make -j$(nproc) 
sudo make install

 

• Download and install OpenSSL with oqs-provider support

git clone https://github.com/openssl/openssl.git 
cd openssl ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl linux-x86_64 
make -j$(nproc) 
sudo make install_sw

 

• Configure OpenSSL for oqs-provider

/usr/local/ssl/openssl.cnf: 
openssl_conf = openssl_init 

[openssl_init] 
providers = provider_sect 

[provider_sect] 
default = default_sect 
oqsprovider = oqsprovider_sect 

[default_sect] 
activate = 1 

[oqsprovider_sect] 
activate = 1

 

• Generate post quantum certificates

export OPENSSL_CONF=/usr/local/ssl/openssl.cnf

# Generate CA key and certificate
/usr/local/ssl/bin/openssl req -x509 -new -newkey dilithium3 -keyout ca.key -out ca.crt -nodes -subj "/CN=Post-Quantum CA" -days 365
# Generate server key and certificate signing request (CSR)
/usr/local/ssl/bin/openssl req -new -newkey dilithium3 -keyout server.key -out server.csr -nodes -subj "/CN=your.domain.com"
# Sign the server certificate with the CA
/usr/local/ssl/bin/openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365

 

• Download and install NGINX Plus

 

• Configure NGINX to use the post quantum certificates

server {

        listen       0.0.0.0:443 ssl;
        ssl_certificate      /path/to/server.crt;
        ssl_certificate_key  /path/to/server.key;
        ssl_protocols TLSv1.3;
        ssl_ecdh_curve kyber768;

        location / {
            return 200 "$ssl_curve $ssl_curves";
        }
    }

 

Conclusion

By adopting PQC, we can future-proof encryption against quantum threats while balancing security and practicality. While technical hurdles remain, collaborative efforts between researchers, engineers, and policymakers are accelerating the transition.

 

Related Content

• New Features in BIG-IP Version 17.5.0 
• K000149577: Enabling Post-Quantum Cryptography in F5 BIG-IP TMOS 
• F5 NGINX Plus R33 Release Now Available | DevCentral