Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Encryption

NIST Finalizes Trio of Post-Quantum Encryption Standards (theregister.com) 20

"NIST has formally accepted three algorithms for post-quantum cryptography," writes ancient Slashdot reader jd. "Two more backup algorithms are being worked on. The idea is to have backup algorithms using very different maths, just in case a flaw in the original approach is discovered later." The Register reports: The National Institute of Standards and Technology (NIST) today released the long-awaited post-quantum encryption standards, designed to protect electronic information long into the future -- when quantum computers are expected to break existing cryptographic algorithms. One -- ML-KEM (PDF) (based on CRYSTALS-Kyber) -- is intended for general encryption, which protects data as it moves across public networks. The other two -- ML-DSA (PDF) (originally known as CRYSTALS-Dilithium) and SLH-DSA (PDF) (initially submitted as Sphincs+) -- secure digital signatures, which are used to authenticate online identity. A fourth algorithm -- FN-DSA (PDF) (originally called FALCON) -- is slated for finalization later this year and is also designed for digital signatures.

NIST continued to evaluate two other sets of algorithms that could potentially serve as backup standards in the future. One of the sets includes three algorithms designed for general encryption -- but the technology is based on a different type of math problem than the ML-KEM general-purpose algorithm in today's finalized standards. NIST plans to select one or two of these algorithms by the end of 2024. Despite the new ones on the horizon, NIST mathematician Dustin Moody encouraged system administrators to start transitioning to the new standards ASAP, because full integration takes some time. "There is no need to wait for future standards," Moody advised in a statement. "Go ahead and start using these three. We need to be prepared in case of an attack that defeats the algorithms in these three standards, and we will continue working on backup plans to keep our data safe. But for most applications, these new standards are the main event."
From the NIST: This notice announces the Secretary of Commerce's approval of three Federal Information Processing Standards (FIPS):
- FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
- FIPS 204, Module-Lattice-Based Digital Signature Standard
- FIPS 205, Stateless Hash-Based Digital Signature Standard

These standards specify key establishment and digital signature schemes that are designed to resist future attacks by quantum computers, which threaten the security of current standards. The three algorithms specified in these standards are each derived from different submissions in the NIST Post-Quantum Cryptography Standardization Project.

This discussion has been archived. No new comments can be posted.

NIST Finalizes Trio of Post-Quantum Encryption Standards

