← All standards
Standards·22 min

NIST: the standards body behind AES, SHA, and post-quantum cryptography

Almost every algorithm in this catalog traces back to a NIST publication. Here's what NIST actually is, how it picks a winner, and the full list of what it's standardized.

Developer / EngineerSecurity ArchitectGRC / Risk & ComplianceResearcher / AcademicIT Ops / DevOps

A US metrology agency that ended up setting global crypto standards

NIST — the National Institute of Standards and Technology — is a non-regulatory agency of the US Department of Commerce, originally chartered in 1901 to standardize physical measurement (weights, time, physical constants). Its Computer Security Division took on cryptography because the US federal government needed algorithms every agency could rely on, and someone had to specify exactly which ones and how.

NIST publishes two kinds of documents that matter here. A FIPS (Federal Information Processing Standard) is mandatory for US federal systems and is where the actual algorithms live — AES, SHA-2, SHA-3, the post-quantum algorithms. The SP 800 series (Special Publications) is guidance rather than a hard mandate — how to use those algorithms safely, key management practices, random number generation requirements. Almost nothing here is unique to US government use: because NIST's process and output are free, public, and rigorously reviewed, the rest of the world adopted them as the de facto global baseline too.

How NIST actually picks a standard: the open competition model

NIST doesn't design algorithms in-house and declare them standards. For its three biggest decisions — a replacement for DES, a replacement for SHA-1/SHA-2, and a response to the quantum threat — it ran open, multi-year public competitions instead: anyone could submit a candidate, and the entire cryptographic research community was invited to attack every submission in public.

This matters for a reason beyond fairness: a design nobody could break after years of open cryptanalysis by the world's best cryptographers is a far stronger trust signal than a design reviewed only behind closed doors — exactly the property that made the Dual_EC_DRBG story (covered later on this page) so damaging when it broke that pattern.

Three competitions, three current standards

  1. 1997–2000

    AES competition

    15 submissions in round one, 5 finalists, Rijndael selected — became FIPS 197 in 2001.

  2. 2007–2012

    SHA-3 competition

    Keccak selected after NIST wanted a hash function structurally different from SHA-2, in case SHA-2 were ever broken the same way SHA-1 was — became FIPS 202 in 2015.

  3. 2016–2024

    Post-Quantum Cryptography competition

    69 initial submissions; CRYSTALS-Kyber, CRYSTALS-Dilithium, and SPHINCS+ selected — became FIPS 203, 204, and 205 in August 2024.

What NIST has actually standardized

The full list is long, but almost everything covered in this catalog's Learn modules traces back to one of these.

The FIPS and SP 800 documents behind this site's Learn modules

FIPS 197 — AES

The Advanced Encryption Standard itself, published 2001.

FIPS 180-4 — SHS (SHA-2)

The Secure Hash Standard covering the SHA-2 family.

FIPS 202 — SHA-3

SHA-3/Keccak, selected as a structural hedge alongside SHA-2, not a replacement for it.

FIPS 186-5 — Digital Signature Standard

Specifies DSA, RSA, and ECDSA signatures.

FIPS 203 — ML-KEM

The post-quantum key-encapsulation mechanism, finalized August 2024.

FIPS 204 — ML-DSA

The post-quantum signature standard, finalized August 2024.

FIPS 205 — SLH-DSA

The stateless hash-based post-quantum signature standard, finalized August 2024.

SP 800-38D

Block cipher modes of operation — this is the document that specifically defines GCM.

SP 800-56A Rev. 3

Key establishment using discrete-log cryptography — covers Diffie-Hellman and ECDH.

SP 800-90A

Recommendation for random number generation using deterministic random bit generators (DRBGs) — the standard at the center of the Dual_EC_DRBG story below.

SP 800-57 Part 1 Rev. 5

Key management guidance, including the key-size/security-level equivalence table this site's Compare page draws from.

Practice

Which FIPS publication defines AES itself?

Why NIST ran three separate open competitions instead of one

Each competition responded to a specific, different threat. AES replaced DES because DES's 56-bit key had become exhaustively searchable — a computational weakness, not a design flaw. SHA-3 was selected not because SHA-2 had been broken (it hadn't, and still hasn't), but as a structural hedge: SHA-1's break in the mid-2000s showed an entire hash function family can share a fatal weakness, so NIST wanted a backup built on a fundamentally different internal structure (a sponge construction) ready before it was ever needed. The post-quantum competition responds to Shor's algorithm, covered in its own module — a future quantum computer would break RSA, Diffie-Hellman, and ECC's discrete-log math entirely, not just weaken it.

Go deeperWhen the process broke down: Dual_EC_DRBG⌄

NIST's open-competition model is the reason its standards are trusted by default — which is exactly why the one time that trust was seriously damaged is worth understanding in detail. SP 800-90A, the 2006 random-number-generation standard, included an algorithm called Dual_EC_DRBG alongside several others. Independent researchers flagged a strange property as early as 2007: the algorithm's design included constants that, if chosen a certain way, could give whoever chose them a mathematical backdoor into predicting every 'random' output.

The 2013 Snowden disclosures confirmed the suspicion: Dual_EC_DRBG had been championed for standardization with NSA involvement, and the constants in question were plausibly NSA-generated with no public proof they weren't backdoored. NIST withdrew its recommendation within months and later formally removed the algorithm from SP 800-90A. The lasting lesson, still cited in security reviews today, is procedural: a standard is only as trustworthy as the transparency of every constant and design choice inside it — an algorithm that can't be shown to avoid a backdoor should be treated as though it might have one, regardless of who proposed it.

Practice

What specifically made Dual_EC_DRBG different from a normal 'this algorithm turned out to be weak' story?

Knowledge check

Test what you just learned →

10 quick questions, with an explanation for every answer.

Up next

The IETF: RFCs and the protocols the internet actually runs →

TLS, JWT, PKIX certificates, SSH — every protocol module on this site cites an RFC. Here's how the IETF actually produces them, and what "RFC" does and doesn't guarantee.