Introduction to Post-Quantum Cryptography: A Practical Guide

Post-Quantum Cryptography (PQC) is currently a hot topic. With the rapid advancements in quantum computing technology, concerns are growing that these powerful machines might one day be able to break many of the cryptographic protocols we consider secure today. Despite the urgency of this issue, finding a clear and practical entry point into PQC can be challenging.

In this blog, I aim to shed light on this complex subject and provide practical examples of how Post-Quantum Cryptography can be understood and implemented.

What to Expect in This Blog

1. Introduction to the Prominent PQC Candidates: Before diving into practical examples, I will describe not only the current situation regarding existing algorithms, I will also give you an overview of the most promising algorithms being considered in the NIST standardization process. You’ll get a brief introduction to how these algorithms work and the specific problems they aim to solve.
2. Open Quantum Safe Project: I will practically demonstrate how to install the correct version of OpenSSL, the liboqs library, and the OQS-OpenSSL provider. This setup is crucial for experimenting with and implementing post-quantum cryptographic algorithms.
3. Building a PQC Public Key Infrastructure (PKI): I will start by setting up a Post-Quantum PKI, which involves creating key pairs and certificates based on post-quantum secure algorithms.
4. Launching a PQC TLS Server: Next, I’ll demonstrate how to launch a TLS server that uses Post-Quantum Cryptography for TLS connections. This ensures secure communication channels that are resistant to quantum computer attacks.
5. „Store Now, Decrypt Later“: A key part of this blog will focus on protection against the threat of „Store Now, Decrypt Later“ attacks. I’ll show you how to use hybrid encryption techniques that combine classical and post-quantum algorithms to ensure your data remains secure even in the quantum era.

Introduction to the Prominent PQC Candidates

Why Do We Need Post-Quantum Cryptography?

Quantum computers leverage the principles of quantum mechanics to perform calculations that are practically impossible for classical computers. Specifically, two quantum algorithms, Shor’s Algorithm and Grover’s Algorithm, pose significant threats to current cryptographic practices:

• Shor’s Algorithm (asymmetric): Efficiently factors large numbers and solves discrete logarithms. This means that algorithms like RSA and ECC, which are based on the difficulty of these mathematical problems, could be easily broken in the quantum world.
• Grover’s Algorithm (symmetric): Provides a quadratic speedup for searching keys in symmetric encryption schemes. While this does not entirely undermine the security of algorithms like AES, it necessitates doubling the key length to maintain the same level of security.

Scenarios Where Asymmetric Encryption is Predominantly Used Today

1. Digital Signatures:
   • Usage: Digital signatures are used to ensure the authenticity and integrity of messages, documents, and software. A digital certificate verifies that a message or document indeed originates from the stated sender and has not been tampered with.
   • Examples: SSL/TLS certificates for secure websites, email signatures (e.g., PGP/GPG), software and code signing (e.g., for distributing software updates).
2. Hybrid Encryption:
   • Usage: In hybrid encryption, asymmetric encryption is used to securely exchange a symmetric session key. This symmetric key is then used for the actual data transmission because symmetric encryption is significantly faster.
   • Examples: TLS (Transport Layer Security) uses asymmetric encryption to negotiate the session key, which is then used to encrypt the data transmission. Email encryption systems like S/MIME also employ this technique.
3. Key Exchange Protocols:
   • Usage: Key exchange protocols allow two parties to securely negotiate a shared secret key over an insecure network. This key can then be used for symmetric encryption.
   • Examples: The Diffie-Hellman key exchange protocol (often used in combination with TLS), Elliptic Curve Diffie-Hellman (ECDH) for faster and more secure key agreement, and VPN connections (e.g., IPsec) use key exchange protocols to establish secure tunnels.

As we find ourselves in 2024, the cryptographic community is looking forward to the upcoming standardization of three critical Federal Information Processing Standards (FIPS) by the National Institute of Standards and Technology (NIST). These drafts, FIPS 203, FIPS 204, and FIPS 205, represent the forefront of post-quantum cryptography, setting the stage for a secure digital future in the era of quantum computing. Here, we focus on their application in Public Key Infrastructure (PKI) and Transport Layer Security (TLS).

1) FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)

Old Name: CRYSTALS-Kyber

Overview: FIPS 203 establishes the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), which originates from the CRYSTALS-Kyber algorithm. ML-KEM is designed to facilitate secure key exchange over public channels, leveraging the complexity of the Module Learning with Errors (MLWE) problem to withstand quantum attacks.

