Google's Chrome Begins Supporting Post-Quantum Key Agreement to Shield Encryption Keys (theregister.com) 13
"Teams across Google are working hard to prepare the web for the migration to quantum-resistant cryptography," writes Chrome's technical program manager for security, Devon O'Brien.
"Continuing with our strategy for handling this major transition, we are updating technical standards, testing and deploying new quantum-resistant algorithms, and working with the broader ecosystem to help ensure this effort is a success." As a step down this path, Chrome will begin supporting X25519Kyber768 for establishing symmetric secrets in TLS, starting in Chrome 116, and available behind a flag in Chrome 115. This hybrid mechanism combines the output of two cryptographic algorithms to create the session key used to encrypt the bulk of the TLS connection:
X25519 — an elliptic curve algorithm widely used for key agreement in TLS today
Kyber-768 — a quantum-resistant Key Encapsulation Method, and NIST's PQC winner for general encryption
In order to identify ecosystem incompatibilities with this change, we are rolling this out to Chrome and to Google servers, over both TCP and QUIC and monitoring for possible compatibility issues. Chrome may also use this updated key agreement when connecting to third-party server operators, such as Cloudflare, as they add support. If you are a developer or administrator experiencing an issue that you believe is caused by this change, please file a bug.
The Register delves into Chrome's reasons for implementing this now: "It's believed that quantum computers that can break modern classical cryptography won't arrive for 5, 10, possibly even 50 years from now, so why is it important to start protecting traffic today?" said O'Brien. "The answer is that certain uses of cryptography are vulnerable to a type of attack called Harvest Now, Decrypt Later, in which data is collected and stored today and later decrypted once cryptanalysis improves." O'Brien says that while symmetric encryption algorithms used to defend data traveling on networks are considered safe from quantum cryptanalysis, the way the keys get negotiated is not. By adding support for a hybrid KEM, Chrome should provide a stronger defense against future quantum attacks...
Rebecca Krauthamer, co-founder and chief product officer at QuSecure, told The Register in an email that while this technology sounds futuristic, it's useful and necessary today... [T]he arrival of capable quantum computers should not be thought of as a specific, looming date, but as something that will arrive without warning. "There was no press release when the team at Bletchley Park cracked the Enigma code, either," she said.
"Continuing with our strategy for handling this major transition, we are updating technical standards, testing and deploying new quantum-resistant algorithms, and working with the broader ecosystem to help ensure this effort is a success." As a step down this path, Chrome will begin supporting X25519Kyber768 for establishing symmetric secrets in TLS, starting in Chrome 116, and available behind a flag in Chrome 115. This hybrid mechanism combines the output of two cryptographic algorithms to create the session key used to encrypt the bulk of the TLS connection:
X25519 — an elliptic curve algorithm widely used for key agreement in TLS today
Kyber-768 — a quantum-resistant Key Encapsulation Method, and NIST's PQC winner for general encryption
In order to identify ecosystem incompatibilities with this change, we are rolling this out to Chrome and to Google servers, over both TCP and QUIC and monitoring for possible compatibility issues. Chrome may also use this updated key agreement when connecting to third-party server operators, such as Cloudflare, as they add support. If you are a developer or administrator experiencing an issue that you believe is caused by this change, please file a bug.
The Register delves into Chrome's reasons for implementing this now: "It's believed that quantum computers that can break modern classical cryptography won't arrive for 5, 10, possibly even 50 years from now, so why is it important to start protecting traffic today?" said O'Brien. "The answer is that certain uses of cryptography are vulnerable to a type of attack called Harvest Now, Decrypt Later, in which data is collected and stored today and later decrypted once cryptanalysis improves." O'Brien says that while symmetric encryption algorithms used to defend data traveling on networks are considered safe from quantum cryptanalysis, the way the keys get negotiated is not. By adding support for a hybrid KEM, Chrome should provide a stronger defense against future quantum attacks...
Rebecca Krauthamer, co-founder and chief product officer at QuSecure, told The Register in an email that while this technology sounds futuristic, it's useful and necessary today... [T]he arrival of capable quantum computers should not be thought of as a specific, looming date, but as something that will arrive without warning. "There was no press release when the team at Bletchley Park cracked the Enigma code, either," she said.
Why not KYBER-1024 though? (Score:3)
Why would they choose anything less than the maximum keysize if there's a larger one available, and the performance penalty would be undetectable by end users? Attacks only get better over time.
Just saying. Oldtimers may recall questions as to why 3DES used 56 bits as opposed to 64 bits back in the day; was it to make it 'hard' (for 'other' spooks) but not 'too hard' for the 5-eyes spooks?
Re: (Score:1)
Lol take a guess. It's the same reason we're still using aes-256 and elliptic curve.
Re: (Score:2)
"It's the same reason we're still using aes-256 and elliptic curve."
What's wrong with AES-256?
Well I know what's wrong with AES-256 in terms of the impractical key schedule attack and I'm not concerned about it.
I'm more concerned with the obsession with larger key sizes like this is a good thing.
Can you break AES-128? No
Can you break AES-256? No
So what's the difference? Your crypto now runs 40% slower with neither increased nor decreased ability to break the crypto.
We would be better off focusing on side ch
Re: (Score:2)
Using X25519Kyber768 adds over a kilobyte of extra data to the TLS ClientHello message due to the addition of the Kyber-encapsulated key material. Our earlier experiments with CECPQ2 demonstrated that the vast majority of TLS implementations are compatible with this size increase; however, in certain limited cases, TLS middleboxes failed due to improperly hardcoded restrictions on message size.
Khyber1024 adds an additional ~400 bytes to the key size, making it greater than 1500 bytes (1568). This will be even more problematic than khyber768.
and they'll force disable the rest in 3, 2, 1 .. (Score:3)
Adding some new ciphers to browsers and servers is fine and SSL's supported for decades.
When Google is obnoxious is when they then remove the old stuff, you know, "for your own good" in ways that are hard to bypass.
Like MD5, server certs with long lifetimes. Or try connecting to localhost:4045 (or any 4045) sometime, though Firefox does this too.
Re: (Score:2)
Chrome won't be removing AES or SHA-256 in this decade unless there's a major break found.
keeping your data safe from (Score:1)
why use Chrome browser? (Score:1)
NSA and NIST sabotoging post-quantum crypto? (Score:1)
There is even a lawsuit [cr.yp.to], as despite NIST's claims about being open, most work has been done behind closed doors, and they are stonewalling on FOIA requests for their communications with the NSA. Any crypto standard that they produce, is most likely useful as an indicator of what to avoided. That link highlights the long history of sabotage, and the NSA aren't the only ones with motive.
The vulnerability and the problem (Score:2)