A Post-Quantum Future for Let's Encrypt • Hacker News Board

Re: A Post-Quantum Future for Let's Encrypt

#51

Post by mswphd » Wed, Jun 03, 2026, 6:27 PM UTC

tialaramex wrote: post #48

skmurphy wrote: post #34

We are truly living in a science fiction future where quantum code cracking is not a remote possibility but a near term risk we are planning for. In Vernor Vinge's novel "A Fire Upon the Deep" one of the most valuable commodities were one time pads that are physically transported to communication nodes to enable unbreakable communication. The pads are split into three pieces that are XORed to create the actual pad to…

But that's a miss, it's like one of those Neal Stephenson moments where the creator is using the right language (so it's not like reading William Gibson who clearly has no idea and knows it - he's going for the emotional feel not the technology) but they don't understand what's actually going on. OTP is in theory the correct choice if you don't have working symmetric cryptography but in fact the "Quantum computer" ap…

It's worth noting that the above assumes that grover's is optimal for symmetric crypto. There are not that many quantum attacks against symmetric crypto that are better than grover's, so in some sense this is justified. But there are some attacks for particular constructions

https://arxiv.org/pdf/2110.02836

So there is a risk that there are even more improved attacks that people aren't looking for due to the conventional wisdom that grover's is the best you can do for symmetric crypto. Hopefully this risk doesn't end up materializing.

Re: A Post-Quantum Future for Let's Encrypt

#52

Post by some_furry » Wed, Jun 03, 2026, 6:34 PM UTC

saltcured wrote: post #41

some_furry wrote: post #30

Earlier quoted context omitted.

The thing is: Quantum computers don't break AES-GCM, ChaCha20-Poly1305, or any other modern authenticated cipher. Layering encryption or doing cipher cascades is pointless. The thing a cryptography-relevant quantum computer does is break RSA and elliptic curve cryptography, so that the underlying key (k1 or k2) is recoverable from its corresponding public component. Hybrid KEMs, such as mlkem768x25519 (a.k.a. X-Wing)…

Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs? The change of jargon from "encryption" to "KEM" doesn't mean anything to most people talking about this post-quantum risk. To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption. Whether or not people understand the nuance of encrypting the block cipher keys or encryp…

> Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs?

No, I'm saying that "hybrid KEM" or "chaining two KEMs" is very distinct from "encrypt twice". Confuse the two at your own peril.

> To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.

Encryption is reversible. If you have the key, you can decrypt. It's not encryption if you can't decrypt.

KEMs are their own class of algorithms. They combine an asymmetric encryption scheme with an all-or-nothing one-way transform (usually a key derivation function built on hash functions). It's the safest way to hold asymmetric encryption in practice (even not considering PQ; RSA-KEM beats RSA-OAEP in implementation safety).

Calling KEMs "encryption" is misleading to the point of malpractice. I will push back on conflating the two.

> Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection.

Your only defense-in-depth should be in delivering a strong pseudorandom ephemeral key over an untrusted network, and then using the tried-and-true AEAD constructions that we're already using today. Encrypt once. Do whatever you need to do to get the key exchanged securely.

I write a blog that very regularly covers applied cryptography. I deal with newbie confusion all the time. It's very important that we talk about these things correctly on forums like Hacker News comment threads so that the people learning from us won't get more confused.

Please don't call KEMs "encryption".

Re: A Post-Quantum Future for Let's Encrypt

#53

Post by cyberax » Wed, Jun 03, 2026, 6:37 PM UTC

connorboyle wrote: post #22

tsimionescu wrote: post #8

Earlier quoted context omitted.

By this standard, there is no current encryption method (except for pre-shared one time pads when used correctly) that is known to be unbreakable. For example, it is not proven that prime factoring can't be done much more efficiently on a classical computer - for all we know, it's possible that tomorrow someone will come up with a novel algorithm that can break RSA in just a small number of operations. Same is true f…

Has there been "no progress" on classical prime factorization? What about the AKS primality test, a polynomial-time algorithm to test the primality of a number, published in 2002? (This is not my field of expertise; I'm genuinely curious if there's a good reason to discount this as progress towards efficient prime factorization)

> Has there been "no progress" on classical prime factorization?

Not recently. The primality tests don't really help all that much. We already had polynomial tests that are really fast since the 70-s.

Think about this idea: the output of the counting function for the number of primes ("Euler's totient function") lies almost on the logarithmic curve, and we can compute logarithms quickly to any precision. So we can easily find the general area of the curve that should contain the current prime. And then we can quickly test if the given number is in fact the prime number within it.

This is probabilistic because the prime distribution is not _strictly_ logarithmic. We can imagine that by computing a logarithm we might end up in the next "bucket" and check for the wrong prime.

The fascinating part is that zeroes of the Riemann zeta function encode these corrections on top of the logarithmic curve. If the Riemann hypothesis is correct, then these corrections are _bounded_ and we simply can not end up in a different "bucket" by accident.

Re: A Post-Quantum Future for Let's Encrypt

#54

Post by tatersolid » Wed, Jun 03, 2026, 6:37 PM UTC

hylaride wrote: post #42

