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

131–140 of 175 posts

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

#131

Post by sureglymop »

From the article not everything is fully clear to me yet.

What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962.

The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof!

So, someone can do inclusion and consistency proofs. If a log presents a split view that should be noticable through gossiping. But what gossiping is implemented? I think the only gossiping that happens is in the CT Google group/mailing list that probably few people know of.

Then, what if you want to actually detect malicious or misissued certs for your domain? Ideally you want to do it yourself and not use some service. Probably you just have one server and IP. Now you have to download insane amounts of data from ~60 logs and hope that someone else is checking the consistency and correctness of those logs. And you have to scrape those logs faster than they grow. Now, what if everyone running a web server did monitor? Even static logs probably couldn't withstand that.

Next, what about the log lists? One can talk all about sovereignty but really you rely on and have to trust Apple and Google with their policies and log lists if you want to meaningfully participate in this system and by extension, the encrypted web...

CT is fully deployed to production but still has many design flaws and things that are still just theoretical. It seems many of them are addressed by MTCs. I hope it can be better.

The one thing I didn't see addressed is the gossiping thing. Couldn't a malicious CA still present a split view under this model?

And if I'll have to rely on mirrors then I still can't independently monitor.

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

#134

Post by mswphd »

crote wrote: post #111
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…

> a near term risk we are planning for I'd argue it's closer to a cheap insurance, just in case. Take the encryption of a TLS connection itself, for example: you want to protect against a possible "store now, decrypt later" attack on your connection, 60 years from now, by an attacker with an NSA-level budget. Even if you judge the probability of it happening as "exceedingly unlikely", migrating to a hybrid scheme is…

> as they almost certainly have weaknesses for some of those new PQ schemes already lying around

why believe this about PQ schemes vs about pre-existing schemes? Or any other schemes?

It's also worth mentioning that it appears that other countries (in particular China) will adopt fundamentally similar schemes. The NSA loves vulnerabilities, but generally only vulnerabilities of a certain type. These are generally referred to as "NOBUS"

https://en.wikipedia.org/wiki/NOBUS

It includes things like backdoors (say DUAL_EC_DRBG), as well as historically things like reducing the key size of DES, where the US thought they'd be able to brute force it (but other countries would lack the compute). Historically the NSA has actually assisted in removing non-NOBUS vulnerabilities (at least they did this with the SBOX design of DES, which was vulnerable to differential/linear cryptanalysis --- I forget which).

The NSA hasn't publicly assisted/disclosed any vulnerabilities with currently suggested schemes, though a close US ally (Isreal, through an IDF group known by Matzov) has. If America was hoarding vulnerabilities, one might imagine America would have pressured Isreal to keep this secret.

A final point is that it's not clear where the NSA would source the vulnerabilities. By a peculiar chain of coincidences, nearly all of the most successful lattice cryptanalysts are European. None have "gone dark" in a way that would be concerning (say how Don Coppersmith did, when he moved to a NSA affiliate in the mid 2000s). This isn't to say that it would be impossible for the NSA to have better-than-public vulnerabilities, but more to say that they can't just take some of the most successful people who have publicly attacked the problem, and throw more money at them. Their "talent-pipeline" for this particular problem is not as available (and many cryptographers soured on working with them post-Snowden anyway).

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

#135

Post by mswphd »

fluoridation wrote: post #128
crote wrote: post #111

Earlier quoted context omitted.

> a near term risk we are planning for I'd argue it's closer to a cheap insurance, just in case. Take the encryption of a TLS connection itself, for example: you want to protect against a possible "store now, decrypt later" attack on your connection, 60 years from now, by an attacker with an NSA-level budget. Even if you judge the probability of it happening as "exceedingly unlikely", migrating to a hybrid scheme is…

I don't know about signatures, but wouldn't a hybrid encryption scheme just involve nesting? Why would that have weaknesses from the hybridization?

First, it doesn't, because we don't use public-key encryption. Instead, we use key-encapsulation mechanisms, which you have to hybridize in another way.

Second, hybridization can add weaknesses in several ways

1. Hybridization may preserve some, but not all, security properties of the constituent parts. This is the case for hybrid signatures. In particular, ML-DSA signatures have a better than SUF-CMA type of security typically called "BUFF" security. Known hybridization techniques lose this security.

2. Hybridization is also more code (and more complex code) to write. Historically, the vast majority of cryptographic issues come from implementation issues, not fundamental weaknesses in the underlying hard problems. So suggesting to obtain security by doing more complex things may not always achieve the desired goal.

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

#136

Post by mswphd »

bigfatkitten wrote: post #93
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

it's worth mentioning opinions have started to shift away from this. Quantum computing has made quite concrete progress in the last ~2 years. No guarantee this continues, but among people I know it has changed their perspectives from (roughly) similar things as that essay, to thinking we really must transition now.

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

#137

Post by mcpherrinm »

sureglymop wrote: post #131

From the article not everything is fully clear to me yet. What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962. The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof! So, someone can do inclusion and cons…

Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised.

There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.

CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.

Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.

Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".

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

#138

Post by sureglymop »

mcpherrinm wrote: post #137
sureglymop wrote: post #131

From the article not everything is fully clear to me yet. What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962. The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof! So, someone can do inclusion and cons…

Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised. There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it. CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, y…

Okay that choice of words was a bit harsh. My struggles are partly also due to logs barely complying, that I can't even monitor as quickly as they grow from one IP (mainly looking at you, trustasia, though at least there now is a static log).

Thank you for the explanations. I think I should read the draft RFC.

The last part of your comment caught my attention, seems great if that is being worked on. Can I find more information on it somewhere?

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

#139

Post by mcpherrinm »

sureglymop wrote: post #138
mcpherrinm wrote: post #137

Earlier quoted context omitted.

Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised. There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it. CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, y…

Okay that choice of words was a bit harsh. My struggles are partly also due to logs barely complying, that I can't even monitor as quickly as they grow from one IP (mainly looking at you, trustasia, though at least there now is a static log). Thank you for the explanations. I think I should read the draft RFC. The last part of your comment caught my attention, seems great if that is being worked on. Can I find more i…

The best introduction to verifiable indexes I know of offhand is https://www.youtube.com/watch?v=gfrXTgmbS1s and https://github.com/transparency-dev/incubator/tree/main/vind...

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

#140

Post by bawolff »

bigfatkitten wrote: post #93
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

That was very unconvincing.

Like if you want to go from history - yes the make a giant artillery piece thing didn't work.

You know what did work? A surprising application of quantum physics known as nuclear bombs.

I'm not neccesarily saying quantum computers will work out the same way, but if you follow the logic of the presentation, nuclear bombs fit it so much better than the example they use. It was a step-change. People went from saying it was theoretically interesting without practical application to actually having a bomb very quickly. Basically replace everything in that presentation using nukes as the running example and suddenly the argument sounds really stupid.

Post reply on HN