HAWK and FAEST
HAWK and FAEST are two post-quantum digital signatures that both advanced to the third round of NIST’s additional-signatures process in May 2026, and they sit at opposite ends of the design space. HAWK is a lattice signature built on the lattice isomorphism problem, prized for being fast and compact while avoiding the tricky floating-point math that complicates Falcon. FAEST is a symmetric-key signature whose security rests on nothing more exotic than AES, the block cipher already trusted everywhere, at the cost of large signatures. Neither is a finished standard. Together they show the two directions NIST is hedging: a better-engineered lattice option, and a signature that leans only on the symmetric primitives the whole field already trusts.
The short version:
- HAWK and FAEST are both NIST Round 3 additional-signature candidates, advanced in May 2026, and neither is a finished FIPS standard.
- HAWK is a lattice signature on the lattice isomorphism problem, a different lattice assumption than ML-DSA, and it’s fast because it uses no floating-point arithmetic, unlike Falcon.
- HAWK’s sizes are moderate: about a 1,024-byte public key and 555-byte signature at NIST level 1, up to a 2,440-byte key and 1,221-byte signature at level 5.
- FAEST is a symmetric-key signature whose only security assumption is AES (plus SHA-3), built with a technique called VOLE-in-the-head, so it rests on primitives already trusted against quantum attack.
- FAEST’s tradeoff is large signatures, several kilobytes at level 1 and tens of kilobytes at level 5, paired with a tiny 32-byte public key.
Picture two ways to prove you own a house. HAWK hands over a compact, well-made deed that a clerk can check quickly, built to a cleaner blueprint than the older lattice deeds so it doesn’t jam in the machine. FAEST skips the specialized paperwork and instead proves ownership by demonstrating you know the combination to the front-door lock, a lock everyone already trusts, without ever saying the combination out loud. That proof is bulky, but it leans only on a lock the whole world has already vetted.
That’s the split. HAWK is the tidier lattice deed. FAEST is the proof that borrows all its trust from AES, the cipher already sitting in nearly every secure system on earth.
What are HAWK and FAEST?
HAWK and FAEST are digital signature schemes submitted to NIST’s additional-signatures process, and they do the standard signature job: a signer produces a value anyone holding the public key can verify came from that signer and stayed unaltered, which is authentication and integrity rather than key establishment or confidentiality. The two are grouped here because they entered Round 3 together, though their foundations are unrelated.
- HAWK is a lattice-based signature. It was the only lattice scheme in the second round of the additional-signatures process, and its security is inspired by the lattice isomorphism problem, a different hard lattice problem than the Module-LWE and NTRU problems under the finalized lattice standards.
- FAEST is a symmetric-key signature. It builds a signature out of a zero-knowledge proof that the signer knows a secret AES key mapping a public message to a public ciphertext, so its security relies only on AES and SHA-3, primitives believed to hold up against quantum attack.
Source: HAWK submission team, project overview, hawk-sign.info; FAEST submission team, project overview, faest.info.
How does HAWK work, and why is it fast?
HAWK signs and verifies using the geometry of lattices, and it’s fast because its designers built the whole scheme to run on ordinary integer arithmetic with no floating-point math. The construction rests on the lattice isomorphism problem, the difficulty of telling whether two lattices are secretly the same lattice viewed through a hidden transformation, and it turns that hard problem into a signature. The flow follows the usual signature moves: the signer holds a secret transformation as the private key, publishes a description of a lattice as the public key, and produces signatures that prove knowledge of the secret geometry, which a verifier checks against the public lattice.
The engineering advantage over Falcon is the point worth remembering. Falcon, the compact lattice signature NIST is standardizing as FN-DSA, needs careful floating-point arithmetic and delicate sampling, which makes it hard to implement safely and hard to run on hardware without good floating-point support. HAWK avoids floating point entirely, so it runs fast and consistently on constrained hardware, with signing and verification under a tenth of a millisecond on a desktop and modest memory use. That combination, a compact lattice signature that sidesteps Falcon’s implementation traps, is HAWK’s whole pitch.
Source: hawk-sign.info, scheme overview and performance notes.
HAWK’s sizes are moderate, in the same neighborhood as the standardized lattice signatures rather than the extremes of the multivariate or hash families.
| Parameter set | NIST level | Public key (bytes) | Signature (bytes) |
|---|---|---|---|
| HAWK-512 | 1 | 1,024 | 555 |
| HAWK-1024 | 5 | 2,440 | 1,221 |
Source: HAWK submission team, specification figures, hawk-sign.info. [OPERATOR VERIFY the HAWK level-III parameter set and re-confirm all HAWK sizes against the current Round 3 specification on hawk-sign.info before these become canonical in a client deliverable; only the level-1 and level-5 rows are captured here.]
How does FAEST work, and what’s its only assumption?
FAEST signs by proving, in zero knowledge, that the signer knows a secret AES key, and its entire security rests on AES being hard to break. This is a fundamentally different idea from every other signature in the running. Instead of relying on lattices, codes, isogenies, or multivariate equations, FAEST relies on the block cipher the world already uses for encryption. The construction works like this:
- The secret. The signer’s private key is an AES key. The public key is a plaintext-ciphertext pair that this key produces, which anyone can hold.
- Signing. To sign a message, the signer generates a non-interactive zero-knowledge proof that they know an AES key mapping the public plaintext to the public ciphertext, bound to the message being signed. The proof reveals nothing about the key.
- Verification. Anyone checks the proof against the public plaintext-ciphertext pair, which confirms the signer knew the key without learning it.
The machinery that makes this practical is a technique the FAEST team calls VOLE-in-the-head, an advance on the MPC-in-the-head approach, which builds the zero-knowledge proof from a simulated secure computation. The strategic payoff is that FAEST introduces no new hardness assumption at all. Its security reduces to AES and SHA-3, symmetric primitives that have been studied for decades and are believed to resist quantum attack, so a break of FAEST would essentially mean a break of AES itself.
Source: faest.info, scheme overview and VOLE-in-the-head description.
The cost of that clean assumption is signature size. FAEST signatures are large, and the public key is tiny.
| NIST level | Public key (bytes) | Signature (approx.) |
|---|---|---|
| 128-bit (I) | 32 | ~4 to 6 KB |
| 192-bit (III) | 48 | ~9 to 15 KB |
| 256-bit (V) | 48 to 64 | ~18 to 27 KB |
Source: FAEST submission team, size figures, faest.info (signature ranges reflect the scheme’s speed-versus-size variants). [OPERATOR VERIFY the exact FAEST signature byte counts per variant against the current Round 3 specification on faest.info before these become canonical in a client deliverable; the ranges here come from the project overview, not a pinned parameter table.]
FAEST offers variants that trade speed against signature size, and a mode based on Even-Mansour that shrinks the signature further, so the exact size depends on which variant a deployment picks.
Why does quantum computing not break either one?
Neither scheme rests on the factoring or discrete-logarithm problems that a quantum computer actually breaks, which is what keeps both in the post-quantum toolbox. Shor’s algorithm efficiently solves factoring and discrete logarithms, which is why RSA and elliptic-curve cryptography fall, but it doesn’t apply to either the lattice isomorphism problem under HAWK or the AES-hardness assumption under FAEST.
- HAWK rests on a lattice problem, and the best quantum attacks on well-chosen lattice problems offer only limited improvement that the parameter sizes absorb, the same reason the finalized lattice standards are quantum-safe.
- FAEST rests on AES, and the only meaningful quantum pressure on AES is Grover’s algorithm, which gives a square-root speedup on key search. AES-128 keeps roughly 64 bits against Grover and larger AES keys keep more, and FAEST’s parameter sets are chosen with that speedup accounted for, so the symmetric basis stays sound.
Source: hawk-sign.info and faest.info, quantum-security rationale.
What is the standardization status of HAWK and FAEST?
Both are Round 3 candidates in NIST’s additional digital signature schemes process, and neither is a finished standard. NIST opened that process in 2022 to add post-quantum signatures beyond the finalized ML-DSA, SLH-DSA, and FN-DSA, with a stated preference for designs on math other than structured lattices, plus room for lattice schemes that clearly outperform what’s already standardized. HAWK and FAEST both advanced to the third round when NIST published its second-round status report, NIST IR 8610, on May 14, 2026, as two of the nine surviving candidates.
Source: NIST IR 8610, Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST Post-Quantum Cryptography Standardization Process, May 14, 2026, csrc.nist.gov.
The correct posture follows from that status:
- Not FIPS, not a deployment default. Neither has a finalized standard, a CMVP validation path, or a long production track record. Both are candidates under active cryptanalysis.
- Two distinct hedges. HAWK is the lattice candidate that earns its place by outperforming and out-engineering the standardized lattice signatures, especially Falcon’s floating-point difficulty. FAEST is the candidate whose value is a security basis that introduces no new assumption, resting only on the symmetric primitives the whole field already trusts.
- A timeline measured in years. A third round in 2026 means any resulting standard is still well out, so the sensible move is to deploy the finalized standards and build for crypto-agility so either scheme could be adopted later as a configuration change.
Source: NIST, “Round 3 Additional Signatures,” project page, csrc.nist.gov.
How do HAWK and FAEST compare to each other and the standards?
The two answer different questions, so the useful comparison lines them up against each other and against the standardized signatures. All do the same signing job; they differ on basis, status, and size profile.
| Property | HAWK | FAEST | ML-DSA | SLH-DSA |
|---|---|---|---|---|
| Basis | Lattice isomorphism problem | AES (symmetric only) | Lattice (Module-LWE) | Hash functions |
| NIST status | Round 3 candidate | Round 3 candidate | Final (FIPS 204) | Final (FIPS 205) |
| Public key | ~1 to 2.4 KB | ~32 to 64 bytes | ~1.3 KB and up | ~32 to 64 bytes |
| Signature | ~555 to 1,221 bytes | ~4 to 27 KB | ~2.4 KB and up | ~7.9 KB and up |
| Standout trait | Fast, no floating point | No new assumption beyond AES | Balanced default | Conservative hash basis |
Source: NIST IR 8610 (statuses), csrc.nist.gov; hawk-sign.info and faest.info (candidate sizes); NIST FIPS 204/205 (standardized sizes).
The practical reading: ML-DSA is what almost every program deploys, the balanced finalized default. HAWK is the lattice candidate to watch if it holds up, a compact signature without Falcon’s implementation traps. FAEST is the conservative-assumption candidate, appealing to anyone who wants a signature that borrows all its trust from AES rather than a newer algebraic problem, provided they can absorb the large signatures.
Common misconceptions
- “HAWK or FAEST is a NIST standard you can use.” Neither is. Both are Round 3 candidates in the additional-signatures process, with no finalized FIPS and no validation path yet.
- “HAWK is just Falcon.” Both are compact lattice signatures, but HAWK rests on a different lattice problem and avoids floating-point arithmetic entirely, which is the engineering advantage it’s built around. Falcon (FN-DSA) needs careful floating point.
- “FAEST is quantum-vulnerable because it uses AES.” The opposite is its whole point. AES resists quantum attack apart from Grover’s square-root speedup, which the parameters absorb, so FAEST rests on one of the best-trusted quantum-resistant primitives.
- “FAEST’s large signatures make it useless.” The large signature is a real cost, but it buys a security basis with no new assumption beyond AES, which is exactly why some planners value it for high-assurance, low-volume signing.
- “These fix harvest-now-decrypt-later.” They don’t touch it. Harvest-now-decrypt-later is a key-establishment risk solved by ML-KEM. Signatures only fail once a quantum computer exists.
Questions people ask
Are HAWK and FAEST NIST standards? No. Both are third-round candidates in NIST’s additional digital signature schemes process, advanced in May 2026, with no finalized standard. The finalized post-quantum signatures are ML-DSA and SLH-DSA, with FN-DSA in draft.
What makes HAWK different from the standardized lattice signatures? HAWK rests on the lattice isomorphism problem, a different lattice assumption, and it uses no floating-point arithmetic, so it avoids the implementation difficulty that makes Falcon (FN-DSA) hard to deploy safely. It’s compact and fast on ordinary hardware.
What is FAEST built on? Only AES and SHA-3. FAEST signs by proving in zero knowledge that the signer knows a secret AES key, using a technique called VOLE-in-the-head, so its security introduces no new assumption beyond the symmetric primitives already trusted worldwide.
Why are FAEST’s signatures so large? Because the zero-knowledge proof that carries the signature is inherently bulky, running to several kilobytes at the lowest level and tens of kilobytes at the highest. The public key, by contrast, is tiny at 32 bytes.
Are HAWK and FAEST quantum-safe? Yes. HAWK rests on a lattice problem the finalized standards also rely on, and FAEST rests on AES, whose only quantum weakness is Grover’s square-root speedup, which the parameters absorb. Neither is touched by Shor’s algorithm.
When would anyone pick FAEST over a lattice signature? When a security basis with no new algebraic assumption matters more than signature size, such as high-assurance, low-volume signing where leaning only on AES is worth the larger signature.
Should my organization deploy HAWK or FAEST now? No. For any signing today, use the finalized standards, ML-DSA by default. HAWK and FAEST are research candidates to track, adopted later through crypto-agility if either becomes a standard.
HAWK and FAEST are the tidier lattice deed and the proof that borrows its trust from AES, two different bets on what the next signature should rest on. Everything here is the map, given freely. When your team needs to decide whether either belongs anywhere on your roadmap, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.