Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Encryption Chrome

Chrome Switching To NIST-Approved ML-KEM Quantum Encryption (bleepingcomputer.com) 48

Google is updating the post-quantum cryptography in Chrome, replacing the experimental Kyber with the fully standardized Module Lattice Key Encapsulation Mechanism (ML-KEM) to enhance protection against quantum computing attacks. BleepingComputer reports: This change comes roughly five months after Google rolled out the post-quantum secure TLS key encapsulation system on Chrome stable for all users, which also caused some problems with TLS exchanges. The move from Kyber to ML-KEM though is not related to those early problems, that got resolved soon after manifesting. Rather, its a strategic choice to abandon an experimental system for a NIST-approved and fully standardized mechanism.

ML-KEM was fully endorsed by the U.S. National Institute of Standards and Technology (NIST) in mid-August, with the agency publishing the complete technical specifications of the final version at the time. Google explains that despite the technical changes from Kyber to ML-KEM being minor, the two are essentially incompatible, so a switch had to be made. "The changes to the final version of ML-KEM make it incompatible with the previously deployed version of Kyber," explains Google. "As a result, the codepoint in TLS for hybrid post-quantum key exchange is changing from 0x6399 for Kyber768+X25519, to 0x11EC for ML-KEM768+X25519."

Chrome Switching To NIST-Approved ML-KEM Quantum Encryption

