Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

[shuasha@infosec.exchange]

@dangoodin Yeah, but I'm a weirdo who goes to IETF meetings and cares about this stuff. You can watch the PLANTS meeting from Novermber's IETF meeting here: https://www.youtube.com/watch?v=wBR_MIFc08I

[agwa@follow.agwa.name]

@dangoodin Yes, closely. There's a lot of momentum and Mozilla and Apple are interested as well.

[agwa@follow.agwa.name]

@andrei_chiffa @dangoodin The QR asymmetric handshake protects against passive attackers decrypting sniffed traffic, but not against active attackers presenting a forged certificate in a man-in-the-middle attack. Merkle Tree Certificates protect against the latter threat.

[sophieschmieg@infosec.exchange]

@dangoodin yes.

[sophieschmieg@infosec.exchange]

@andrei_chiffa @dangoodin the issue is the size of the handshake itself. You have to run the entire handshake before you can transmit data. With PQC, what used to be a 32 to 256 byte public key or signature now each becomes 1 to 3.5 KB in size. This is acceptable for the key agreement parts, since we really only need one artifact per party there, but becomes way too expensive when talking about the certificate, i.e. a chain of public keys signed by keys further up.
Merkle Tree Certificates are a proposal that significantly compresses this certificate chain, at the cost of a more complicated trust management story.

[shuasha@infosec.exchange]

@sophieschmieg @andrei_chiffa @dangoodin Dan: The scale of the problem is spelled out pretty clearly in this presentation from the last IETF: https://youtu.be/wBR_MIFc08I?si=85y_tlGfEdREkFRd&t=1027

[spacelifeform@infosec.exchange]

@dangoodin

Smells.

#EEE

[spacelifeform@infosec.exchange]

@dangoodin

Who cares about the certs if you are behind a defacto MITM like Cloudflare?

[spacelifeform@infosec.exchange]

@dangoodin

This is Security Threatre.

[tknarr@mstdn.social]

@dangoodin My question is, how close are we to hardware that can do quantum attacks on encryption?

[vandorb12@infosec.exchange]

@dangoodin seeing the cryptography nerds do their thing, and all I see is word salad, dreading the day I have to learn anything about certificates and cryptography beyond a Cæsar cypher in school.

[thibaultmol@en.osm.town]

@tknarr @dangoodin don't forget how slow certain technology adoption rates are.
You only need one person to have the capabilities to use quantum computer for this meanwhile every website needs to update which will take a while

[icing@chaos.social]

@sophieschmieg @dangoodin @filippo 82 pages of RFC…hmmm…must be secure then!

[i@toot.pouyan.net]

@SpaceLifeForm@infosec.exchange Firefox never really forced CT logged, but with this proposal it seems to me that you now have to trust that a CA can properly maintain a log and also trust the cosigners at the same time.

@dangoodin@infosec.exchange

[tknarr@mstdn.social]

@thibaultmol @dangoodin Yes. It won't be just one person though, just as it wasn't just one person who got the first computer made using ICs. It'll be a steady progression across such a large set of organizations that there'll be no way not to broadcast the state of the hardware. We'll know well before the first unit that can do the job in a reasonable amount of time is produced.

The question needs asked and answered: what's the earliest we can reasonably expect the first one...

[tknarr@mstdn.social]

@thibaultmol @dangoodin ... that can do the job at all to arrive? Without a timeframe, planning a response is a bad idea. You need a response in place before that deadline, but if you rush things you end up with sub-par results that won't hold up against the inevitable advances. So we really need to know if we're on a 5 year deadline vs. 10, 25, 50.

Personally I think it's closer to 50 than 10.

[neilmadden@infosec.exchange]

@sophieschmieg @andrei_chiffa @dangoodin I’m a bit confused by this. The client is still going to need the public keys, right? So is this just replacing the signatures with a Merkle proof? Have you done a blockchain??!

[i@toot.pouyan.net]

This is the NSA timeline for PQC. Other countries (EU, UK, etc.) have similar timelines between 2030 and 2035.

I, however, do not think that we will have any Cryptographically Relevant Quantum Computers (CRQC) in the next decades.

CC: @thibaultmol@en.osm.town @dangoodin@infosec.exchange

[i@toot.pouyan.net]

@sophieschmieg@infosec.exchange it's ironic because CT logs were introduced because we didn't trust CAs. Now we should trust the CA, the cosigners, and the CT logs.

@andrei_chiffa@mastodon.social @dangoodin@infosec.exchange

[neverpanic@chaos.social]

@dangoodin Exciting, but also seems heavily focused on the needs of hyperscalers. Will roll out in Chrome and Cloudflare only at first, others get left behind. Requires a public Merkle tree, no thought seems to have been given to private CAs. And at the same time, Chrome is sabotaging the existing ML-DSA certificates (that already work today, albeit slow), by not implementing them.