Applications in PKI and TLS:

• PKI: ML-KEM can be integrated into the Public Key Infrastructure to enhance the security of key exchanges. In PKI, ML-KEM can be used to securely distribute and manage cryptographic keys, ensuring that even if quantum computers become powerful enough to break current encryption methods, the keys exchanged using ML-KEM will remain secure.
• TLS: In Transport Layer Security, ML-KEM can replace traditional key exchange algorithms like RSA or Diffie-Hellman. This ensures that the process of establishing a secure communication channel over the internet is resistant to quantum attacks, safeguarding the confidentiality and integrity of data exchanged between clients and servers.

2) FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)

Old Name: CRYSTALS-Dilithium

Overview: FIPS 204 defines the Module-Lattice-Based Digital Signature Standard (ML-DSA), based on the CRYSTALS-Dilithium algorithm. ML-DSA provides robust digital signatures that ensure the authenticity and integrity of messages and documents, relying on the structured lattice problem of MLWE.

Applications in PKI and TLS:

• PKI: Digital signatures are a cornerstone of PKI, used to verify identities and authenticate messages. ML-DSA can be implemented to create quantum-resistant digital certificates, ensuring that the authentication and non-repudiation services provided by PKI are secure against quantum threats.
• TLS: In TLS, digital signatures are used during the handshake process to authenticate the server (and optionally the client) to each other. By employing ML-DSA, TLS can ensure that these authentication steps are quantum-secure, preventing quantum attackers from impersonating legitimate entities or tampering with communications.

3) FIPS 205: Stateless Hash-Based Digital Signature Standard

Old Name: SPHINCS+

Overview: FIPS 205 introduces a stateless hash-based digital signature standard, derived from the SPHINCS+ algorithm. This standard uses hash-based techniques to create secure digital signatures without relying on state information, enhancing protection against certain types of attacks.

Applications in PKI and TLS:

• PKI: Stateless hash-based signatures can be used to create digital certificates within PKI, providing an additional layer of security by ensuring that signatures cannot be forged or tampered with, even by quantum-capable adversaries. This is especially useful for long-term validation and archival purposes.
• TLS: In the context of TLS, stateless hash-based signatures can be utilized to authenticate the entities involved in the communication process. This guarantees that the authenticity of the certificates used in the TLS handshake remains intact, even in the presence of quantum computing threats.

The Open Quantum Safe Project

https://openquantumsafe.org

The Open Quantum Safe (OQS) project is an open-source initiative aimed at developing and integrating quantum-resistant cryptographic algorithms into existing security protocols. In this guide, I will use liboqs and OQSProvider to build a post-quantum cryptography Public Key Infrastructure (PKI) and subsequently establish a post-quantum secure TLS 1.3 connection.

liboqs

liboqs is the core library providing a collection of post-quantum cryptographic algorithms standardized by NIST. It supports both key encapsulation mechanisms (KEMs) and digital signatures, optimized for performance and security.

OQSProvider

OQSProvider integrates liboqs into the OpenSSL 3.0 provider framework, enabling dynamic loading of post-quantum algorithms without modifying the core OpenSSL codebase. This ensures flexibility and future-proofing for applications.

Setup the environment

First we need to install the latest version of OpenSSL fully supporting the OQSProvider – OpenSSL 3.3

git clone https://github.com/openssl/openssl.git
cd openssl
git tag
git checkout openssl-3.3.1

make
sudo make install

export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH

Afterwards we need to download the latest liboqs sources from the respective git repository and compile

sudo apt install astyle cmake gcc ninja-build libssl-dev python3-pytest python3-pytest-xdist unzip xsltproc doxygen graphviz python3-yaml valgrind
git clone -b main https://github.com/open-quantum-safe/liboqs.git
cd liboqs

mkdir build && cd build
cmake -GNinja .. -DBUILD_SHARED_LIBS=ON
ninja
sudo ninja install

The next step is to download and compile the OQSProvider which brings Post Quantum Cryptography to OpenSSL

git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -S . -B _build && cmake --build _build && ctest --test-dir _build && cmake --install _build

We need to make a few adjustments in the openssl.conf in order to activate the OQSProvider

sudo nano /etc/ssl/openssl.conf

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[oqsprovider_sect]
activate = 1

