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.
-
@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@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...
-
@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...
@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.
-
@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.@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??!
-
@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.
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
-
@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.@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
-
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.
Is anyone following this work?
Cultivating a robust and efficient quantum-safe HTTPS
Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...
Google Online Security Blog (security.googleblog.com)
@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.
-
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.
Is anyone following this work?
Cultivating a robust and efficient quantum-safe HTTPS
Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...
Google Online Security Blog (security.googleblog.com)
@dangoodin @briankrebs no, quantum computing is nothing.
-
@sophieschmieg @dangoodin @filippo 82 pages of RFC…hmmm…must be secure then!
@icing @sophieschmieg @dangoodin it's mostly very well-tested stuff from the tlog ecosystem. The Go sumdb has had zero security incidents since 2019. The same is not true of our crypto/x509. But please do report any issues!
-
@icing @sophieschmieg @dangoodin it's mostly very well-tested stuff from the tlog ecosystem. The Go sumdb has had zero security incidents since 2019. The same is not true of our crypto/x509. But please do report any issues!
@filippo @icing @sophieschmieg @dangoodin it's kinda straightforward but it's not trivial
-
@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@i @andrei_chiffa @dangoodin no, the CT logs still function as CT logs in mtc. They do away with the imperfection of CT logs requiring signatures instead of being published immediately, and they use the fact that the CT log itself can function as a certificate, but the trust model isn't relaxed, it's just more complicated.
-
@i @andrei_chiffa @dangoodin no, the CT logs still function as CT logs in mtc. They do away with the imperfection of CT logs requiring signatures instead of being published immediately, and they use the fact that the CT log itself can function as a certificate, but the trust model isn't relaxed, it's just more complicated.
@sophieschmieg@infosec.exchange what I'm trying to say is: the number of moving parts, that I need to trust or verify is increasing. And that is not really comforting.
Am I missing something here?
@andrei_chiffa@mastodon.social @dangoodin
-
@sophieschmieg@infosec.exchange what I'm trying to say is: the number of moving parts, that I need to trust or verify is increasing. And that is not really comforting.
Am I missing something here?
@andrei_chiffa@mastodon.social @dangoodin@i @andrei_chiffa @dangoodin you can always request and verify the fallback certificate, which is just a normal cert chain backed by ML-DSA. MTC is an optional optimization mechanism for the browser, that also fixes an issue CT had while we're at it.
-
@i @andrei_chiffa @dangoodin you can always request and verify the fallback certificate, which is just a normal cert chain backed by ML-DSA. MTC is an optional optimization mechanism for the browser, that also fixes an issue CT had while we're at it.
@sophieschmieg@infosec.exchange got it! Thanks for the clarification.
