Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Post-Quantum Future for Let's Encrypt

letsencrypt.org

Post reply on HN
Print view View original

61–70 of 175 posts

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

#61

Post by saltcured »

mswphd wrote: post #59
saltcured wrote: post #41

Earlier quoted context omitted.

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 desig…

I don't disagree, but I think the folks who know this ought to remember the lay person perspective and try to address it more concretely.

Rather than rejecting the framing because they (we) aren't fluent in your jargon, provide a more constructive hint... E.g. "You may be thinking the symmetric cipher key is simply encrypted with the asymmetric cipher and concatenated to the bulk message. But, to mitigate known cryptographic system risks, modern solutions use specialized key encapsulation or key exchange methods (KEM) which are not directly encrypted messages containing key material."

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

#63

Post by mswphd »

3form wrote: post #27
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…

It seems to me you assumed that the poster that replied to you meant encrypting in parallel, while it seems pretty clear to me what they meant was c = E1(E2(p, k2), k1).

both encrypting in parallel and encrypting in the second way you mentioned are bad ideas, and are far from being what is seriously being discussed when people talk about hybrid KEMs. Encrypting in parallel is explicitly IND-CPA insecure if one of the ciphers is broken. Your construction is IND-CPA secure, but quite inefficient, and would not fit into modern protocols.

If this was a typical cryptographic topic, this might be fine, and is how I would likely phrase things for an undergraduate cryptography course. Unfortunately, this is a topic that a certain cryptographer with a decently large public following has been spreading conspiracy theories (and slandering other cryptographers about) for a number of years now. So, discussions on this topic often come from a place where the audience is misinformed, and more care is required in grounding the discussing in what is actually being discussed/considered.

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

#64

Post by zetsurin »

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…

[Vinge](https://en.wikipedia.org/wiki/Vernor_Vinge) was a professor of mathematics and computer science. I'd expect him to get things right. Funny enough I don't remember that bit at all from fire upon the deep.

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

#65

Post by buu700 »

some_furry wrote: post #60
buu700 wrote: post #57

Earlier quoted context omitted.

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.…

I wasn't implying that the two should be hybridized. I think both are great options to have in our toolkit. For example, in Cyph I chose ML-DSA for end user signing keys + certificates and SLH-DSA for code signing.

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

#66

Post by some_furry »

saltcured wrote: post #61
mswphd wrote: post #59

Earlier quoted context omitted.

"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 desig…

I don't disagree, but I think the folks who know this ought to remember the lay person perspective and try to address it more concretely. Rather than rejecting the framing because they (we) aren't fluent in your jargon, provide a more constructive hint... E.g. "You may be thinking the symmetric cipher key is simply encrypted with the asymmetric cipher and concatenated to the bulk message. But, to mitigate known crypt…

> I think the folks who know this ought to remember the lay person perspective

That's fair. I hold Hacker News to a higher bar of technical proficiency than a general audience. My hope with insisting on correct framing is to nudge other experts in adjacent fields to teach your more general audiences how to think about these topics more correctly so it's more approachable to the general public.

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

#67

Post by raphinou »

I've been working on a new project using ed25519 signatures and discovered they are not quantum resistant.... I went with ed25519 due to possibility of using openssh keys. Any opinion on this choice at the light of this article and other quantum computing news?

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

#68

Post by some_furry »

buu700 wrote: post #65
some_furry wrote: post #60

Earlier quoted context omitted.

> 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.…

I wasn't implying that the two should be hybridized. I think both are great options to have in our toolkit. For example, in Cyph I chose ML-DSA for end user signing keys + certificates and SLH-DSA for code signing.

Sorry, I did entirely misread your words.

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

#69

Post by some_furry »

raphinou wrote: post #67

I've been working on a new project using ed25519 signatures and discovered they are not quantum resistant.... I went with ed25519 due to possibility of using openssh keys. Any opinion on this choice at the light of this article and other quantum computing news?

There's an IETF RFC draft for mldsa-44 keys for OpenSSH. https://datatracker.ietf.org/doc/draft-rpe-ssh-mldsa

I'm not aware if it has any real traction, but that's what I found with a quick search.

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

#70

Post by zem »

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 zones of thought universe literally had different physics; things like superintelligence and ftl travel were physically impossible closer to the galactic centre but commonplace further out. so the notion of "not physically practical" doesn't apply here.
Post reply on HN