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

91–100 of 175 posts

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

#91

Post by dwaite »

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.

Trying to bridge this a bit since I'm closer to a layperson in this area.

Symmetric encryption does not need a quantum computer alternative, nor do we need a post quantum hashing algorithm. We may need larger keys and larger outputs from the existing algorithms, but that really depends on the level of paranoia.

It is the asymmetric keys that need post quantum replacement.

So I'm guessing the change to your proposed pseudocode you would have two derivation algorithms based on two input asymmetric keys - one post quantum and one classical. You would get from these two separate symmetric keys. You would then layer encryption using each of them, encrypting the cipher text output from the first with the second.

You can however just combine the two derived symmetric keys together to create a single symmetric key, and encrypt once. That is what hybrid algorithms propose.

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

#93

Post by bigfatkitten »

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…

If we take near term to mean “while any of the participants in this thread are still alive”, I think we’re going to be safe for a while.

https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

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

#94

Post by some_furry »

mcpherrinm wrote: post #87
some_furry wrote: post #69

Earlier quoted context omitted.

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.

OpenSSH's Damien Miller has https://datatracker.ietf.org/doc/draft-miller-sshm-mldsa44-e... defining ssh-mldsa44-ed25519@openssh.com which seems more likely given the authorship.

Sure, but that's a composite scheme, and I dislike those. :P

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

#96

Post by mcpherrinm »

LoganDark wrote: post #76

This post completely fails to address one of my biggest fears with a batched approach: waiting for a brand new certificate to be provisioned for a server that does not already have one. If batches are executed too frequently, then clients will have too big a database to maintain. If batches are executed too infrequently, then I have to wait a while to get my first certificate. Are they doing anything about this or is…

Great question! Of course, we'll continue to provide more information as we firm up more details. This is an area that's not locked down yet, but I can give a sneak preview of what it might look like.

We expect batches to be produced quickly, on the same order of magnitude as current CT logs - somewhere in the 0.5s to 5 second range. This is an existing problem since (at least some) CT logs do the same batched behaviour.

Now, there is a catch with MTCA: That gets you a "standalone" certificate, which works just like a certificate does today. But it's big, still. To get the new, small certificates (landmark-relative), you will have to wait for the next landmark. Based on current planning and discussions with Chrome, we expect that to be hourly for short-lived certs, and 4 hours for longer-lived certificates.

So you'll get a big cert instantly, but you might have to wait an hour or 4 to get a certificate. So your new website can be online quickly, but with some downsides until you get the small landmark-relative cert.

(I work at Let's Encrypt)

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

#97

Post by agwa »

LoganDark wrote: post #76

This post completely fails to address one of my biggest fears with a batched approach: waiting for a brand new certificate to be provisioned for a server that does not already have one. If batches are executed too frequently, then clients will have too big a database to maintain. If batches are executed too infrequently, then I have to wait a while to get my first certificate. Are they doing anything about this or is…

You'll be able to immediately use use a "standalone certificate" while waiting for the batch to be created. The tradeoff is that the standalone certificate will have multiple huge ML-DSA signatures.

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

#98

Post by agwa »

kibwen wrote: post #11

> In the common case, the entire authentication path in an MTC handshake is one signature, one public key, and one inclusion proof. That’s smaller than today’s Web PKI handshake, even though MTCs use post-quantum algorithms. [...] There is more to MTCs than size optimization. Because every certificate is part of a published Merkle tree, transparency becomes a property of issuance itself. Today’s Certificate Transpare…

The downside is that to get the size optimization, TLS servers will get moderately more complicated (they'll need to have multiple MTC certificates configured and select the right one depending on the client's state), and TLS clients will get considerably more complicated (they'll need to continuously download landmarks for each CA out-of-band from a trusted source).

I expect many non-browser TLS clients won't support the small landmark-relative certificates, because there isn't a clear party to operate the landmark distribution service (Chrome has Google, and Firefox has Mozilla, but who does curl have?). I'm also worried that support will be lacking in open source TLS servers, though that's a more tractable problem. Consequentially, I expect the large standalone certificates to be quite common outside of connections between browsers and CDNs.

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

#99

Post by m463 »

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…

I've always thought creating an ssh-otp should be easy to implement.

(meaning xor the packets themselves with a huge bundle of random data duplicated at each side, and never re-used)

But I think it would probably still qualify as a munition and have export restrictions.

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

#100

Post by mcpherrinm »

agwa wrote: post #98
kibwen wrote: post #11

> In the common case, the entire authentication path in an MTC handshake is one signature, one public key, and one inclusion proof. That’s smaller than today’s Web PKI handshake, even though MTCs use post-quantum algorithms. [...] There is more to MTCs than size optimization. Because every certificate is part of a published Merkle tree, transparency becomes a property of issuance itself. Today’s Certificate Transpare…

The downside is that to get the size optimization, TLS servers will get moderately more complicated (they'll need to have multiple MTC certificates configured and select the right one depending on the client's state), and TLS clients will get considerably more complicated (they'll need to continuously download landmarks for each CA out-of-band from a trusted source). I expect many non-browser TLS clients won't suppor…

On Linux and similar systems, I'm hoping github.com/rustls/upki will handle landmark distribution, and that non-browser clients can use that. Of course Rustls will support their own project, but I'm hopeful other TLS stacks do too. Ubuntu announcing they're deploying it should help with that.

On other OSes (like Mac OS and Windows), there's also OS-level services which could support this.

It would be a shame if we end up with a bunch of copies of this data, so I think a shared OS service is the only reasonable approach.

The hardest part is going to be smaller embedded systems.

Post reply on HN