Inside the grey box of post-quantum cryptography standards

01 Sep 2026

Note: This article was originally written for Fhenix. None of it is AI written.

If you follow ePrint, ZK Podcast, or one of the many other sources covering cryptography research, you’ll notice there are new cryptographic schemes being proposed on a monthly (if not weekly) basis. Many of these works improve on efficiency and appear in prestigious venues like Eurocrypt or Crypto. We often get asked about the process of going from academic paper to production and why we can’t we just deploy these new peer-reviewed works.

However, this sidesteps a more fundamental question: what cryptography do we use today and why?

In speaking with technical investors who actively fund companies working on novel cryptography and engineers working at such companies, we’ve found there’s little understanding of how cryptography is adopted and the highly influential role (the relaitvely unknown federal agency) NIST has in this process.

This is an extreme oversight as far as we’re concerned, especially when it comes to understanding the transition to post-quantum cryptography and the rise of multi-party/threshold cryptography.

In our three part series, we’ll cover the past, present, and future of NIST, cryptography, and its role in blockchain. As part of this blog post, we’ll cover the past, namely the role NIST has in determining cryptographic standards, how the cryptography standardization process works + its consequences, and what the results from the 8+ year long post-quantum cryptography competition mean for the rest of us.

Our 2nd post will dive into the present, highlighting Ethereum and its transition to post-quantum cryptography along with the somewhat controversial decisions being made on that front. Our final post will cover the future, diving into an active NIST call for multi-party threshold schemes that Fhenix is participating in.

What cryptography do we use and why?

In theory, we could create an app or infra project and deploy any cryptography we conceivably desire in it. However, established applications and infrastructure providers tend to be a lot more risk-averse and for good reason:

  1. Even if a paper is published in an extremely presitigious peer-reviewed venue, there is no guarantee that the construction is truly “secure.” The original Zerocash paper (which formed the basis of the cryptocurrency project Zcash), published at arguably the most prestigious venue for applied cryptography, was later discovered to have a bug. Furthermore, most organizations do not have the ability to vet state-of-the-art cryptography themselves.
  2. Upgrading cryptography can be a highly non-trivial task for engineering and may cause interop issues. This generally means that cryptography must be picked very carefully to prevent unnecessary breaking changes.
  3. Depending on the company’s customers and vendors, there may be requirements or market standards around what crytography can be used. We’ll dive into this shortly!

As a case study, let’s look at Ethereum and what cryptography is used in its stack today…

Dissecting the cryptography used in Ethereum today

We’ll focus on the cryptography employed by users, in the EVM, and for off-chain communication and local storage.

You’ll notice all of this cryptography traces its origins back to NIST.1 At this point, you may be wondering who or what is “NIST” and what are “FIPS?” Well, NIST (aka the National Institute of Standards and Technology) is a US federal agency that holds various “competitions” to determine cryptographic standards, formally known as “Federal Information Processing Standards” (FIPS).

“NIST” and cryptography

NIST dates back to 1901 and was formerly known as the “National Bureau of Standards.” Their website does relatively little to clear up what exactly this agency does but roughly speaking their mission includes anticipating the future, co-developing new technology, and fostering standards. They appear to have a number of laboratories and research efforts across cryptography, computer science more generally, engineering, biotech, energy, and physics.

So why should you care about NIST?

NIST sets the standard (sometimes de jure, often times de facto) of what cryptography should be used by institutions in the US. Their standards are highly influential and often inform what other countries adopt. The vast majority of cryptography you use today originates via NIST competitions and will almost certainly continue to do so for decades to come.

The next question that likely comes to mind is: who has to follow the standards set by NIST?

At this point, things require clarification. Technically speaking, rather few organizations need to “comply with FIPS” which involves a lot more than just using the cryptographic algorithms coming from the accompanying standard. Orgs that must “comply with FIPS” include federal agencies and those that operate systems for the federal government (e.g. certain cloud providers). Compliance includes things like running only approved algorithms with pre-chosen parameter sets, specific version control rules/logging, formal testing by a third party, obtaining certificates, etc. It is a rather tedious process that you definitely do not want to suffer through unless you have to.

Thus, the vast majority of companies are not “complying with FIPS” but are using the underlying cryptography from various FIPS.