lukan wrote: post #2

Better encryption sounds good to me in general, but I don't really understand, how we can make quantum safe encryption, when we don't know yet, what capabilities it will have (or if it is possible at all). I am obviously not in the field, but as far as I know, no QC is close of working for a practical purpose(aside quantum research), but to make it practical, it needs a groundbraking brakethrough of some sort. But if…

It's essentially the laws of physics. To oversimplify, Quantum computing can essentially do certain kinds of operations extremely fast (like factoring prime numbers) because it can calculate all the permutations almost instantly. But if you add intentional complexity to it in ways that all those states can't be "seen" then the quantum computer falls flat. That's one of the issues with adding post-quantum algorithms,…

Clarification/correction:

The Nagasaki “Fat Man” bomb was the same plutonium implosion design tested at Trinity.

The Hiroshima “Little Boy” bomb was the uranium “gun” design that was never tested before combat use. The physics and engineering were comparably straightforward so the scientists were very sure it would work assuming the Urnaium enrichment was pure enough.

Re: A Post-Quantum Future for Let's Encrypt

#55

Post by Tangurena2 » Wed, Jun 03, 2026, 6:38 PM UTC

lukan wrote: post #2

Better encryption sounds good to me in general, but I don't really understand, how we can make quantum safe encryption, when we don't know yet, what capabilities it will have (or if it is possible at all). I am obviously not in the field, but as far as I know, no QC is close of working for a practical purpose(aside quantum research), but to make it practical, it needs a groundbraking brakethrough of some sort. But if…

Bruce Schneier's books explain that there is far more to security than better encryption. Most are implemented incorrectly or used incorrectly.

Re: A Post-Quantum Future for Let's Encrypt

#56

Post by hylaride » Wed, Jun 03, 2026, 6:39 PM UTC

tatersolid wrote: post #54

hylaride wrote: post #42

Earlier quoted context omitted.

It's essentially the laws of physics. To oversimplify, Quantum computing can essentially do certain kinds of operations extremely fast (like factoring prime numbers) because it can calculate all the permutations almost instantly. But if you add intentional complexity to it in ways that all those states can't be "seen" then the quantum computer falls flat. That's one of the issues with adding post-quantum algorithms,…

Clarification/correction: The Nagasaki “Fat Man” bomb was the same plutonium implosion design tested at Trinity. The Hiroshima “Little Boy” bomb was the uranium “gun” design that was never tested before combat use. The physics and engineering were comparably straightforward so the scientists were very sure it would work assuming the Urnaium enrichment was pure enough.

Ugh. You're right. Thanks.

Re: A Post-Quantum Future for Let's Encrypt

#57

Post by buu700 » Wed, Jun 03, 2026, 6:40 PM UTC

tomgag wrote: post #40

some_furry wrote: post #33

Earlier quoted context omitted.

> Refreshing! Not wanting to be the "told you so" guy, > This is a problem that I have met so many times talking with people: they parrot the "Harvest-Now-Decrypt-Later is the only urgent problem, signatures can wait" mantra, and this piece of misinformation has spread so much that even AI repeats it (because it has been trained on open data, where the overwhelming sentiment has been following this trend), thereby re…

Yes, totally agreed, but the problem is that most people tend to simplify this as "let's just bother with PQ encryption, forget about signatures". I know experts can handle the nuance, but execs and most industry folks can't. Or, at least, this is the trend that I have personally observed countless times, maybe I was just unlucky with my data points, but I have seen this in "technical" settings as well (case in point…

I agree. If we're going the rally the industry to do the work, it should be the whole work in one shot. Any given project/infrastructure that implements both encryption and signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM, or at least in immediate succession.

My concern is that PQC is having a bit of a Y2K moment, and undercapitalizing on that sense of urgency may risk letting PQ signatures drag on for ages like IPv6. "We need $X engineering budget for PQC" is easy to understand, but "we need $X for PQ encryption now and $Y for PQ signing at some undefined future time" is murkier and may require getting into the weeds on cryptographic concepts and speculative CRQC timelines with non-expert stakeholders.

Re: A Post-Quantum Future for Let's Encrypt

#58

Post by some_furry » Wed, Jun 03, 2026, 6:46 PM UTC

insanitybit wrote: post #36

some_furry wrote: post #24

Earlier quoted context omitted.

If you encrypt your data twice (taken very literally): c1 = E1(p, k1) c2 = E2(p, k2) If we assume E1() is broken by a quantum computer, E2 doesn't matter to protect p. What you do instead is to use multiple KEMs and combine them securely (see the blog post I linked) in such a way that the confidentiality of your shared secret (i.e., the key you actually use for encryption ) is preserved if any of the underlying KEMs…

The idea would be: key = get_key() classic_key = derive_key(key, "domain-classic") qc_key = derive_key(key, "domain-qc") ciphertext_a = classic_encrypt(plaintext, classic_key) ciphertext_b = qc_encrypt(ciphertext_a, qc_key) I think this is different from what you wrote but I can't really tell. FWIW I am not advocating for "encrypt twice" at all, I'm just trying to understand.

