up:: The New Standards MOC

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 has since been withdrawn. On 29 July 2026 its submission team pulled it from the process, one day after a cryptanalytic attack was published that halves its effective key size. HAWK is a lattice signature built on the lattice isomorphism problem, and it was 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 ever became a finished standard, and FAEST is now one of eight remaining candidates.

Status changed 29 July 2026

HAWK is withdrawn and will not be standardized. NIST’s Round 3 project page records that “the submission team has withdrawn HAWK from the additional digital signatures standardization process.” The trigger was a key-recovery improvement disclosed on 28 July 2026, found by Anthropic’s Claude Mythos Preview model, which reduces HAWK’s effective key size by a factor of two. HAWK was the only lattice-based scheme among the nine Round 3 candidates, so the on-ramp now carries no lattice option. The finalized standards are untouched: ML-KEM, ML-DSA and SLH-DSA rest on different assumptions and Anthropic states the attack “does not impact the other NIST post-quantum cryptographic schemes.” The HAWK material below is kept as a record of the design and of how it fell. See Why HAWK Was Withdrawn for the full account. Sources: NIST, “Round 3 Additional Signatures,” updated 29 July 2026, csrc.nist.gov; Anthropic, “Discovering cryptographic weaknesses,” 28 July 2026, anthropic.com.

The short version:

• HAWK was withdrawn on 29 July 2026 and will not be standardized. FAEST remains a Round 3 additional-signature candidate, and neither ever became a finished FIPS standard.
• HAWK is a lattice signature on the lattice isomorphism problem, a different lattice assumption than ML-DSA, and it was fast because it uses no floating-point arithmetic, unlike Falcon.
• The attack that ended HAWK halves its effective key size, so restoring the claimed security would require doubling the key, which erases the compactness that was its reason to exist.
• 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.

1. 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.
2. 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. NIST’s own third-round assessment of Falcon, the compact lattice signature it is standardizing as FN-DSA, records that its trapdoor preimage sampling algorithm is “fairly involved,” that the implementation “requires the use of operations such as floating-point arithmetic, which leads to difficulties in secure implementations (e.g., for achieving constant-time signing),” and that the complex data structures on top of that make Falcon “significantly more challenging to implement than other lattice signature schemes.” NIST also measured the hardware cost directly: on an ARM Cortex-M4, which has no floating-point support, Falcon signing is much slower than Dilithium signing. HAWK avoids floating point entirely, and its submission reports HAWK-512 signing at 8.54 x 10^4 cycles and verification at 1.48 x 10^5 cycles on x86 “Coffee Lake” with AVX2, with no more than 14 kiB of RAM for any HAWK-512 algorithm, which puts it on ARM Cortex-M0(+) class parts. That combination, a compact lattice signature that sidesteps Falcon’s dependence on a floating-point unit, is HAWK’s whole pitch.

Sources: Bos, Bronchain, Ducas, Fehr, Huang, Pornin, Postlethwaite, Prest, Pulles and van Woerden, “HAWK,” submission specification version 1.1, 5 February 2025, Table 1 (speed in clock cycles) and §1.1.1 Advantages (14 kiB of RAM, no floating-point unit required, ARM Cortex-M0(+) suitability), hawk-sign.info; NIST IR 8413-upd1, “Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process,” §2.2.2 and §4.4.2, csrc.nist.gov, for Falcon’s involved sampling, its floating-point dependence and the resulting implementation difficulty. The HAWK submission itself makes no claim about Falcon.

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 specification version 1.1, 5 February 2025, Table 2 (key and signature sizes in bytes), hawk-sign.info. The level-1 and level-5 rows are captured here.

How does FAEST work, and what does it assume?

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:

1. 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.
2. 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.
3. 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, drawn from the project overview rather than 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.

1. 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.
2. 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, which is why FAEST offers three security levels “corresponding roughly to AES-128, AES-192 or AES-256” rather than a single one.

Sources: hawk-sign.info, HAWK specification, for HAWK’s lattice quantum-security rationale; faest.info, for FAEST’s AES-and-SHA3 basis (“believed to remain secure against quantum adversaries”) and its three security levels; NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final, for Grover’s quadratic speedup and the halved symmetric strength. Neither project site mentions Grover by name.

What is the standardization status of HAWK and FAEST?

FAEST is a Round 3 candidate in NIST’s additional digital signature schemes process and HAWK is withdrawn, so neither is or will become a finished standard on its current footing. NIST opened that process in 2022 to add post-quantum signatures beyond the finalized ML-DSA and SLH-DSA and the draft 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. HAWK left that field on 29 July 2026, withdrawn by its own submission team the day after the attack was published, leaving eight.

