upvote

points

by rdl1 days ago |
comments
upvoteby jeroenhd1 days ago|
next
[-]
If any kind of proof about serious quantum computers comes to light, browsers can force most websites' hand by marking non-PQ ciphers as insecure.

Maybe it'll require TLS 1.4/QUIC 2, with no changes but the cipher specifications, but it can happen in two or three years. Certificates themselves don't last longer than a year anyway. Corporations running ancient software that doesn't support PQ TLS will have the same configuration options to ignore the security warnings already present for TLS 1.0/plain HTTP connections.

The biggest problem I can imagine is devices talking to the internet no longer receiving firmware updates. If the web host switches protocols, the old clients will start dying off en masses.

reply
upvoteby bwesterb1 days ago|
parent|
next
[-]
No need for a TLS 1.4.

Leaf certificates don't last long, but root CAs do. An attacker can just mint new certs from a broken root key.

Hopefully many devices can be upgraded to PQ security with a firmware update. Worse than not receiving updates, is receiving malicious firmware updates, which you can't really prevent without upgrading to something safe first.

reply
upvoteby jeroenhd22 hours ago|
parent|
next
[-]
> An attacker can just mint new certs from a broken root key.

In Chrome at the very least, the certificate not being in the certificate transparency logs should throw errors and report issues to the mothership, and that should detect abuse almost instantly.

You'd still be DoSing an entire certificate authority because a factored CA private key means the entire key is instantly useless, but it wouldn't allow attacks to last long.

reply
upvoteby bwesterb22 hours ago|
parent|
[-]
Yeah, PQ certificate transparency is crucial for downgrade protection: https://westerbaan.name/~bas/rwpqc2026/bas.pdf
reply
upvoteby 1 days ago|
parent|
prev|
[-]
deleted
reply
upvoteby GoblinSlayer23 hours ago|
parent|
prev|
next
[-]
When you connect, you specify supported ciphers. If the server doesn't support them, there's standard "insufficient security" (71) error that was there since at least TLS 1.0, maybe earlier.
reply
upvoteby rocqua20 hours ago|
parent|
[-]
Confidentiality of the TLS connection is indeed easy to handle here.

The hard part is certificate authentication. And that's not included in the cipher suite setting.

reply
upvoteby PunchyHamster1 days ago|
parent|
prev|
[-]
There is no reason to not support non quantum safe algorithms for foreseeable future in the first place
reply
upvoteby greesil1 days ago|
parent|
next
[-]
You did not increase comprehension by not using a single negative.
reply
upvoteby ZiiS1 days ago|
parent|
prev|
[-]
They are slower, larger, and less tested. Specifically the hope was to develop hybrids that could also provably be more pre-quantum secure then what they are replacing. History dose not favour rushing cryptography.
reply
upvoteby bwesterb22 hours ago|
parent|
next
[-]
They are large, but they're not that slow actually. We've been testing them for almost a decade now. I agree that rushing is bad. That's why we need to start moving now, so that we're not rushing even closer to the deadline.
reply
upvoteby Hendrikto1 days ago|
parent|
prev|
[-]
You misread the comment you replied to.
reply
upvoteby KAMSPioneer23 hours ago|
parent|
[-]
Which, to be fair, is easy to do because they used a triple-negative.

Rephrased, they meant to say "there is no reason to remove support for quantum-vulnerable algorithms in the near future."

IMO that's much less likely to be accidentally misinterpreted.

reply
upvoteby bwesterb1 days ago|
prev|
next
[-]
Waiting now means rushing even more close to the deadline! We added stats on origin support for post-quantum encryption. Not as much support as browsers of course, but better than I expected. Still a long road (and authentication!). https://radar.cloudflare.com/post-quantum
reply
upvoteby stingraycharles1 days ago|
prev|
[-]
> Updating websites is going to be so much easier than dealing with other systems (bitcoin probably the worst; data at rest storage systems; hardware).

IPv6 deserves a prominent spot there

reply
upvoteby fc417fc8021 days ago|
parent|
[-]
Does it? That one is different because IPv4 with CGNAT largely "just works" except for P2P type stuff. As a result there's a strong incentive for anyone who has a working setup to just not care.

I can use myself as an example here. IPv6 is supported by all my hardware, all the software I use, and my ISP provides it. Yet my LAN intentionally remains IPv4 only with NAT. Why? Because adding IPv6 to my LAN would require nonzero effort on my part and has (at least for now) quite literally zero upside for me. If I ever need something it offers I will switch to it but that hasn't happened yet.

PQC is entirely different in that the existence of a CRQC immediately breaks the security guarantee.

reply