A better idea is to do this:

  # You kind of have to define this since most libraries don't have it
  def classic_kem(pk):
    [eph_sk, eph_pk] = classic_keygen()
    d = classic_shared_secret(eph_sk, pk)
    return hash(d + eph_pk + pk), eph_pk
  
  # Two pieces ...
  [ss1, ct1] = classic_kem(pk1)
  [ss2, ct2] = postquantum_kem(pk2)
  
  # ... combine into one:
  # note: for some KEMs, ct1 and/or ct2 can safely be omitted
  shared_secret = hash(ss1 + ss2 + ct1 + ct2)
  
  ciphertext = symmetric_encrypt(plaintext, shared_secret, context)
  send_to_other_party(
    ct1,
    ct2,
    ciphertext
  )

This sounds more complex, but I'm just filling in the details implied by your pseudocode and making it at least 2x as fast.

On the opposite side, their code looks like this:

  # I'm ignoring implicit vs explicit rejection for simplicity
  def classic_kem_decaps(ct, sk, pk):
    d = classic_shared_secret(ct, sk)
    return hash(d + ct + pk)

  ss1 = classic_kem_decaps(ct1, sk1, pk1)
  ss2 = postquantum_kem_decaps(ct2, sk2, pk2)
  shared_secret = hash(ss1, ss2, ct1, ct2)

  # raises an exception on decrypt failure (e.g., invalid auth tag)  
  plaintext = symmetric_decrypt(ciphertext, shared_secret, context)

If you mean "doing two different KEMs and then securely combining them", then just say that. "Hybrid KEM" is short enough and distinct from other verbage.

"Encrypt" means something specific, not just the vague use of cryptography.

Re: A Post-Quantum Future for Let's Encrypt

#59

Post by mswphd » Wed, Jun 03, 2026, 6:46 PM UTC

saltcured wrote: post #41

some_furry wrote: post #30

Earlier quoted context omitted.

The thing is: Quantum computers don't break AES-GCM, ChaCha20-Poly1305, or any other modern authenticated cipher. Layering encryption or doing cipher cascades is pointless. The thing a cryptography-relevant quantum computer does is break RSA and elliptic curve cryptography, so that the underlying key (k1 or k2) is recoverable from its corresponding public component. Hybrid KEMs, such as mlkem768x25519 (a.k.a. X-Wing)…

Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs? The change of jargon from "encryption" to "KEM" doesn't mean anything to most people talking about this post-quantum risk. To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption. Whether or not people understand the nuance of encrypting the block cipher keys or encryp…

"Intuition" about how cryptography works is notoriously bad. Many intuitive things about cryptography are false, and many true things about cryptography are non-intuitive. For this reason it is difficult to seriously discuss cryptography when people are vaguely referring to what they intuitively hope to achieve, framed in terms of concrete constructions that are not secure.

This is also completely ignoring that designing secure systems is about MUCH more than selecting the right "hard problem". Concretely

> They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.

might mean requiring a much more complicated lock that, in its ideal implementation has the properties you want, but practically is easier to implement incorrectly, yielding a less secure scheme. Considerations of this form almost never appear, despite being very relevant to the end goal of protecting users.

Similarly, this "defense in depth" intuition is currently not particularly controversial for hybrid KEMs. it is currently quite controversial for hybrid signatures though. The intuitive story would work perfectly well for signatures though. So this intuition does not end up being particularly useful for understanding the actual discussion.

Re: A Post-Quantum Future for Let's Encrypt

#60

Post by some_furry » Wed, Jun 03, 2026, 6:59 PM UTC

buu700 wrote: post #57

tomgag wrote: post #40

Earlier quoted context omitted.

Yes, totally agreed, but the problem is that most people tend to simplify this as "let's just bother with PQ encryption, forget about signatures". I know experts can handle the nuance, but execs and most industry folks can't. Or, at least, this is the trend that I have personally observed countless times, maybe I was just unlucky with my data points, but I have seen this in "technical" settings as well (case in point…

I agree. If we're going the rally the industry to do the work, it should be the whole work in one shot. Any given project/infrastructure that implements both encryption and signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM, or at least in immediate succession. My concern is that PQC is having a bit of a Y2K moment, and undercapitalizing on that sense of urgency may risk letting PQ signatures drag on for…

> signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM

I know you mean well, but this proposal maximizes the downsides of PQ signatures.

Both ML-DSA and SLH-DSA have enormous keys. SLH-DSA is also very slow, while ML-DSA is relatively fast: https://blog.cloudflare.com/another-look-at-pq-signatures/

One of the biggest challenges with the signatures currently standardized is the signature + public key sizes. Demanding we hybridize both just maximizes the pain, and there's no real incentive for this.

As I wrote in https://soatok.blog/2026/04/13/hybrid-constructions-the-post..., the justification for composite/hybrid signatures just isn't there.

Use ML-DSA-44. Don't combine it with other crap. It's good enough.

For KEMs, X-Wing (mlkem768x25519) is great, but ML-KEM-768 and ML-KEM-1024 are also fine on their own. Hybrids are the path of least resistance here, so I prefer them, but have no concerns over ML-KEM's security.