Sources: 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, for the nine third-round candidates and for what a selected scheme would augment (FIPS 204, FIPS 205, FIPS 186-5, and SP 800-208); NIST, “Round 3 Additional Signatures,” updated 29 July 2026, csrc.nist.gov, for the HAWK withdrawal. IR 8610 predates the withdrawal and still lists HAWK as advancing.

The correct posture follows from that status:

1. Neither is FIPS, and only one is still running. FAEST has no finalized standard, no CMVP validation path, and no long production track record. HAWK has been withdrawn outright. Candidates sit under active cryptanalysis for exactly this reason.
2. One hedge remains of the two. FAEST’s value is a security basis that introduces no new assumption, resting only on the symmetric primitives the whole field already trusts. HAWK was the lattice hedge, the candidate meant to out-engineer the standardized lattice signatures and Falcon’s floating-point difficulty, and its removal leaves the on-ramp with no lattice option at all.
3. 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 a future scheme could be adopted later as a configuration change.
4. The withdrawal is the argument for agility, made in public. A scheme that cleared two rounds of expert review was removed from the field within a day of the attack going public. Anything planned around a candidate rather than a finalized standard needs to survive that happening again.

Sources: NIST, “Round 3 Additional Signatures,” project page, csrc.nist.gov, which states only that “the submission team has withdrawn HAWK from the additional digital signatures standardization process” and carries no timing; see Why HAWK Was Withdrawn for the dated 28-to-29 July 2026 sequence behind it.

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	Withdrawn 29 Jul 2026	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 and SHA3	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 off the board, and its sizes are kept in the table as a record of what the design offered before the attack. 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

1. “HAWK or FAEST is a NIST standard you can use.” Neither is. FAEST is a Round 3 candidate with no finalized FIPS and no validation path, and HAWK was withdrawn on 29 July 2026.
2. “The HAWK break means lattice cryptography is broken.” It means the lattice isomorphism problem was the wrong foundation for this scheme. ML-DSA and ML-KEM rest on Module-LWE and NTRU, different assumptions entirely, and Anthropic states the attack “does not impact the other NIST post-quantum cryptographic schemes.”
3. “An AI broke a NIST standard.” HAWK was a competition candidate that was never standardized and never deployed. The distinction between a flaw found in a proposal and a break of a fielded standard is the whole story.
4. “HAWK is just Falcon.” Both are compact lattice signatures, but HAWK rests on a different lattice problem and avoids floating-point arithmetic entirely, which was the engineering advantage it was built around. Falcon (FN-DSA) needs careful floating point.
5. “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.
6. “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 and SHA-3, which is exactly why some planners value it for high-assurance, low-volume signing.
7. “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. FAEST is a third-round candidate in NIST’s additional digital signature schemes process, advanced in May 2026, with no finalized standard. HAWK was withdrawn from that process on 29 July 2026. The finalized post-quantum signatures are ML-DSA and SLH-DSA, with FN-DSA in draft.

Why was HAWK withdrawn? On 28 July 2026 an improved key-recovery attack against HAWK was published to NIST’s pqc-forum mailing list, credited to Anthropic’s Claude Mythos Preview model, which found a previously unknown symmetry in the lattice HAWK is built on. The attack reduces HAWK’s effective key size by a factor of two, so matching the original security claim would mean doubling the key and giving up the compactness that justified the scheme. Another cryptographer confirmed the result independently within hours, and the submission team withdrew HAWK the following day. See Why HAWK Was Withdrawn.

Does the HAWK withdrawal affect the encryption I use today? No. HAWK was never standardized and never deployed in any product. The finalized standards rest on different mathematics and are unaffected.

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? Both were designed to be, and neither is touched by Shor’s algorithm. FAEST rests on AES, whose only quantum weakness is Grover’s square-root speedup, which the parameters absorb. HAWK rested on a lattice problem, and what ended it was a classical attack rather than a quantum one.

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 and SHA-3 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. FAEST is a research candidate to track, adopted later through crypto-agility if it becomes a standard. HAWK is withdrawn and has no future path.

---

HAWK and FAEST were the tidier lattice deed and the proof that borrows its trust from AES, two different bets on what the next signature should rest on. One of those bets lost in July 2026, publicly and fast, which is what a standardization process is built to do. Everything here is the map, given freely. When your team needs to decide whether any of it belongs on your roadmap, that’s the work I do.

Last verified 2026-08-04 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.