Finally, you might wonder: if most companies aren’t required to use the cryptography put out in NIST’s standards, why do they do so anyway?

Likely, risk management and market pressure. The cryptography in NIST standards has been heavily scrutinized by dozens of experts over a multi-year process. The government has decided it’s good enough for their secrets so you should feel safe knowing it’s likely good enough for yours. If something later “breaks” or is found to be insecure, at least the company can point the blame at someone else (NIST). If a company decides on its own to adopt some novel cryptography out of a peer-reviewed paper, they will have to take the bulk of the blame if the scheme is later found to be insecure.

Thus, the vast majority of orgs choose to adopt the underlying cryptography in NIST standards. These standards generally form from open competition calls put out by NIST. We’ll dive into the process next.

Inside the grey box of cryptography standardization

How do we end up with a cryptography standard (say for post-quantum digital signatures)?

It all starts with NIST putting out a formal call for proposals, where they solicit submissions for a particular class of cryptographic algorithms (e.g. digital signatures). They provide detailed guidelines on what must be included as part of the proposal to be considered. These calls are put out quite far in advance of the deadline so competitors have sufficient time to meet the requirements (e.g. spec, security proofs, implementation, performance numbers). Most submissions build upon prior work in the competitors’ own fields (sometimes their own publications) and are not entirely new constructions from scratch.

In reality, this process is a competition that proceeds in multiple rounds across multiple years. Submissions are pitted against one another, with NIST ultimately determining which proposals make it to the next round.

However, the process isn’t completely opaque. NIST often provides reports, detailing what the strengths and weakness are of each proposal and why they decided to eliminate it. Some criteria include operation times (e.g. key generation, encryption, decryption times), size (e.g. key and ciphertext sizes), the underlying security assumptions and their maturity level, resistance to side channel attacks, the level of difficulty to implement the system and the likelihood of implementation errors, and licensing (NIST notes that it prefers algorithms with royalty-free licensing).

While in theory anyone can participate (even sending multiple submissions), in practice the vast majority of submissions come from well-respected cryptographers. Most submissions come from teams of 3+ experts, collaborating across different academic institutions and with industry. NIST generally makes the accepted submissions available for anyone to view so that you read it, see the team members, and comment on the proposals if you notice some flaws/issues. Additionally, NIST often organizes workshops and conferences in which the community at large and the participants can share updates on their work, concerns about proposals, etc.

During this multi-year process, it is not uncommon for cryptographers to break some of the later round proposals. A great example comes from a cryptographer at IBM who broke a post-quantum digital signature scheme called “Rainbow” that had made it all the way to the third round. The resulting paper was aptly titled “Breaking Rainbow Takes a Weekend on a Laptop” and won the author best early career research paper at Crypto 2022.

The (long) road to standardize post-quantum cryptography

All of this takes us to the present and NIST’s most recent call to standardize post-quantum cryptography, specifically a post-quantum key encapsulation mechanism (KEM) and a digital signature. Roughly speaking, a KEM is used to establish a symmetric key between two parties (as symmetric/private key cryptography is a lot more efficient than asymmetric aka “public key” cryptography).

Post-quantum cryptography is cryptography resistant to attacks from a quantum computer. Most public key cryptography we use today is not post-quantum as it relies on elliptic curves. The primary attacks we have to worry about are Shor’s algorithm and Grover’s algorithm; Shor’s algorithm is relevant for public key cryptography (“breaking” the security of elliptic curve based cryptography) whereas Grover’s is relevant to private key cryptography (halving the security level so that we need to accordingly increase the parameters e.g. AES-256 reduces from 256 bits of security to 128 bits of security). We’d recommend this video if you’d like to dive more into quantum computing.

There’s been a lot of speculation from experts (and non-experts alike) on how far out a sufficiently interesting/powerful quantum computer is. We think these opinions matter relatively little as NIST has essentially made a decision on our behalf by disallowing non-post quantum digital signatures and KEMs after 2035.

The competition and its results

The NIST competition to find a post-quantum digital signature and KEM kicked off in December 2016, with submissions due November 2017. There were a total of 69 complete submissions (i.e. submissions meeting the requirements), with submitters presenting at a NIST-organized conference a few months later. These 69 submissions were whittled down to 26 in Round 2 (Jan 2019) and then 7 finalists in Round 3 (July 2020). Competitors often update their submissions as they progress through the rounds, e.g. improving on security and performance, taking into account feedback provided by NIST.

