Cryptography and the Quantum Problem: Why We Need Post-Quantum Cryptography

Post Header Header image by gabrielzschmitz, licensed under Creative Commons 4.0 Attribution license.

Cryptography is the cornerstone of modern digital security. From encrypted messaging to blockchain and secure web browsing, the invisible machinery of math keeps our data safe. But with the rise of quantum computing, the very foundation of today's encryption methods faces a serious threat.

Let's explore what cryptography is, how it works, and why quantum computers could break it — unless we prepare now.


What Is Cryptography?

Cryptography is the art of protecting information through mathematical transformations. It ensures that only the intended recipient can access a message's contents, even if others intercept it.

There are two major types of cryptography:

Cryptography underpins much more than hidden messages. It enables secure communications, digital signatures, and the backbone of technologies like blockchain, e-commerce, and VPNs.


A Classic Example: Caesar Cipher

One of the simplest and oldest encryption techniques is the Caesar cipher.

Each letter in a message is shifted by a fixed number of positions in the alphabet. For example, with a key k = 3:

$$\texttt{A} \rightarrow \texttt{D}, \quad \texttt{B} \rightarrow \texttt{E}, \quad \texttt{C} \rightarrow \texttt{F}, \quad \ldots$$

So the message ATTACK becomes DWWDFN.

Today, this cipher is trivially breakable — one only needs to try all 26 k possibilities. However, it still serves as a useful introduction to basic encryption concepts such as:

  • Cipher key, in this case k = 3;
  • Plaintext and ciphertext, ATTACK and DWWDFN respectively.

Diffie-Hellman

While the Caesar cipher illustrates the basics of encryption, it lacks the security needed for real-world communication. Modern systems require a way for two people to establish a shared secret key — even when communicating over an insecure channel.

This raises an important question:
How can two people agree on a secret if everyone can hear their conversation?

This is the problem that Diffie-Hellman key exchange solves. It allows two parties to create a shared secret, without ever sending the secret itself.

Historically, the Diffie-Hellman key exchange is credited to Whitfield Diffie and Martin Hellman, who published it in 1976. However, Ralph Merkle also contributed key ideas, and Diffie has since acknowledged him as a co-inventor.

But, to explain how this works, start with a simple analogy using colors.

  • Imagine Alice and Bob want to exchange a secret.
    • Alice chooses a secret color: red.
    • Bob chooses a different secret color: blue.
    • They agree on a public base color: gray.
  • Each mixes their secret color with the public one and sends the result:
    • Alice sends a mixture of red + gray
    • Bob sends a mixture of blue + gray
  • Then, each mixes the received color with their own secret:
    • Alice mixes (blue + gray) with red
    • Bob mixes (red + gray) with blue
  • The final result is the same shared color — a shared secret key — but anyone observing the exchanged colors can’t reconstruct it without knowing the secrets.
Diffie-Hellman as Colors Diffie-Hellman as Colors Scheme by gabrielzschmitz, licensed under Creative Commons 4.0 Attribution license.

Turning Colors into Numbers

We'll now translate the color analogy into mathematical operations — this is where the real magic of Diffie-Hellman happens.

In the previous example, Alice and Bob created a shared color without ever revealing their secret colors. The same principle can be achieved with numbers using modular arithmetic, which is like working on a circular number line — much like a clock.

For example:

$$10 + 5 \equiv 3 \pmod{12}$$

This “modulo” operator keeps values within a fixed range, which prevents attackers from deducing secrets even when partial information is shared.


How the Protocol Works

  1. Public parameters are agreed upon:

    • A base number g (generator)
    • A large prime number p (modulus)
  2. Alice and Bob choose private numbers:

    • Alice chooses a secret number a
    • Bob chooses a secret number b
  3. They generate public values using modular exponentiation:

$$A = g^a \pmod{p}$$

$$B = g^b \pmod{p}$$

  1. They exchange A and B over an open channel.

  2. They each compute the same secret key:

$$\text{Alice: } K = B^a \pmod p = g^{ba} \pmod p$$

$$\text{Bob: } K = A^b \pmod p = g^{ab} \pmod p$$

as:

$$g^{ab} = g^{ba}$$

Both parties arrive at the same shared key — just like the shared color in the metaphor — even though their private values remain hidden.


Security Through Discrete Logarithms

Now that we've seen how Alice and Bob generate a shared secret, let's explore why an attacker can't just reverse the process.

Even though the values g, p, A, and B are publicly visible, the attacker still doesn't know the private values a or b.

Why can't they just compute them?

Because doing so would require solving the discrete logarithm problem — finding a such that:

$$A = g^a \pmod{p}$$

This problem is computationally hard for large enough values of p. There's no efficient shortcut to reverse modular exponentiation without knowing the secret exponent. In fact:

  • For modern key sizes, it would take longer than the age of the universe using today's best classical algorithms.

"Or would it?"

This is the tipping point where classical security assumptions fall apart.

Enter quantum computing.


The Quantum Problem

Quantum Computer IBM Quantum System from Ehningen, Germany

Quantum computers can solve discrete logarithms exponentially faster than classical ones using Shor's Algorithm.

That means encryption schemes like RSA, Diffie-Hellman, and ECC — the bedrock of internet security — could be broken in minutes by a powerful quantum machine.

Large-scale quantum computers don't yet exist. But when they arrive, most of our current cryptographic infrastructure will become obsolete.


Why We Need Post-Quantum Cryptography

Post-Quantum Cryptography (PQC) is about building encryption systems that resist attacks from quantum computers.

Instead of relying on problems like factoring or discrete logs, PQC is based on:

  • Lattices
  • Hash-based constructions
  • Multivariate polynomials
  • Code-based systems

These problems remain hard even for quantum machines.

Institutions like NIST are already evaluating and standardizing PQC algorithms to ensure future-proof digital security.


Conclusion

Cryptography has come a long way — from Caesar’s ciphers to internet-scale encryption. But a new challenge looms: the quantum computer.

If we want to preserve privacy, trust, and security in the digital age, we must act now to transition to post-quantum cryptography.

The future isn't just encrypted. It's quantum-resistant.


Further Reading

  • Palomar College (2018) "Basic and Historical Cryptography" slide set. Introduces Caesar cipher as E(p,k) = (p + k) (mod 26). 📄 Slide Deck PDF

  • Whitfield Diffie & Martin E. Hellman (1976) "New Directions in Cryptography," IEEE Trans. Inf. Theory 22(6): 644–654. Seminal paper introducing public‐key cryptography and digital signatures. 📄 Read PDF from Stanford

  • Rivest, R. L., A. Shamir & L. Adleman (1978) "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Commun. ACM 21(2): 120–126. Introduces the RSA algorithm and shows how to enable secure communication without prior key sharing. 📄 Read PDF from MIT

  • Peter W. Shor (1994) "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer." Shows that a quantum computer can break RSA and Diffie–Hellman by factoring and computing discrete logs in polynomial time. 📄 Read on arXiv (quant-ph/9508027)

  • Leslie Lamport (1979) "Constructing Digital Signatures from a One-Way Function." First one-time signature scheme based on hash functions — a precursor to hash-based cryptography. 📄 SRI Technical Report (CSL-98)

  • Oded Regev (2005) "On Lattices, Learning with Errors, Random Linear Codes, and Cryptography," in Proc. 37th ACM STOC. Introduces the Learning With Errors (LWE) problem and a quantum-resistant public-key encryption scheme. 📄 Read PDF from STOC (2005)

  • Dam, D.-T. et al. (2023) "A Survey of Post-Quantum Cryptography: Start of a New Race," Cryptography 2023, 7(3): 40. An accessible and up-to-date survey of PQC approaches, NIST candidates, and research directions. 📄 Open-access MDPI paper