Comments Filter:
  • And get broken before QCs ever scale to useful size (if they do, that is). Switching to these standards is far more of a risk than QCs are.

    • by Hadlock ( 143607 ) on Wednesday August 14, 2024 @10:20PM (#64707450) Homepage Journal

      I think the point here is to just set a baseline and establish the language and procedures for doing it The Right Way, when we figure that out, whatever it is. Encryption standards are introduced and retired on a semi-regular basis, every couple of years at least, as new methods are created, and new strategies to crack them are uncovered.

      • by gweihir ( 88907 )

        I agree. Just putting this into perspective. This is not a "OMG, everybody must move to it now!" new set of standards.

    • Well no, because exactly no one recommends using them by themselves. They're meant to be used with standard key encryption/signing algorithms, so you'd need a QC to break that anyways. Actually at this point laying post-quantum algorithms probably makes sense too, if you're really paranoid.
    • They will probably get broken

      Given sufficient brainpower, most encryption gets broken. However, NIST standards aren't known to be broken and whenever they are suspected to be broken or breakable then a new standard is made. If there wasn't the case then we would all still be using DES.

      Switching to these standards is far more of a risk than QCs are.

      Every cipher is considered breakable which secure systems use a selection of ciphers. In the event that a cipher is sufficiently weakened then the cipher can simply be removed from the list of acceptable ciphers. See also: ssh -Q cipher

      • by gweihir ( 88907 )

        They will probably get broken

        Given sufficient brainpower, most encryption gets broken. However, NIST standards aren't known to be broken and whenever they are suspected to be broken or breakable then a new standard is made. If there wasn't the case then we would all still be using DES.

        Except, if you look at Dual_EC_DRBG, the NIST standard was clearly broken (backdoored) before it was made a standard.

        • Except, if you look at Dual_EC_DRBG, the NIST standard was clearly broken (backdoored) before it was made a standard.

          No, it was suspected that the K table (a set of constants) was backdoored by the NSA. As a result lot more scrutiny has fallen upon US encryption standards since other nations use them too. Also, ciphers have moved toward avoiding needing K tables to eliminate suspicion of a backdoor.

    • by tlhIngan ( 30335 ) <slashdot&worf,net> on Thursday August 15, 2024 @06:18AM (#64707904)

      And get broken before QCs ever scale to useful size (if they do, that is). Switching to these standards is far more of a risk than QCs are.

      That's fine. It's called being proactive. If/when quantum computers are powerful enough to break current encryption (which is currently predicted to be 5-10 years out), we would have had time to vet and switch encryption algorithms.

      That's why it's being done now - there is time to deprecate RSA usage so when quantum computers can break it, it's already obsolete and messages that could be cracked are no longer useful to do so (e.g., financial transactions, e-commerce, etc) or no longer useful (e.g., encrypted messages.

      The whole point is to have something to use when it happens, not suddenly wake up one day and realize that quantum computers can readily break RSA-4096 now what do we do.

      • That's fine. It's called being proactive. If/when quantum computers are powerful enough to break current encryption (which is currently predicted to be 5-10 years out), we would have had time to vet and switch encryption algorithms.

        There should be affirmative evidence to support a course of action.

        That's why it's being done now - there is time to deprecate RSA usage so when quantum computers can break it, it's already obsolete and messages that could be cracked are no longer useful to do so (e.g., financial transactions, e-commerce, etc) or no longer useful (e.g., encrypted messages.

        I don't much mind the various schemes for hybrid agreement / forward secrecy to hedge against the unknown where at least a failure in any one system isn't fatal. At least there you are not losing anything.

        And of course "crypto agility" is always good allowing existing systems the ability to adapt with perhaps only administrative changes as conditions warrant.

        The thing I do very much mind is walking away from something that works and has st

  • Thank-you NIST, you've done a bang-up job yet again of highlighting for the world the algos not to use. NIST can be trusted with exactly nothing since the Dual EC DRBG debacle, and subsequent very questionable NSA-tainted curves. Thank-you, by the say, for eliminating NTRU back in 2020, freeing it up to be trusted and implemented in OpenSSH/TinySSH/PuTTY and others.

    What a crime for an entity with the duty to (I was going to say 'entrusted to' but can't) improve our security to be able to be actually trust

    • by TaliesinWI ( 454205 ) on Thursday August 15, 2024 @12:31AM (#64707586) Journal

      Problem is, there are loads of companies out there that can't just "not trust NIST".

      And it was the NSA that ruined Dual EC DRBG, NIST only made it one of four recommended PRNGs, they didn't mandate anyone use it specifically (and no one other than RSA, after being paid off by the NSA, did.)

      Every time the NSA tries "we're going to develop a standard that has a backdoor we can use" (Clipper, Dual EC DRBG), they get sniffed out and their attempt fails.

      • by HiThere ( 15173 )

        But if they have a list to choose from, you can pick the one you deem best.

      • Problem is, there are loads of companies out there that can't just "not trust NIST".

        A company is free to choose what they want for their own security. And if they are required to conform to government standards for interoperability when liaising with government or others, then that security decision is on them, not the company.

        NIST only...

        NIST only.... nice. Yes, they only chose to make a standard out known broken systems. They have a proven track record of making choices that are not in the best interest of the public. So, since what they are doing now is....choosing a standard, what does that sa

  • @jd has a lower user number than me - there are not that many of those still around.
    I signed up on the first day that user IDs could be created, back in the early Jurassic

    • by Hadlock ( 143607 )

      I had been reading slashdot since the era of the 5 digit user ids but didn't bother to reg an account until much later, unforutnately. I could have been # ~80,000

      • by ebh ( 116526 )

        Same here. I didn't think much of it, since I was way past the chance of getting a four-digit number. I figured I'd look like a n00b forever.

        This has turned out to be true, but not because of my user number. :)

    • by martok ( 7123 )

      I don't remember when I signed up. But you and JD are some of the lowest I've seen lately.

    • by Henriok ( 6762 )
      Hello there!
  • I'm dealing with FIPS-143

Trap full -- please empty.

Working...