[default_sect]
activate = 1

Finally we set the correct environment variables and export them to be pre-set with the next logins

sudo echo "export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH" >> ~/.bashrc
sudo echo "export OPENSSL_MODULES=~/oqs-provider/_build/lib" >> ~/.bashrc
source ~/.bashrc

openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.3.1
    status: active
  oqsprovider
    name: OpenSSL OQS Provider
    version: 0.6.2-dev
    status: active

Check whether CRYSTALS-Kyber is available -> Key Encapsulation Method

openssl list -kem-algorithms | grep '^  kyber*'
  kyber512 @ oqsprovider
  kyber768 @ oqsprovider
  kyber1024 @ oqsprovider

Check whether CRYSTALS-Dilithium is available -> Digital Signature

openssl list -signature-algorithms | grep '^  dilithium*'
  dilithium2 @ oqsprovider
  dilithium3 @ oqsprovider
  dilithium5 @ oqsprovider

Check whether SPHINCS+ is available -> Digital Signature

openssl list -signature-algorithms | grep '^  sphincssha2'
  sphincssha2128fsimple @ oqsprovider
  sphincssha2128ssimple @ oqsprovider
  sphincssha2192fsimple @ oqsprovider

Building a PQC Public Key Infrastructure (PKI)

The theoretical part is now covered, and we have gained an understanding of the necessity and various approaches in post-quantum cryptography. We have captured the essential information and set up an environment to operate quantum-secure cryptography. Now, the exciting part begins: it’s time to see post-quantum cryptography in action.

First, we will establish a Post-Quantum Public Key Infrastructure (PKI) to ensure the security of our digital communications in a world with quantum computers. Our approach involves implementing different security levels of the Dilithium algorithm family within our PKI.

1. Root CA: We will start by setting up a Root Certificate Authority (CA) named CypherWiseRootCA, signed with Dilithium5. This highest security level provides a solid foundation for the entire PKI.
2. Sub CA: Next, we will set up a Sub CA named CypherWiseSubCA, signed with Dilithium3. This CA will be certified by CypherWiseRootCA and will be responsible for issuing certificates for various endpoints.
3. TLS Server Certificate: We will issue a TLS server certificate named CypherWiseServer, ensuring the secure communication of our server.
4. TLS Client Certificate: Additionally, we will issue a TLS client certificate named CypherWiseClient to authenticate clients in our system.

After setting up the PKI, we will establish a TLS 1.3 connection protected with Kyber 768. Kyber will ensure a secure key exchange for the symmetric AES encryption key, providing robust post-quantum security for our communications.

Currently, there are no web browsers that support mTLS authentication based on PQC algorithms. Therefore, the TLS 1.3 handshake will be simulated using OpenSSL.

In the subsequent demonstration, we will delve deeper into how the hybrid approach works and why it is advisable to start transitioning to it today. This approach leverages the strengths of both classical and quantum-resistant algorithms, ensuring maximum security as we move towards a future where quantum computers become more prevalent.

Creating a self-signed RootCA utilizing Dilithium5

openssl genpkey -algorithm dilithium5 -out cypherwise_root_ca.key
openssl req -x509 -new -key cypherwise_root_ca.key -out cypherwise_root_ca.crt -days 3650 -subj "/CN=CypherWiseRootCA"

Create a SubCa certificate signed by the CypherWiseRootCa utilizing Dilithium3

openssl genpkey -algorithm dilithium3 -out cypherwise_sub_ca.key
openssl req -new -key cypherwise_sub_ca.key -out cypherwise_sub_ca.csr -subj "/CN=CypherWiseSubCA"

cat > sub_ca_ext.cnf <<EOL
[ v3_ca ]
basicConstraints = CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
EOL

openssl x509 -req -in cypherwise_sub_ca.csr -out cypherwise_sub_ca.crt -CA cypherwise_root_ca.crt -CAkey cypherwise_root_ca.key -CAcreateserial -days 365 -extfile sub_ca_ext.cnf -extensions v3_ca

Create a server certificate signed by the SubCA utilizing Dilithium2

openssl genpkey -algorithm dilithium2 -out cypherwise_server.key
openssl req -new -key cypherwise_server.key -out cypherwise_server.csr -subj "/CN=CypherWiseServer"

cat > client_ext.cnf <<EOL
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOL


openssl x509 -req -in cypherwise_server.csr -out cypherwise_server.crt -CA cypherwise_sub_ca.crt -CAkey cypherwise_sub_ca.key -CAcreateserial -days 365 -extfile server_ext.cnf -extensions v3_req

Create a client certificate signed by the SubCa utilizing Dilithium2

openssl genpkey -algorithm dilithium2 -out cypherwise_client.key
openssl req -new -key cypherwise_client.key -out cypherwise_client.csr -subj "/CN=CypherWiseClient"

cat > client_ext.cnf <<EOL
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOL

openssl x509 -req -in cypherwise_client.csr -out cypherwise_client.crt -CA cypherwise_sub_ca.crt -CAkey cypherwise_sub_ca.key -CAcreateserial -days 365 -extfile client_ext.cnf -extensions v3_req

Launching a PQC TLS1.3 Server

Starting the Quantum Safe TLS1.3 Server with mTLS and Kyber768 protecting the key agreement

openssl s_server -cert cypherwise_server.crt -key cypherwise_server.key -CAfile cypherwise_sub_ca.crt -verifyCAfile cypherwise_root_ca.crt -accept 4433 -tls1_3 -groups kyber768 -Verify 2

Starting the Quantum Safe TLS1.3 Client with mTLS

openssl s_client -connect localhost:4433 -servername localhost -cert cypherwise_client.crt -key cypherwise_client.key -CAfile cypherwise_sub_ca.crt -verifyCAfile cypherwise_root_ca.crt -tls1_3 -groups kyber768

Server-side logs

According to the start parameter, the „-groups kyber768“ configures the server to support kyber768 as key exchange mechanism only.

Client-side logs

Although Kyber768 is not mentioned by name here, a key exchange using Kyber768 did take place. This is because the server did not allow any other key exchange methods, and yet the connection was successfully established. It is also evident that a complete mTLS authentication with the PQC algorithms Dilithium5, Dilithium3, and Dilithium2 was conducted.

„Store Now, Decrypt Later“ Attack: A Detailed Explanation

The concept of „store now, decrypt later“ is a potential threat in the context of quantum computing. This scenario involves adversaries intercepting and storing encrypted data today with the expectation that they will be able to decrypt it in the future when quantum computers are powerful enough to break the encryption.

Example: A TLS Web Server Session

Consider a typical TLS 1.3 web server session secured with the secp256r1 elliptic curve and the x25519 key exchange mechanism. Here is how a „store now, decrypt later“ attack could unfold:

1. Data Interception:
   • An attacker intercepts the encrypted traffic between a client and a web server.
   • The traffic includes the initial handshake, encrypted messages, and the ephemeral keys used for the session.
2. Data Storage:
   • The attacker stores all intercepted data, including the handshake messages and the encrypted payload.
   • This data is stored with the intention of decrypting it in the future when quantum computing resources become available.

Key Exchange Using x25519

The x25519 key exchange mechanism is based on the Diffie-Hellman key exchange using elliptic curve cryptography. While x25519 is currently considered secure against classical attacks, it is vulnerable to quantum attacks for the following reasons:

• Quantum Vulnerability:
  • Quantum computers can use Shor’s algorithm to solve the discrete logarithm problem, which is the mathematical foundation of the x25519 key exchange.
  • This means that once quantum computers are sufficiently advanced, they could potentially derive the private keys used in the x25519 key exchange from the public keys exchanged during the TLS handshake.

Ephemeral Keys and Their Limitations

TLS 1.3 uses ephemeral keys (short-lived keys) for key exchanges to provide forward secrecy. Forward secrecy ensures that even if a private key is compromised in the future, past communications cannot be decrypted. However, in the context of quantum computing, ephemeral keys do not provide sufficient protection:

• Ephemeral Key Vulnerability:
  • Ephemeral keys are secure against classical attacks but not against quantum attacks.
  • If an attacker intercepts and stores the public keys exchanged during the TLS handshake, a future quantum computer could potentially use these stored public keys to derive the ephemeral private keys.
  • Once the ephemeral private keys are known, the session keys can be derived, and the entire communication can be decrypted.

Protection Against „Store Now, Decrypt Later“ Attacks

Many major technology providers, such as web browser developers (e.g., Google Chrome) and web server and hosting services (e.g., Cloudflare), have not yet fully integrated post-quantum cryptography into their products. This cautious approach is due to several factors:

Ongoing Development and Testing: The draft status of FIPS 203, FIPS 204, and FIPS 205 means that the algorithms and implementations are still being refined. Major technology providers are waiting for these standards to be finalized to avoid integrating solutions that might change significantly.

1. Beta Implementations: Some companies have started to implement post-quantum cryptography in beta versions of their products. These beta implementations are used to gather feedback and test the practicality and performance of the new algorithms. However, they are not yet ready for widespread deployment.
2. Risk of Early Adoption: Adopting a standard that is not yet finalized carries risks. Changes to the standards could require significant updates or overhauls of existing implementations. Therefore, many companies are adopting a wait-and-see approach, closely monitoring the development of these standards before committing to full integration.

Hybrid Cryptography: A Bridge to the Future

Given the draft status of FIPS 203, FIPS 204, and FIPS 205, many organizations are exploring hybrid cryptography as a transitional solution. Hybrid cryptography combines traditional, well-established cryptographic algorithms with new post-quantum algorithms. This approach helps mitigate the risk of future quantum attacks while leveraging the proven security of current cryptographic methods.

Hybrid cryptography is particularly effective in addressing the threat of „store now, decrypt later“ attacks. In these attacks, adversaries store encrypted data now with the intention of decrypting it once quantum computers become available and capable of breaking current encryption standards. By using a combination of classical and post-quantum cryptography, organizations can ensure that even if one algorithm is compromised in the future, the other remains secure, thus protecting the data from being decrypted later.

Why Combining Proven Algorithms with PQC Makes Sense

1. Enhanced Security: Combining a well-established cryptographic algorithm with a new PQC algorithm provides an added layer of security. If a quantum computer breaks the classical algorithm, the post-quantum algorithm still protects the data and vice versa.
2. Incremental Transition: Hybrid cryptography allows for a gradual transition to post-quantum security. Organizations can start implementing PQC algorithms alongside their current systems without a complete overhaul.
3. Risk Mitigation: Since PQC algorithms are still in the testing phase and subject to change, using them in conjunction with proven algorithms reduces the risk associated with relying solely on untested methods.
4. Interoperability: Using hybrid cryptography ensures compatibility with existing systems while preparing for future quantum threats. It allows for a smoother integration process and maintains the reliability of current communications.

Post-Quantum Cryptography for Superhero Communication – Practical Example

Captain America and Iron Man have decided to secure their communications with a hybrid technology, combining Kyber768 and x25519. This approach ensures robust protection against future quantum attacks while leveraging the proven security of current cryptographic methods. By integrating both algorithms, they safeguard their vital messages today and future-proof their exchanges against emerging threats.

from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.backends import default_backend
from oqs import KeyEncapsulation
from binascii import hexlify

#TonyStark
#Generate x25519 KeyPair
TonyStark_private_x25519_key = X25519PrivateKey.generate()
TonyStark_public_x25519_key = TonyStark_private_x25519_key.public_key()

#CptAmerica
#Generate x25519 KeyPair
CptAmerica_private_x25519_key = X25519PrivateKey.generate()
CptAmerica_public_x25519_key = CptAmerica_private_x25519_key.public_key()

#TonyStark
#Generate Shared Secret
shared_key = TonyStark_private_x25519_key.exchange(CptAmerica_public_x25519_key)
TonyStarks_shared_secret = HKDF(algorithm=hashes.SHA256(), length=32,salt=None,info=None).derive(shared_key)

#CptAmerica
#Generate Shared Secret
shared_key = CptAmerica_private_x25519_key.exchange(TonyStark_public_x25519_key)
CptAmericas_shared_secret = HKDF(algorithm=hashes.SHA256(), length=32,salt=None,info=None).derive(shared_key)

#TonyStark
#Generate Kyber768 KeyPair
TonyStarks_kem = KeyEncapsulation("Kyber768")
TonyStarks_public_KEM_key= TonyStarks_kem.generate_keypair()
TonyStarks_private_KEM_key = TonyStarks_kem.export_secret_key()

#CptAmerica
#Generate Kyber768 KeyPair
CptAmericas_kem = KeyEncapsulation("Kyber768")
CptAmericas_public_KEM_key= CptAmericas_kem.generate_keypair()
CptAmericas_private_KEM_key = CptAmericas_kem.export_secret_key()