You can read the original blog post at: gabrielzschmitz.github.io

Hybrid PQC in Java: Common Pitfalls (Part 1)

OpenArt AI-Generated 'Pitfalls and holes in Cryptography using a dark theme', except for the java icon OpenArt AI-Generated "Pitfalls and holes in Cryptography using a dark theme", except for the java icon (Freepik - Flaticon).

As part of a collaboration project with CZERTAINLY, I've started a Java repository to experiment hybrid PQC. Together with Andrei and Danrlei (some of our hero's undergrad students!), we developed some examples of hybrid PQC using Bouncy Castle (1.77).

In this post, I'll explain some possible problems you might encounter, in particular if you are planning a transition to PQC with java, such as:

  • Design Architecture: how can I add hybrids in my Java application?
  • Performance: it can get 3-12x worse! (comparing PQ-only vs Hybrid, depending on some choices)

Let's start on how to develop a Hybrid KEM in Java using Bouncy Castle.

Design alternatives

Recently, KeyFactor announced FIPS 140-3 compliance for Bouncy Castle, which includes post-quantum algorithms. Looking at their docs, one can plan a migration as follows (considering KEMs):

  • Certified version of Bouncy Castle (docs here).
  • Or use non-FIPS KEMs (docs here).

Regardless of the version, the recommended approach is to use a traditional algorithm (such as ECDH) with a PQC one (e.g., Kyber) as follows:

  • Key Agreement (older systems): using "UserKeyingMaterialSpec" class to supply the PQC KEM secret or "DEROtherInfoClass".
  • Key Agreement (newer systems):"HybridValueParameterSpec", which uses a Two-step KDF (NIST.SP.800-56C).
  • Key Transport: "PQCSecretKeyProcessor". Documentation states that it combines traditional and PQC shared secrets using a XOR function.

Ok, all of this are in the docs, but if we look from an implementation perspective, there is much more to deal with. Theoretically, the migration can be represented as a flow in which we start from traditional cryptography towards PQC:

PQC Transition flow

We could generalize each step as a different approach to the same end, which is, a way to secure our data. With crypto agility in mind, a flexible but easy-to-switch API is desirable. In this case, the migration should not be hard to code. Consider the array sorting as a quick example. The sorting strategy (quick-sort, merge-sort, etc.) is something that a computer-science student would like to switch in order to compare performance.

So, how can I code such a easy-to-switch API? Well, there are some alternatives and in our repository we choose a pattern: Strategy.

Strategy is kind of a set of black-box methods; easy to switch between them. I know, there are cons to that, but if we want to do something like traditional -> hybrid -> PQ-only it means that there are three strategies to deal with. It's not that simple but this is the general idea that we select for our implementation.

One caveat to the Strategy pattern is that if your application is not using it maybe the refactor efforts may slow down your migration. Since hybrids can be used for a while (years, decades, forever? What if it is not Java anymore? Who knows...), maybe a pattern would not be necessary.

Anyway, our Strategy instance contains a KEM class, and a HybridKEM class, coded in a way that you can switch between them very easily, like this:

Instantiating a PQC KEM or a HybridKEM

Such a design also helps to minimize the number of required configurations (we can establish defaults after the benchmarks).

There is also a security concern that hybrid keys should not be used outside the "hybrid context" (to avoid downgrade attacks). This concern is more critical when talking about hybrid signatures (please refer to this talk). Our design is aligned to this idea, because the operations are performed inside the hybrid class, but obviously we are dependent on the interfaces that Bouncy Castle gives and how the methods are actually used.

After some initial benchmarks, we saw a performance bootleneck and that lead us to a second HybridKEM class: HybridKEMxECDH (which does not fit well in the strategy concept but we left "as-is" just for reference, or for an easy copy-and-paste example).

Now let's see some results.

Performance