Comments Filter:
  • I am far from knowing much about encryption and quantum computer capabilities today but I do not recall any such breach.
    Are quantum technologies near such capability? I do not think so. So why now? Is it just an for bragging rights?

    • by JoshuaZ ( 1134087 ) on Tuesday September 17, 2024 @07:13AM (#64792343) Homepage
      There's concern about people engaging in what is called "Store Now, Decrypt Later" or "Harvest Now, Decrypt Later" https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later [wikipedia.org] where powerful actors (such as various intelligence agencies and large criminal organizations) will store large amounts of encrypted information and then go back and decrypt it once the quantum computers are available. This is a legitimate concern. That said, one obvious concern in the other direction is that the encryption schemes which we are hoping to be resistant to quantum computing based attacks have had much less attention given to them (in part due to them simply being much younger), and thus we have less certainty that they are even classically good encryption. And we've had now multiple examples of supposedly quantum resistant algorithms being cracked by completely classical methods. See for example :https://cacm.acm.org/news/nist-post-quantum-cryptography-candidate-cracked/ [slashdot.org]. So switching to these new algorithms may be creating new vulnerabilities to deal with a threat that has not yet substantially emerged. It might make sense to start having two tiers of encryption one for data where Store Now, Decrypt Later is a threat, and another for things where they are just not that time sensitive.
      • That reminds me, I need to buy ink for my printer so that I can print out all my passwords in plain text and store them in a fireproof safe for later retrieval. "Store Now, Remember Later".
      • That said, one obvious concern in the other direction is that the encryption schemes which we are hoping to be resistant to quantum computing based attacks have had much less attention given to them (in part due to them simply being much younger), and thus we have less certainty that they are even classically good encryption. And we've had now multiple examples of supposedly quantum resistant algorithms being cracked by completely classical methods. See for example :https://cacm.acm.org/news/nist-post-quantum-cryptography-candidate-cracked/ [slashdot.org]. So switching to these new algorithms may be creating new vulnerabilities to deal with a threat that has not yet substantially emerged.

        Which is why no one is suggesting moving to a post-quantum algorithm alone. What Chrome is implementing is a hybrid key exchange, ML-KEM768+X25519 (the X25519 part is a standard elliptical curve cypher). Unless your implementation is absolutely terrible, you can't decrease security by layering on multiple encryption schemes, so even if ML-KEM is no more secure than ROT13, it still won't introduce any new vulnerability.

    • Are quantum technologies near such capability?

      No.

      So why now?

      https://miracl.com/blog/backdo... [miracl.com]

    • by ledow ( 319597 )

      No, but you don't WAIT for your thing to be compromised when you know it's only a matter of time, when you can literally deploy an alternative now and have 10+ years of real-world testing of it by the time it's actually necessary.

      Secure protocols.... secure things. It's dumb to wait until they're compromised before you do anything.

      And we KNOW for a fact that AES etc. is vulnerable to quantum attacks, and that many governments and companies are producing viable quantum computers that are increasing in size

      • you don't WAIT for your thing to be compromised when you know it's only a matter of time, when you can literally deploy an alternative now and have 10+ years of real-world testing of it by the time it's actually necessary

        I want 10+ years of real-world testing before I adopt it to make sure that NIST isn't pushing us another compromised cryptosystem.

        And we KNOW for a fact that AES etc. is vulnerable to quantum attacks

        Yes, if you use such a small key that you could do the decryption by hand. The question is, will quantum computers ever actually even scale up to the point that this is a real concern? And we don't know the answer, so that does merit some caution, but NIST's prior actions also merit caution.

      • No, but you don't WAIT for your thing to be compromised when you know it's only a matter of time, when you can literally deploy an alternative now and have 10+ years of real-world testing of it by the time it's actually necessary.

        How do you know it is only a matter of time? Are there any known means of enabling exponential scaling of quantum computers?

        And we KNOW for a fact that AES etc. is vulnerable to quantum attacks

        Bullshit.

        and that many governments and companies are producing viable quantum computers that are increasing in size all the time.

        While it is certain analog and quantum computers have a bright future ahead of them and will certainly become far more powerful and far cheaper in the future there is still no exponential scaling happening or that can be reasonably predicted to happen.

        • by ledow ( 319597 )

          Clearly you're an expert in the field and absolutely unarguable with, so I won't bother too much.

          A paper from 2017 (so already 7 years out of date):
          https://www.etsi.org/deliver/e... [etsi.org]

          "This can result in AES-128 being feasible to crack, but AES-256 is still considered quantum resistantâ"at least until 2050"

          Note "resistant" - not proof. And note that 128bit is actually "feasible to crack". And that's if they haven't underestimated a single thing in their analysis. What if they are wrong, what if quantum

    • by brunes69 ( 86786 )

      Imagine classical encryption is cracked via commercially available methods in 2030.

      Now imagine I can open up all of your banking transactions and emails (which I have intercepted and recorded) from the years 2020-2029, and decrypt them.

      Do you think that information has value, or not?

      • Or... 2030 has new quantum computing cracks available, and black hat hackers are now using them. And only THEN do banks decide that they need to upgrade their security, but they can't because also the browsers haven't been updated because Slashdot told them it was too soon, and chip makers haven't updated yet because they were waiting until there was a real quantum hack first before expending valuable profits, so now things remain vulnerable until 2033, and for some slower companies maybe not until 2040...

    • I'd rather fix my crypto before it's broken. I don't want to hear about how my data was stolen, I'd much rather be reasonably assured that it wasn't.
      • Sure, better to be proactive here. Though I do not think we are anywhere close technologically to even try., right? On the other hand, NIST or not who know what we will be able to try to break in the future.

    • No, but given how long it takes to update everyone to new security methods, such as a decade or more, then everyone needs to get ready for this now.

      The computing industry is resistant to change - standards are often about carving ad-hoc or existing solutions into stone rather than doing what is technically best (or in this case, stronger crypto). Ie, stick with the standard that's already out in the field because you need to interoperate.

      Going to something new causes problems. Which is exactly an issue Cho

  • Why do I get the feeling that the "approved" system has backdoors that are already known by interested parties and the experimental one didn't have them or was reluctant to implement them?
    • Why do I get the feeling that the "approved" system has backdoors that are already known by interested parties

      Don't worry - everyone else will figure out a hack before long, and it will be back to equal-opportunity eavesdropping.

  • by gweihir ( 88907 ) on Tuesday September 17, 2024 @08:29AM (#64792449)

    Post-quantum encryption is _not_ ready for prime-time. At this time, it must be regarded as significantly less secure than conventional encryption. In addition, it is completely unclear whether QCs will ever amount to anything. The 12 error corrected QBITs that IBM proudly announced a few days back, are for example enough to factor RSA keys up to 15. That can be done manually with an Abacus. And that is after about 50 years or research. The transistor is about 80 years old at this time, and look what it has scaled too. For QCs it is unclear whether they will ever scale. Hence it is massively premature to rip out well-reviewed ciphers due to the "threat" of QCs and all it does is decrease security.

    • by stooo ( 2202012 )

      a sensible alternative would use both "old" and "new" algorithms in series (i.e. encrpt with one, then encrypt the result with the new one)
      At least until proven.

      • by flink ( 18449 )

        That's exactly what they are doing: EC crypto wrapped in a post-quantum cipher.

      • by gweihir ( 88907 )

        That is rather risky. Layering encryption is something that can decrease your security. At the very least you need to restrict yourself to stream-mode and encrypt in parallel. That comes with other potential problems though.

    • You seem fairly bent on discouraging the adoption of quantum-resistant cryptography. If I assume you're not just being atruistic and expressing real (if not valid) concerns here, what's your game?
      • by gweihir ( 88907 )

        My "game" is understanding how secure cryptology evolves. It requires a decade or two of expert review and attempts to break it. The "post quantum" stuff already has had some really ridiculous failures. And the attacker model is purely speculative. Hence I, rightfully, expect some other agenda here. It would not be the first time that NIST, in orders from the NSA, pushes backdoored or insecure cryptography.

        You, on the other hand, seem to try to manipulate general opinion, by using classical PyOps (and marke

    • That's exactly why the new NIST approved system uses both the new QC resistant key exchange AND the currently used ECDH key exchange.

      That way, you need to break both the older proven key exchange method and the new QC resistant one.

  • What is going to kill us sooner, quantum computing or climate change? Too close to call. Must take measures now.

  • Using Chrome. Only Google can have all my data.

"The eleventh commandment was `Thou Shalt Compute' or `Thou Shalt Not Compute' -- I forget which." -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Working...