#TonyStark
#Generate Shared Secret and send it encrypted to CptAmerica
TonyStarks_ciphertext, TonyStarks_shared_KEM_secret = TonyStarks_kem.encap_secret(CptAmericas_public_KEM_key)

#CptAmerica
#Generate Shared Secret by decrypting TonyStarks_ciphertext
CptAmericas_shared_KEM_secret = CptAmericas_kem.decap_secret(TonyStarks_ciphertext)

print(f"TonyStark's X25519 session key: {hexlify(TonyStarks_shared_secret).decode()} with a size of {len(hexlify(TonyStarks_shared_secret))*4} bits")
print(f"CptAmerica's X25519 session key: {hexlify(CptAmericas_shared_secret).decode()} with a size of {len(hexlify(CptAmericas_shared_secret))*4} bits")
print(f"TonyStarks's Kyber768 session key: {hexlify(TonyStarks_shared_KEM_secret).decode()} with a size of {len(hexlify(TonyStarks_shared_KEM_secret))*4} bits")
print(f"CptAmericas's Kyber768 session key: {hexlify(CptAmericas_shared_KEM_secret).decode()} with a size of {len(hexlify(CptAmericas_shared_KEM_secret))*4} bits")

#Concatenate both shared secrets Hybrid key exchange in TLS 1.3 draft-ietf-tls-hybrid-design-10 and SHA256
digest = hashes.Hash(hashes.SHA256(), default_backend())
digest.update(CptAmericas_shared_secret + CptAmericas_shared_KEM_secret)
hash_value = digest.finalize()

print(f"Thy hybrid X25519 || Kyber768 shared secret: {hexlify(hash_value).decode()} with a size of {len(hexlify(hash_value))*4} bits")

TonyStark's X25519 session key: e7ab89369868c9bfa6019affcf328a341a4fbab92947044304e771aefe14af17 with a size of 256 bits
CptAmerica's X25519 session key: e7ab89369868c9bfa6019affcf328a341a4fbab92947044304e771aefe14af17 with a size of 256 bits
TonyStarks's Kyber768 session key: c4fbfa4e2cb229d49d4f8964b2357a9094cd351d1e231a5c254a4d596f501284 with a size of 256 bits
CptAmericas's Kyber768 session key: c4fbfa4e2cb229d49d4f8964b2357a9094cd351d1e231a5c254a4d596f501284 with a size of 256 bits
Thy hybrid X25519 || Kyber768 shared secret: c2935bb42cdeb76b7acff092f5a61368ab220dd0d724619898f76bd2ce067888 with a size of 256 bits

The script demonstrates the creation of a hybrid key exchange using two different cryptographic algorithms: X25519 and Kyber768. The purpose of this combination is to ensure the security of the shared secret against both classical and quantum computer-based attacks.

Basic Workflow

1. Generation of X25519 Key Pairs:
   • TonyStark and CptAmerica each generate an X25519 key pair.
   • Public keys are exchanged.
2. Deriving the Shared X25519 Secret:
   • Both parties compute a shared secret using their own private key and the public key of the other party.
   • This shared secret is processed with HKDF and SHA-256 to derive a 32-byte session key.
3. Generation of Kyber768 Key Pairs:
   • TonyStark and CptAmerica each generate a Kyber768 key pair.
   • Public keys are exchanged.
4. Deriving the Shared Kyber768 Secret:
   • TonyStark encrypts a random message (encapsulated secret) with CptAmerica’s public Kyber768 key.
   • CptAmerica decrypts this message to obtain the shared secret.

Combining the Secrets

Both parties now have two shared secrets:

• X25519-based secret: Secure against classical attacks.
• Kyber768-based secret: Secure against quantum computer attacks.

These secrets are combined to form a final shared secret. In this example, the combined secret is processed using a SHA-256 hash function. This combination ensures that the final shared secret is protected against the strongest known attacks.

Security and Benefits

• Resilience to Quantum Computers: Kyber768 is a post-quantum cryptographic algorithm resistant to quantum computer attacks, ensuring the system remains secure even if quantum computers become capable of breaking classical cryptography.
• Combining Security Properties: By combining X25519 (classical) and Kyber768 (post-quantum), the system maximizes its security. If one algorithm is compromised, the other still provides protection.
• Encryption and Authentication: The final shared secret can be used to derive session keys for symmetric encryption and message authentication, ensuring confidentiality and authenticity of communication.

And if you think this is all just science-fiction:

Try it out!