We selected Kyber as PQC algorithm and NIST P-curves to do the benchmark. Our setup was configured without Turbo Boost (from here) and disabling other unnecessary services in a Linux system. Flag -n is used to generate a million iterations. The table below shows the result (considering 1M KeyGens, 1M Encaps, 1M Decaps):

Parameter
Set
Keygen/s
(PQ-only)
Keygen/s
(hybrid)
Hybrid
Penalty
Encaps/s
(PQ-only)
Encaps/s
(hybrid)
Hybrid
Penalty
Decaps/s
(PQ-only)
Decaps/s
(hybrid)
Hybrid
Penalty
Kyber 512 12777.75 4008.30 3.18x 12107.27 2394.96 5.05x 9730.27 2315.45 4.20x
Kyber 768 7895.65 1643.80 4.8x 8092.77 810.05 9.99x 6686.68 786.28 8.5x
Kyber 1024 5150.84 828.53 6.21x 5567.58 379.02 14.68x 4717.69 374.40 12.6x

By hybrid penalty I mean the slowdown when comparing PQ-only vs hybrid. The above table shows penalties from 3.18x to 12.6x. Ouch!

Literature shows that hybrid modes do not harm performance when considering algorithms at security level 1 (e.g., Kyber512), and reported some penalties when increasing security levels. Some examples here and here. However, our results are much worse from what I would expect for the hybrid mode. So what's wrong?

First I thought that something was wrong with the implementation, but after a quick profiling I saw this:

Profiling Kyber key generation (PQ-only and Hybrid)

AbstractECMultiplier class seems to be the bootleneck (comparing Key Generation). I could not simply fix it by changing software providers (SunEC provider was slower!). So if that performance is unacceptable, then we should change our hybrid ECC component. By changing it to x25519 and X448 (curves described in RFC 7748), the hybrid penalties were reduced significantly. See below:

Parameter
Set
Keygen/s
(PQ-only)
Keygen/s
(hybrid)
Hybrid
Penalty
Encaps/s
(PQ-only)
Encaps/s
(hybrid)
Hybrid
Penalty
Decaps/s
(PQ-only)
Decaps/s
(hybrid)
Hybrid
Penalty
Kyber 512 12839.11 4943.30 2.59x 12199.58 4028.76 3.02 9701.29 3771.96 2.57x
Kyber 768 7982.05 3973.29 2.0x 8102.80 3473.01 2.33x 6770.70 3193.44 2.12x
Kyber 1024 5188.92 1465.73 3.54x 5550.62 1245.92 4.45x 4715.06 1198.32 3.93x

As expected, such a change improved performance for the hybrid mode. One can also use the x25519 interface directly, perhaps the performance could be further improved that way. Therefore, x25519 is a better choice for the hybrid.

Some details are missing, such as the KDF instances that we use (but I don't think they would change the results). Also, we map x25519 with Kyber512 and Kyber768, because there is no level-3 equivalent (differently from NIST P-384). Nevertheless, it seems that Kyber768 with x25519 will be used as default: examples here and here.

In conclusion, there are some pitfalls in the choices for the algorithms and the design architecture when you migrate your java application. Hopefully this post might help you avoid some of them. For the next post, we'll see some performance results when using hybrid signatures. Thanks!

Group's First Anniversary

The "Grupo de Pesquisa Criptografia Pós-Quântica - UTFPR" was created in March, 2023. The primary goal is to gather people interested in studying concepts, applications and adoption strategies, focusing on the development and evaluation of Post-Quantum Cryptography (PQC). Other topics also belongs to the group's interest.

Being the group's coordinator, I would like to thank to the hero students that have been studying, attending meetings and starting research in order to achieve the group's primary goal.

After one year of activities, we have started partnerships* and collaborations that are (hopefully!) promising!

PS*: not necessarily related to PQC.

Obviously we are still at our "baby steps" stage. But we hope to contribute and we welcome new collaborations!