With elliptic curve cryptography compromised, the primary options for a post-quantum future are (1) lattice-based cryptography, (2) hash-based cryptography, and (3) code-based cryptography. If you’re in the crypto space, you may have heard of fully homomorphic encryption (FHE), which relies on lattice-based cryptography. You’ve likely also heard of STARKs, a hash-based proof system used in in some zkVMs. Very few people (ourselves included) have encountered code-based cryptography in the wild or studied it.

On July 2022, NIST determined that 1 KEM and 3 digital signature schemes would be standardized (thus forming the basis of new FIPS); these were CRYSTALS-Kyber (a lattice-based KEM), CRYSTALS-Dilithium (a lattice-based signature), FALCON (another lattice-based signature), and SPHINCS+ (a hash-based signature).

NIST continued its search for another KEM, ideally one not based on lattice cryptography, and decided in March 2025 that HQC (based on structured codes) would additionally form the basis of a new standard.

Name Category Cryptography Benefits Drawbacks
CRYSTALS-Dilithium (FIPS 204) Digital signature Lattice Good performance overall Not strong at any one thing
Falcon (FIPS tbd) Digital signature Lattice Fast sign/verify, smallest bandwidth Floating point arithmetic
SPHINCS+ (FIPS 205) Digital signature Hash Mature cryptography Slow and large
CRYSTALS-Kyber (FIPS 203) KEM Lattice Good performance overall Newer hardness assumption
HQC (FIPS tbd) KEM Code Thorough security analysis Weak performance

KEMs

CRYSTALS-Kyber (renamed ML-KEM by NIST), as noted by NIST, relies on hardness assumptions spanning over a decade of research (thus giving them confidence in its security). It also offers relatively fast key generation times, encapsulation times, and decapsulation times. In terms of public key and ciphertext sizes, these are around 1000 bytes.

HQC, while much less performant than CRYSTALS-Kyber with larger public keys and ciphertexts, serves as the non-lattice based alternative. Essentially, it was the best of the non-lattice based options.

Signatures

FALCON offered the smallest key sizes and signature sizes of the potential post-quantum digital signature schemes making it to the third round. While it exhibited good performance on signing and verification, it was not as competitive on key generation times. Additionally, NIST brought up some concerns around the use of floating point arithmetic leading to implementation errors.

CRYSTALS-Dilithium (renamed ML-DSA by NIST) offered a more balanced profile, offering competitive performance for key generation, signing, and verification as well as good key and signature sizes.

As a backup to the lattice-based choices, NIST chose to standardize SPHINCS+ (renamed SLH-DSA by NIST) as well, as hash-based cryptography is extremely old and is least likely to be broken cryptanalytically. Unfortunately, its performance is problematic. NIST explicitly notes that it is unlikely to serve as a drop-in replacement to ECDSA without “extensive re-engineering.”

What does this mean for cryptography?

Lattice cryptography swept the competition. Across the 8 year process, it became self-evident that the other post-quantum alternatives could not compete with lattice cryptography in terms of performance and bandwidth/size. We expect lattice cryptography to dominate public key cryptography from 2035 onwards.

Given the more conservative security assumptions, we expect an expansion in the use of hash-based cryptography (especially within blockchain settings where upgrades can be trickier) as well as further research into making it more efficient.

What does this mean for the rest of us?

At this point, we hope it becomes clear why we covered the difference between NIST setting de jure vs de facto standards.

For the vast majority of companies, which are not expected to officially “comply with FIPS,” the decision of whether to transition to post-quantum signatures boils down to risk appetite and customer/market expectations. However, as we’ve seen historically, the overwhelming majority of companies end up adopting the underlying cryptography in FIPS.

All of that takes us full circle, returning to Ethereum. What cryptography do they plan to adopt as part of the post-quantum transition? In our next post, we’ll dive into what’s going on in the blockchain ecosystem, the unique considerations blockchain has in choosing cryptography, and the somewhat controversial decisions being made by EF.

  1. There is quite a bit of cryptography in Ethereum that does not come from NIST standards as well (e.g. Poseidon hash, BLS signatures). ↩