Symbolic Software

Verifpal Reaches 1.0: A Toy Becomes an Instrument

Sat, 15 Aug 2026 00:00:00 +0000

Verifpal 1.0 is out. Since May 2020, Verifpal has printed the same warning at the top of its analyses: Verifpal is Beta software. Version 1.0 deletes that line. What justifies the deletion is a new paper, Verifpal Seven Years Later: Can a Toy Become an Instrument?, the successor to the 2019 paper that introduced the tool. Two things have changed since then, and the paper accounts for both: what the modeling language can express, rebuilt across last week’s 0.70.0 and 0.80.0 releases, and whether the engine’s answers deserve belief. This post is the whole argument in one place.

The 2019 paper was frank about what it was presenting. It described its own soundness argument as “an incomplete, semi-formal, in-progress set of results,” called its unlinkability queries “especially experimental,” and conceded that its completeness argument rested on “the problematically subjective definition of what constitutes a ‘real-world protocol’.” The reasonable conclusion at the time was that ProVerif and Tamarin were verification tools, and that Verifpal was a teaching aid that resembled one. The blunter version, which the new paper’s title takes up rather than disputes, was that Verifpal was a toy.

Seven years later, the paper re-asks the question, and it tries to answer it the way a skeptic would want it answered: by proving what can be proved, measuring what can be measured, and conceding in print what can be neither.

What the language can now say

A tool that cannot express the protocol in front of you is of no use whatever its theory, so the paper’s first answer to its own question is a list of what the language now covers. The items landed across 0.70.0 and 0.80.0, each of which has its own detailed post; here is the short version.

Diffie-Hellman stopped being special

The 2019 language had a third kind of value alongside constants and primitives: equations, written G^a and G^a^b, with a reserved generator, a limit of two exponents, and their own special case in the parser, the printer, the equational theory, the unifier and the search. They modeled Diffie-Hellman and nothing else. That kind of value no longer exists. Key exchange is written with two ordinary primitives, PUBKEY(a) and DH_KEX(ga, b), and commutativity is a declared field on the primitive’s specification, interpreted by the same machinery as every other rule. The equivalence relation is arranged so that DH_KEX(PUBKEY(a), PUBKEY(b)), the term an attacker can build from two public keys off the wire, is equivalent to no shared secret: the computational Diffie-Hellman assumption, made structural in the term algebra instead of handled as a special case in the engine.

Post-quantum and hybrid key exchange

Removing equations was the precondition for this. A KEM has no exponent to commute, so it could not be expressed through the equation interface at all. KEM_ENCAP and KEM_DECAP are thirty-eight lines of declarative data, absorbed by the rest of the engine without modification, and they make the question we hear most often since recommending post-quantum native design something a model can settle: what does a hybrid actually buy you? Three shipped models are the same protocol, an X25519 leg and a KEM leg fed into one key schedule, differing only in what phase 1 leaks:

model	what leaks in phase 1	confidentiality? m
kem_hybrid_classical_broken.vp	both Diffie-Hellman private values	holds
kem_hybrid_pq_broken.vp	the decapsulation key	holds
kem_hybrid_both_broken.vp	both, together	contradicted

It is the hybrid construction argument as three files you can run in a design review.

Assumptions you can declare, verdicts that carry them

From 0.80.0, a call site can state a weakening assumption directly instead of approximating it with a hand-maintained list of leaked values: SIGN[forgeable](sk, m) costs authenticity, AEAD_ENC[weak](k, m, ad) costs confidentiality, and from phase 2 schedules the break, which is exactly what a harvest-now-decrypt-later adversary is. Scheduling comes with an obligation the paper formalizes: knowledge acquired in a later phase must never justify an action taken in an earlier one, or any key ever leaked would forge any signature ever checked. The annotations feed the ordinary deduction rules, and the design shows in what we did not have to write: once PUBKEY[weak] hands the attacker a private value, the existing reconstruction machinery recomputes every shared secret that value was ever used in, with no Diffie-Hellman-specific rule anywhere.

Two decisions govern how the feature behaves at its edges. An annotation a primitive does not declare is a hard error at load time with an explanation, because an annotation that reads like a check but does nothing is more dangerous than no annotation; malleable parses and is rejected on those grounds, held back until the solver can actually find the two-substitution attacks it would advertise. And every verdict obtained under assumptions is printed beneath the assumptions in force, which travel through the JSON interface too, so a Pass under PUBKEY[weak from phase 1] cannot be quoted as a Pass outright:

verifpal verify pqxdh-weak.vp

2 of 2 verified · 0.03s

  Warning ▲ Analysis performed under 5 declared weakening assumptions:
  Warning ▲ PUBKEY[weak from phase 1](alongterm)
  Warning ▲ PUBKEY[weak from phase 1](blongterm)
  Warning ▲ PUBKEY[weak from phase 1](bs)
  Warning ▲ PUBKEY[weak from phase 1](bo)
  Warning ▲ PUBKEY[weak from phase 1](ae1)
 
     Pass ✓ confidentiality? m1
     Pass ✓ authentication? Alice -> Bob: e1

The model behind that output is PQXDH, Signal’s current session setup, with every Diffie-Hellman public key annotated weak from phase 1 and nothing leaking at all. The one line to look at is the KEM encapsulation key, which carries no annotation. That omission is the hybrid argument in its entirety: discrete logarithm falls, the KEM does not, and the message survives on exactly that difference.

Unlinkability, decided by finding a witness

unlinkability? used to be decided by structural tests that never consulted what the attacker had observed. It is now decided the way the manual always defined it: by searching for a concrete link witness, a value in the attacker’s hands that ties both queried values to one participant, which the trace then reports as the explanation. In the DP-3T contact-tracing model, a leaked day-zero seed links every identifier that phone will ever broadcast, and the trace names the seed, so the fix is visible in the result. The specification table records which argument positions identify a participant, which is how the engine knows that two signatures verifying under one key are linkable while two ring signatures over the same ring are not: a successful ring verification names a set of possible signers and never a member of it, and that declared emptiness is what stands between this query and a false attack on the one primitive whose entire purpose is unlinkability.

Soundness, assuming the solver is broken

The active-attacker search is the part of a symbolic verifier where the difficulty lives, and therefore the part where the bugs live. The 2019 engine searched forwards, enumerating combinations of wire values to tamper with under four tuned parameters, and those parameters, rather than the protocol under analysis, decided which attacks were reachable. The 0.70.0 post describes its replacement: a backward search that starts from each unresolved query and works out what the attacker would need to contradict it.

The paper’s job is different: to say why anyone should believe what that search reports. Its answer is not a correctness proof for the solver. “The theorem we want,” it says, “is not that the solver is correct, but something stronger and easier to check: that the solver’s correctness is irrelevant to soundness.”

The theorem treats the solver as an arbitrary function, an adversarially buggy one included, and shows that a reported attack is real anyway. The structure that makes this provable is the one 0.70.0 shipped: the solver can only propose. Before anything reaches you, a much smaller component checks that the attacker controls every wire slot the proposal writes to, re-derives every term it installs from the attacker’s own knowledge, re-executes the protocol with the substitution in place, and re-tests the query against what the attacker then holds. Recording a query result requires a token whose constructor is private to one module, so “the search cannot record anything” is a fact the Rust compiler enforces rather than a discipline we promise to maintain.

The paper then does the accounting that a claim like this owes its reader.

What a reported attack depends on. A query result can only be recorded through one call site, gated by a token whose constructor is private; the call-site counts are enforced by tests over the source, and unsafe is forbidden crate-wide. The theorem is a reduction: it shrinks what has to be trusted from the whole engine to under a quarter of it, and names the lines that remain. It is not mechanized.

Writing the deduction rules down as an inference system, which the paper required, also found a bug. The closure’s decomposition rule demands that the attacker actually hold a term before opening it, and holding k makes ENC(k, m) openable without making it obtainable: producing it still requires m. A helper in the engine had conflated the two, and on a forty-line model the tool reported the attacker decrypting under a key that the same run separately certified it could not obtain. A false attack, in the passive analysis, with no solver anywhere near it. The repair is one premise in one rule, decompose_is_not_construct.vp now pins it in the test suite, and the episode is in the paper because it is the best evidence we have for doing this kind of writing-down at all: the formalization caught what the test suite had not.

The model that would not finish

A verifier that does not terminate is worse than useless, because you cannot tell a hard protocol from a broken tool. Symmetric-key Needham-Schroeder ships in Verifpal’s examples directory, and for five years, across two implementations of the tool, it did not finish: the analysis ran for minutes without resolving a single query.

The cause turns out to be a clean pattern the paper calls a replay pump. The protocol decrypts a value, hashes it, and encrypts the result under the same key, so its own output is a well-typed input to itself, one level deeper. An attacker that replays the output into the input obtains a term it did not previously hold; the analysis counts new knowledge as progress and goes around again; the next round produces a term nested one level deeper still. On Needham-Schroeder the engine climbed to 213 nested hash applications and roughly 132,000 proposals in its first 45 seconds, with no end in prospect.

What stops the pump in 1.0 is a bound that is read off the model rather than chosen: the attacker may not install a term that nests deeper than anything the protocol itself computes. A protocol that builds deeper values gets a deeper bound (across the shipped corpus it ranges from 4 to 20), and there is nothing to tune. Symmetric-key Needham-Schroeder now completes in about a tenth of a second at one session and 2.4 seconds at the default two, reporting the textbook Denning-Sacco replay, and the paper proves that the analysis as a whole terminates, unconditionally.

The bound excludes a class of attacks: any whose injected term must nest deeper than the protocol builds. So the tool says so, at the exact place the exclusion occurred, without being asked:

verifpal verify replay_pump_reflection.vp

one line of the analysis output

     Info ● Search declined AEAD_ENC(k, HASH(HASH(HASH(HASH(m)))), nil) at
            Bob's e1: it nests deeper than the 4 levels this protocol itself
            computes. Attacks needing a term deeper than the protocol builds
            are out of reach.

A Pass gives you no way of knowing which branches a search declined to walk down, which is what makes undisclosed incompleteness corrosive. This disclosure names the principal, the slot, the term, and the depth the protocol itself reaches, so a reader who worries about deep-construction attacks against this protocol knows exactly where to direct the worry.

Two sessions of every principal

Protocols are deployed concurrently, and some attacks need two instances of one role to exist at the same time. The standard specimen is Millen’s fⁿgⁿ protocol, engineered so that its secrecy break requires two parallel sessions of the responder; an analysis holding one session of each principal cannot even state the attack. This class of protocol was the sharpest objection to Verifpal’s standing as a verifier, and until 0.80.1, released alongside this post, the objection was correct.

As of 0.80.1, every principal enters the analysis as two concurrent sessions of itself, so a two-party model runs as four principal states: Alice and Alice#2, Bob and Bob#2. Each session draws its own fresh values while long-term material stays shared, and the attacker is free to route any session’s traffic into any other. No model needs editing and no syntax was added, because the language has carried the necessary distinction since 2019 without using it: generates was always “fresh in each run,” and knows was always “long-term.” Raising the count is a matter of --sessions, up to 16 sessions per principal.

Here is what that buys on FFGG, Millen’s protocol at n = 2 and the very model the 2019 paper used for its own trace comparison:

verifpal verify ffgg.vp

1 of 1 failed · 0.02s

     Fail ✗ confidentiality? m
            ╭─ Attack trace:
            │ 1. In an earlier session in which the attacker replaced n2#2
            │    with n1, msg2#2 resolved to PKE_ENC(pkb, CONCAT(n1, m, n1#2)).
            │ 2. Attacker replaces msg (sent by Alice to Bob) with
            │    PKE_ENC(pkb, CONCAT(n1, m, n1#2)). (msg was
            │    PKE_ENC(pkb, CONCAT(n1, n2, m)))
            │ 3. Bob's SPLIT(PKE_DEC(skb, msg))? passes — its inputs are
            │    attacker-controlled.
            │ 4. Bob's ASSERT(SPLIT(PKE_DEC(skb, msg))?, n1)? passes — its
            │    inputs are attacker-controlled.
            │ 5. Attacker observes m on the wire.
            ╰▸ m (m) is obtained by Attacker.

The two nonces in that trace are different objects: n1 belongs to one responder session and n1#2 to the other. The attacker uses the second session as an oracle, feeding it the first session’s nonce so that its reply comes back with the tuple rotated, then presents that reply to the first session, whose own checks pass and whose response moves the secret into a position sent in the clear. This is the shape Tamarin’s counterexample for the same protocol takes, and Verifpal finds and narrates it in the names the model declares.

Bounded sessions are still not unbounded replication, and the paper is specific about the two gaps that remain. First, a passing query at k sessions means that no attack was found within k sessions, never that none exists. Second, the repeated runs of any one session share that session’s fresh values, which grants the attacker an equality that true replication would withhold. The engine cannot close the second gap, so it discloses each instance of it: after minimizing a witness, Verifpal re-runs the attack with the target’s own fresh values renamed to the copies a different session would have held. A witness that survives the renaming did not depend on shared freshness. A witness that dies is still reported, with a label. Run the same FFGG model at --sessions 1 and the only route to the secret is exactly such a witness:

verifpal verify ffgg.vp --sessions 1

the same query, one session

     Fail ✗ confidentiality? m
            ╭─ Attack trace:
            │ 1. In an earlier session in which the attacker replaced n2
            │    with n1, msg2 resolved to PKE_ENC(pkb, CONCAT(n1, m, n1)).
            │ 2. Attacker replaces msg (sent by Alice to Bob) with
            │    PKE_ENC(pkb, CONCAT(n1, m, n1)). (msg was
            │    PKE_ENC(pkb, CONCAT(n1, n2, m)))
            │ 3. Bob's SPLIT(PKE_DEC(skb, msg))? passes — its inputs are
            │    attacker-controlled.
            │ 4. Bob's ASSERT(SPLIT(PKE_DEC(skb, msg))?, n1)? passes — its
            │    inputs are attacker-controlled.
            │ 5. Attacker observes m on the wire.
            │ Note: this trace reproduces only because sessions of Bob share
            │ n1. Under per-session freshness this witness does not reproduce;
            │ an attack may still exist by another route.
            ╰▸ m (m) is obtained by Attacker.

Across the corpus, that label survives on 13 of the 153 narrated traces that involve a substitution, Scuttlebutt and TLS 1.3 among them. It asks the reader the one question the engine cannot answer for itself: can the attacker obtain this principal’s fresh value inside the very session it is attacking? For Needham-Schroeder public key the answer is yes, which is why Lowe’s attack is real even though its Verifpal witness carries the label. The label is a request for review, not a verdict.

Concurrency has a price: two sessions cost roughly four times one, because the model handed to the analysis is twice the size. Most models still finish in fractions of a second; a TLS 1.3 handshake takes 7.9 seconds; the slowest analysis in the corpus is the twelve-message Signal model at 307 seconds, which --sessions 1 brings down to 42.

Measuring whose names are in the trace

When a query falls, the thing you are shown was built in two stages. The state that falsifies one query usually carries substitutions that other queries needed, so the witness is first minimized: substitutions are dropped one at a time for as long as the violation keeps reproducing, with every probe run against a scratch context that is not permitted to record results. What survives is narrated as numbered steps of exactly three kinds: a substitution, with the displaced honest values shown in parentheses; a gate, a checked primitive that passed on attacker-controlled input, which is the step a skeptical reader most wants to interrogate and so gets a line of its own; and a derivation, read off the record the deduction rules kept as they ran rather than reconstructed afterwards by a pretty-printer guessing at what must have happened.

The other half of readability is vocabulary. The narrator keeps a table mapping terms back to the names your model gave them, which is why one step of a Signal trace reads Attacker opens e1 with akenc1, obtaining m1. while the engine’s internal record of the same fact runs to seven lines of nested HKDF, MAC, HASH and DH_KEX applications.

How readable is the result, next to what the peers produce? The 2019 paper printed Verifpal’s FFGG attack trace beside ProVerif’s and argued that the former was easier to read. The argument was impressionistic, and the trace it was defending was a state dump. The new paper re-runs that comparison seven years later, against ProVerif 2.05 and Tamarin 1.12.0, and replaces the impression with a measurement: of the identifiers in the region where each tool expresses its counterexample, once each tool’s fixed boilerplate is discarded, what fraction occur in the model the user wrote? The strict reading requires a verbatim match; the lenient reading forgives each tool its decorations, so that Verifpal’s n1#2 and ProVerif’s ~M_14 are treated alike.

protocol	Verifpal	ProVerif	Tamarin's trace graph
FFGG	88.6% strict · 100% lenient	36.9% · 95.1%	67.9% · 76.9%
Unauthenticated DH	86.5% · 86.5%	81.8% · 100%	87.5% · 87.5%
Needham-Schroeder	93.4% · 100%	51.1% · 75.5%	66.0% · 70.0%

Read the caveats before the numbers, because the paper insists on them. The table is not a scoreboard: under a coarser reading that counts every token, including all of Verifpal’s English, Verifpal falls to between 41.9% and 62.9% and Tamarin’s graph beats it on all three protocols, so no absolute percentage is stable, and what survives every reading is only where each tool’s renaming falls. Tamarin is measured on the trace graph it can serialize rather than on its default output, because its default output under --prove is a proof script, an artifact that is not a counterexample at all; which artifact a tool hands you by default is itself a finding. And the sharpest caveat cuts against Verifpal: the reason it can keep your names is the same reason its session count is bounded. Analyzing finitely many sessions lets it privilege the first as the one you wrote and suffix the rest, while a tool that quantifies over unboundedly many sessions has no first session to privilege and must rename every instance. Verifpal’s readability score and its central limitation have the same cause, and the paper says so in as many words.

The comparison would be worthless if the tools disagreed about the verdicts underneath, so the paper first checks agreement across fourteen properties. Twelve are unanimous among the tools that ran, and the two exceptions are examined rather than smoothed over: one is ProVerif returning cannot be proved where the other two exhibit a falsification, the stated price of the coarse abstraction that gives ProVerif its generality, and the other is a Needham-Schroeder-Lowe query on which Verifpal’s use-based authentication predicate and ProVerif’s injective agreement ask different questions and get different answers, with neither tool wrong about its own question.

One more property rides along with the measurement. Every trace Verifpal shows you was re-executed, from a pristine state, to the reported violation before being rendered, and that is a theorem in the paper rather than a habit of the implementation. In the 9 cases out of 153 where no minimized witness could be confirmed to re-execute, the trace says that too, on the trace itself.

This line of work has a specific origin: the paper’s acknowledgments credit the applied cryptography students at the American University of Beirut, “who are the readers this tool is actually for,” and whose difficulty reading attack traces from every tool, ours included, is what turned trace readability from a feature request into a research question.

What it still cannot do

The paper gives its limitations a full section, and none of them is small.

There is no observational equivalence. If the property you care about is that an adversary cannot tell two worlds apart, which is the standard formulation of vote privacy, anonymity and strong secrecy, Verifpal cannot answer it, and no combination of its queries adds up to an answer.

There are no user-defined equational theories. A protocol whose security depends on algebraic structure the built-in table does not model (XOR-based constructions, pairings, small-subgroup and invalid-curve behavior) cannot be modeled faithfully at all, and may be modeled unfaithfully without any complaint from the tool. The fixed table is deliberate, and it is the one design principle unchanged since 2019: a user-supplied theory can fail to terminate or quietly grant the attacker an equality the actual primitive does not have, no tool can tell a deliberate abstraction from a broken one, and both peers constrain their theories too, so the question was never whether the theory is constrained but who constrains it. We stand by that defense, and it does not shrink the gap. No new table row gives Verifpal XOR.

And sessions are bounded. The paper calls this the best case against everything else in it: without unbounded replication, a passing query can be weaker than it looks. We accept the case. It bears on what a passing query means, not on the attacks the tool reports, which are sound however the solver behaves, reproduce as printed, and are the attacks its peers report.

Why “instrument”

The paper chose its final word for three properties a measuring instrument has, and it checks Verifpal against each. An instrument’s readings are characterized, so that you know in which direction to trust them: Verifpal’s are characterized in one direction, since a reported attack is real whatever the solver does, and silence never means security. An instrument’s operating range is documented: the section above is the range, and the paper states it at greater length. And an instrument indicates when it is being read outside its range, which is what the labels in this post are: a declined proposal named at its slot, a shared-freshness note printed on the trace it qualifies, a verdict obtained under a declared weakening assumption printed beneath the assumptions in force.

The paper also names the one place the analogy fails, rather than leaving the reader to find it. The backward search draws whole terms only from a finite basis of terms the protocol computes, and a goal that fails for want of a term outside that basis looks exactly like a goal with no solution, so this incompleteness has no particular place to point to. An instrument’s casing states its range completely; Verifpal’s cannot. What it does instead is print the fact itself at the top of every active analysis: “Where the search needs a whole term at once, it draws only from terms this protocol computes; an attack needing one outside that set is out of reach. Unlike the other limits, this one cannot report where it applied.”

None of this makes Verifpal a substitute for ProVerif or Tamarin, and the paper does not argue that it should be one. The three tools distribute trust differently. Tamarin returns a proof object, the strongest artifact any of them produces, and a reader who can read one should prefer it; reading one, and often completing one, is expert work. ProVerif buys automation and unbounded sessions with an abstraction deliberately coarser than the concrete semantics, and tells you when that abstraction cannot decide your query. Verifpal moves the solver out of the trusted region and hands you an attack you can re-execute by hand without trusting the tool that found it. Its positive claims are the most bounded of the three; its negative claims come with the most checkable object. “A tool can be worth using without being worth using alone,” as the paper puts it; “nobody proposes retiring ProVerif on the grounds that Tamarin proves more.”

Getting it, and what 1.0 commits to

brew tap verifpal.com/source https://github.com/symbolicsoft/verifpal
brew install verifpal

On Windows, scoop bucket add verifpal https://github.com/symbolicsoft/verifpal.git followed by scoop install verifpal. The Workbench runs the release in the browser with nothing to install, and the paper is on the IACR ePrint Archive; its artifact re-runs all three tools on every model and regenerates every number quoted above, the provenance table included.

Verifpal 1.0 adds no features over 0.80.1. It removes a sentence: the beta warning, in place since May 2020, whose job was to say that the tool’s claims about itself had not been written down. They now are, in one paper: the semantics, the deduction rules, the search, the soundness theorem and its 2,751-line residue, the termination bound, the session model, and the limits. The abstract answers the title’s question in one line: Verifpal “has become a different instrument, not a smaller one,” and it “belongs alongside its two peers instead of in their place.”

If you model something and a result looks wrong to you, please open an issue. The paper’s acknowledgments thank the Verifpal users who reported results that looked wrong, because the unlinkability rework began exactly that way. What 1.0 changes is that there is now much more for a report like that to be checked against.

Verifpal 0.80.0: Nuancing Weak Cryptography Modeling and Witness-Based Unlinkability

Sat, 08 Aug 2026 00:00:00 +0000

Verifpal 0.80.0 is out, a few days behind 0.70.0. The two releases do quite different kinds of work, and it is worth separating them at the outset: 0.70.0 changed how you write models, while 0.80.0 changes what a model is able to say.

There are two additions. The first is that a primitive can now be declared broken, using weak, forgeable, and optionally only from a chosen phase onward, so that an assumption which previously had to be approximated with a list of leaked values, or which could not be written down at all, becomes part of the model itself. The second is that unlinkability queries are now decided by searching for a concrete link witness: a value in the attacker’s hands that ties two identities to the same participant. When such a witness exists, Verifpal reports it to you as the explanation.

Unlike 0.70.0, this release asks you to edit nothing. A model with no annotations behaves exactly as it did before, and there is a test in the suite whose only job is to keep that true. The one thing worth re-checking is your unlinkability verdicts, which can legitimately move in either direction; we will come back to why near the end.

Why a model might want imperfect cryptography

In a symbolic model, cryptographic primitives are perfect by construction. A hash is never invertible, a signature is never forgeable, an encryption never gives up its plaintext. This is not a simplification we tolerate; it is the entire point of the approach. Because the primitives are ideal, every attack the tool finds has to come from the structure of the protocol, from a missing check or a reused key or a value that arrives unauthenticated, rather than from a weakness in a cipher. That is what makes symbolic analysis fast, automatic, and worth doing.

But some of the most important questions we ask about protocols are precisely questions about what happens when a primitive stops being perfect. What survives if this cipher is broken in ten years? What does an implementation flaw in one signature scheme cost the rest of the handshake? These questions are about protocol structure too, since they ask how well the design contains a failure, and until now Verifpal could only approximate them.

The approximation was leaks. If you wanted to model “the attacker can now break this Diffie-Hellman”, you handed the attacker the private values with a leaks declaration and let the ordinary deduction rules do the rest. The 0.70.0 post leaned on exactly this technique: the hybrid key-exchange argument was made with three files whose only difference was what phase 1 leaked.

This works well, and it is still the right tool for many jobs. Its limitation is that a leaks declaration enumerates values, while the assumption you are actually making is about a capability. When those two line up exactly, and the list is short, nothing is lost. As a model grows, keeping them lined up becomes your job rather than the tool’s. If you later add a sixth Diffie-Hellman exchange and forget to extend the list, the model quietly proves something weaker than you believe it proves, and nothing in the output tells you so.

From 0.80.0, you can state the capability directly. A primitive call site may carry a bracketed list of declared weakening assumptions, written between the primitive’s name and its arguments:

ga = PUBKEY[weak](a)                    // discrete logarithm: holding ga yields a
s  = SIGN[forgeable](sk, m)             // signatures forgeable without sk
e  = AEAD_ENC[weak, forgeable from phase 2](k, m, ad)

weak means that confidentiality is lost, so that holding the term yields whatever the term was protecting. forgeable means that authenticity is lost, so that the term becomes constructible by someone who does not hold its secret. from phase N means the assumption comes into force from phase N onward, and it binds to the capability it follows; without it, the assumption is in force from the beginning.

Which primitives accept which assumption, and what precisely falls out of each, is declarative data on the primitive specification, the same table that already defines every rewrite and decomposition rule in the equational theory:

assumption	declared by	holding the term yields
`weak`	HASH, PW_HASH	a preimage — every argument
`weak`	ENC, AEAD_ENC, PKE_ENC	the plaintext
`weak`	KEM_ENCAP	the shared secret
`weak`	PUBKEY	the private key
`forgeable`	SIGN, MAC, RINGSIGN, AEAD_ENC	the term itself, forged without its secret

The last row of the weak group is worth pausing on, because of how much it gives us for how little. PUBKEY[weak] says that a public key yields its private half, which is to say that discrete logarithm has been solved. Notice what this implies for Diffie-Hellman: if the attacker takes a public key off the wire and recovers the private value behind it, then it can recompute every shared secret that value was ever used in. That cascade is not something we had to teach the engine. Recall from 0.70.0 that Diffie-Hellman in Verifpal is written with two ordinary primitives, PUBKEY and DH_KEX, with commutativity declared as a field on the specification. Because of that, once PUBKEY[weak] hands the attacker a private value, the existing reconstruction machinery, the same rules that let an attacker rebuild any primitive whose arguments it knows, carries the consequences forward on its own. There is no Diffie-Hellman-specific rule involved anywhere. The model cap_weak_pubkey_dh.vp exists to pin that down, and its header comment says so explicitly, so that a future change which quietly introduces a special case will be caught.

A worked example: the hybrid argument, written as an assumption

Two new models in examples/messaging/ describe PQXDH, Signal’s current session setup, which is X3DH with a signed KEM prekey added and the KEM shared secret mixed into the master secret alongside the four Diffie-Hellman values.

The first model, pqxdh.vp, asks the harvest-now-decrypt-later question in the older style. The attacker records the handshake as it goes past, and then in phase 1 every Diffie-Hellman private value leaks, five of them, named one by one. The message has to survive on the KEM leg alone, and it does.

The second model, pqxdh-weak.vp, is the same protocol with the same adversary stated as an assumption instead. Every Diffie-Hellman public key is annotated, and nothing leaks at all:

principal Bob[
	knows private blongterm, bs
	generates bo, dkb
	gblongterm = PUBKEY[weak from phase 1](blongterm)
	gbs = PUBKEY[weak from phase 1](bs)
	gbo = PUBKEY[weak from phase 1](bo)
	ekb = PUBKEY(dkb)
	gbssig = SIGN(blongterm, HASH(c2, gbs))
	ekbsig = SIGN(blongterm, HASH(c3, ekb))
]

The one line to look at closely is ekb, the KEM encapsulation key, which carries no annotation. That omission is the hybrid argument in its entirety: discrete logarithm falls, the KEM does not, and the model claims the message survives on exactly that difference. The phase[1] block in this model is empty, because the annotation is carrying the whole adversary by itself.

verifpal verify pqxdh-weak.vp

2 of 2 verified · 0.03s

  Warning ▲ Analysis performed under 5 declared weakening assumptions:
  Warning ▲ PUBKEY[weak from phase 1](alongterm)
  Warning ▲ PUBKEY[weak from phase 1](blongterm)
  Warning ▲ PUBKEY[weak from phase 1](bs)
  Warning ▲ PUBKEY[weak from phase 1](bo)
  Warning ▲ PUBKEY[weak from phase 1](ae1)
 
     Pass ✓ confidentiality? m1
     Pass ✓ authentication? Alice -> Bob: e1

The warning block above the results is deliberate, and we would like to explain the reasoning behind it. A passing result obtained under a weakening assumption is a different claim from a passing result obtained without one, and results travel: they get pasted into review documents, quoted in issues, and screenshotted into slides. So a verification performed under declared assumptions now says so every time, listing each annotated term directly above the verdicts. The internal-json interface carries the same list on every result it emits, and the Workbench displays it, so the caveat stays attached to the verdict wherever the verdict goes.

model	the phase-1 adversary is written as	confidentiality? m1
pqxdh.vp	`leaks alongterm, ae1` and `leaks blongterm, bs, bo`	holds
pqxdh-weak.vp	`PUBKEY[weak from phase 1]` on every DH key; nothing leaks	holds

Both models report the same result code, which is a good sign: the new mechanism reproduces what the old technique already established. What differs is what each model claims, and how each behaves as it grows. The annotated version covers any key derived through an annotated PUBKEY, whether or not the author remembered that particular key was there.

What the annotation does to the master secret. All five inputs to PQXDH's master secret are unavailable to the attacker during phase 0. When discrete logarithm falls in phase 1, the four Diffie-Hellman legs open together, including any key that a hand-maintained list of leaks might have missed, while the KEM leg, which was never annotated, stays closed and keeps m1 sealed. This is the hybrid argument, and the model now states it in those terms.

Assumptions that arrive later

There is a class of assumption that leaks approximates awkwardly, and one that it cannot express at all. The second case is easiest to see in a small model, cap_weak_phase_delayed.vp, which is about twenty lines long:

principal Alice[
	knows private k
	knows private m_now
	knows private m_later
	e_now = AEAD_ENC(k, m_now, nil)
	e_later = AEAD_ENC[weak from phase 2](k, m_later, nil)
]

Read the two encryptions carefully: they use the same key. The result code is c0c1, meaning that m_now stays confidential for the whole run, while m_later, recorded off the wire back in phase 0, opens once phase 2 arrives.

It is worth trying to write this with leaks before reading on, because the exercise is short and the failure is instructive. Leaking k breaks both messages, since both were encrypted under it. Leaking m_later assumes the very thing we wanted the tool to derive. There is simply no value whose disclosure expresses “the attacker becomes able to invert this particular encryption, at this particular time”. The assumption is about an ability rather than about a secret, and it is scheduled rather than immediate.

This is the distinction the two mechanisms now divide between them. leaks hands the attacker values. A capability grants the attacker abilities, optionally on a timetable. Harvest-now-decrypt-later scenarios are the obvious beneficiaries, since their entire premise is that data collected today becomes readable under a capability the adversary does not yet have.

Why `weak` and `forgeable` are two separate assumptions

The 0.70.0 post made a point of keeping properties apart: reading a message and forging one are different powers, and Verifpal reports them as different queries. When we designed capabilities, the same separation had to hold for assumptions, which is why there are two words here rather than one general notion of “broken”.

The case that settles the argument is AEAD_ENC[forgeable]: a ciphertext that an attacker can produce but still cannot read. That combination sounds unusual, but it is exactly what an authenticity failure without a confidentiality failure looks like, and a single combined assumption could not express it. The model cap_forgeable_aead.vp keeps the two from collapsing back together:

verifpal verify cap_forgeable_aead.vp

1 of 2 failed

  Warning ▲ Analysis performed under 1 declared weakening assumption:
  Warning ▲ AEAD_ENC[forgeable](k, m, ad)
 
     Pass ✓ confidentiality? m
     Fail ✗ authentication? Alice -> Bob: e
            ╭─ Attack trace:
            │ 1. Attacker replaces e (sent by Alice to Bob) with
            │    AEAD_ENC(k, nil, ad). (e was AEAD_ENC(k, m, ad))
            │ 2. Bob's AEAD_DEC(k, e, ad)? passes — its inputs are
            │    attacker-controlled.
            ╰▸ e (e), sent by Attacker and not by Alice, is successfully
               used in AEAD_DEC(k, e, ad)? within Bob's state.

Step 2 of that trace is the one to examine. Bob’s decryption is checked, marked with ?, which normally means that a failure halts him. Here it passes, on a ciphertext Alice never produced, because the assumption says such ciphertexts can be manufactured. The narrator prints that step on a line of its own rather than leaving it implicit, since it is the step a careful reader will want to see justified. Meanwhile confidentiality? m still passes, because forgeability says nothing whatsoever about reading. The model’s header comment records what it is guarding: if that confidentiality query ever starts failing, weak and forgeable have been merged somewhere in the engine and the distinction has stopped doing its job.

What happens when an assumption does not apply

A declared assumption reads, to anyone reviewing the model, like a check that was carried out. That creates a responsibility for the tool. If SIGN[weak] were to parse and then quietly do nothing, every reader of that model would come away believing something about it that is not true, and they would have no way of noticing. An annotation that silently does nothing is therefore more dangerous than no annotation at all.

For that reason, every capability is validated against the primitive specification when the model is loaded, and the diagnostics try to name the assumption you probably intended:

three annotations that do not get to run

refused at load time

Error: cap_err_sign_weak.vp:11:2: sanity error: SIGN provides authenticity,
not confidentiality; did you mean `SIGN[forgeable]`?
   s = SIGN[weak](sk, m)
   ^^^^^^^^^^^^^^^^^^^^^
 
Error: cap_err_hash_forgeable.vp:10:2: sanity error: HASH has no secret
argument; anyone who knows its inputs can compute it
   h = HASH[forgeable](m)
   ^^^^^^^^^^^^^^^^^^^^^^
 
Error: cap_err_aead_malleable.vp:12:2: sanity error: malleability of an
authenticated primitive is an authenticity break; did you mean
`AEAD_ENC[forgeable]`?
   e = AEAD_ENC[malleable](k, m, ad)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Each message tries to teach something rather than merely refuse. SIGN[weak] is rejected with a reminder of what a signature is for. HASH[forgeable] is rejected because a hash has no secret argument, so there is nothing for forgeability to bypass: anyone who knows the inputs can already compute the output. The same principle extends to time: weak from phase 5 in a model that never reaches phase 5 is a hard error, not an assumption that quietly never fires.

The third message deserves a fuller explanation, since malleable is in the vocabulary and parses correctly, yet no primitive declares it, so every use of it is rejected. It was designed and partially built during this release cycle and then deliberately held back. The attacks that malleability enables generally require two coordinated substitutions on the wire, and the solver’s goal-directed search cannot presently derive the ciphertext goal that would force them. Shipping the annotation anyway would have meant advertising a class of attack that the engine could not actually find, and a model author would read a passing result as evidence of resistance to malleability when it was really evidence of a search limitation. Rejecting the word with an explanation seemed much better than that, so it stays reserved until the solver can honor it.

Two further guarantees are worth stating plainly, because they are what let you adopt this feature without auditing your existing work. First, weak, forgeable, malleable and from are contextual keywords: they are recognised only inside the parameter brackets, where no constant can appear. A model that already uses weak or from as a constant name is unaffected. Second, a model with no annotations produces byte-identical behaviour to before, and cap_noop_annotated.vp holds an annotated model to the exact verdicts of its unannotated twin.

That second guarantee rests on a design decision that we think is interesting in its own right. Capabilities are deliberately invisible to term hashing and to equivalence, so an annotated term and its unannotated twin count as the same cryptographic object throughout the engine. The assumptions live instead in a model-level index that the engine consults separately. The reason is that attacker knowledge deduplicates values by equivalence: if the engine read capabilities off whichever copy of a term it happened to be holding, then the outcome could depend on whether the annotated or the unannotated copy of a value reached the attacker first, which in turn depends on the order in which principals were walked. Keeping the annotation out of the term and in an index removes that possibility entirely. And because capabilities feed the ordinary deduction pipeline, the soundness argument from 0.70.0 carries over untouched: the solver still only proposes, and validation still re-executes every proposal against real attacker knowledge before any result is recorded.

Unlinkability, decided by finding a witness

The other half of this release concerns a query we had been deciding badly. unlinkability? asks whether an attacker can tell that two values belong to the same party, which is the property that pseudonymous identifiers, rotating beacons and anonymous credentials are built to provide. Verifpal decided it with two structural tests, and we now think both were the wrong shape.

The first test failed the query whenever a queried value contained no fresh constant. That reports a property of the model as though it were an attack, and worse, it disagreed with Verifpal’s own freshness? query, which asks about the very same thing and asks it correctly. The second test failed the query when two queried values were outputs of a single primitive application that the attacker could rebuild. Because it could only ever compare siblings from one application, linkability across sessions or epochs, which is the kind privacy protocols actually worry about, was invisible to it by construction. Neither test consulted what the attacker had observed, which is a strange thing for a decision about an attacker’s knowledge.

Verifpal now decides unlinkability the way the User Manual has always defined it, by searching for a concrete link witness: a value the attacker holds which ties both queried values to one participant. There are three kinds of witness, tried in order of cost:

witness	the attacker exhibits	the trace reads
observed equality	both values in hand, and they are the same secret-dependent value	"…because both are the same value (tok1)"
identifying check	a checked primitive that succeeds over both values under one participant's key	"…because SIGNVERIF succeeds for both under ga"
common secret origin	one held secret from which it can recompute both values	"…via sk0a"

The third kind is the one the old procedure could not see at all, and a contact-tracing model shows why it matters. In dp3t_root_leaked.vp, each phone derives its broadcast identifiers from a daily seed, and each day’s seed is the hash of the previous one:

EphID00A, EphID01A, EphID02A = HKDF(nil, SK0A, BroadcastKey)
// the next day:
SK1A = HASH(SK0A)
EphID10A, EphID11A, EphID12A = HKDF(nil, SK1A, BroadcastKey)

EphID00A and EphID10A come from different days, and from different HKDF applications, so the old sibling test had no way to relate them. Leak the day-zero seed, and the new procedure finds the connection immediately:

verifpal verify dp3t_root_leaked.vp

one query of three

     Fail ✗ unlinkability? ephid00a, ephid10a
            ╭─ Attack trace:
            │ 1. Attacker is handed sk0a by a leaks declaration.
            ╰▸ Attacker links ephid00a and ephid10a via sk0a.

A single leaked seed links every identifier that phone will ever broadcast, in every epoch, because HASH(SK0A) and each HKDF above it can be recomputed from the root. This is seed-compromise linkability, and being able to name the seed as the witness is what makes the result useful: the fix is visible in the trace itself.

Two conditions that keep a witness honest

A search that reports links is only useful if the links are real, so two conditions gate every witness. They are worth understanding if you write privacy models, because they explain results that might otherwise look conservative.

The first is observability. Both queried values must have travelled on the wire or been leaked. A value the attacker cannot reach cannot be linked, no matter what it is derived from, since linkage is a statement about what an observer can conclude. Related to this, when the search tries to reconstruct values from a candidate secret, it first withholds the queried values themselves from the attacker’s knowledge. The reason is worth stating: merely receiving a value tells you nothing about whose it is. Only being able to recompute it from something that identifies a participant does. Reconstructing a value the attacker was simply handed would be circular, and the search declines to do it.

The second condition is that neither queried value may be attacker-authored. An active attacker that overwrites two slots with one value of its own has manufactured the very equality it would then be reporting, which is not an observation about the protocol at all. unlink_injected_equality.vp pins that this is never counted as a witness.

That restriction applies to the linked values themselves, not to the attacker’s activity in general. Attacker actions upstream still count, and they should. In unlink_active_links.vp, the attacker substitutes its own Diffie-Hellman key into the handshake, and the session key that results becomes the common origin for two tokens that the victim went on to compute honestly:

│ 1. Attacker replaces ga (sent by Alice to Bob) with PUBKEY(nil). (ga was PUBKEY(a))
│ 2. Attacker observes gb on the wire.
│ 3. Attacker constructs k from gb, nil.
╰▸ Attacker links tok1 and tok2 via k.

Both queried tokens are Bob’s own values, computed by Bob, so the witness describes something real about the protocol’s structure, not an artifact of the query. The boundary sits precisely at authorship of the linked values, and nowhere earlier.

There is one more restriction, and it is our favourite illustration of how much care the identifying-check witness needs. Consider two models with the same structure and opposite verdicts:

model	Bob verifies with	unlinkability?
unlink_signature_links.vp	`SIGNVERIF(ga, m, s)?`	contradicted — SIGNVERIF succeeds for both under ga
unlink_ringsign.vp	`RINGSIGNVERIF(ga, gb, gc, m, r)?`	holds

Two ordinary signatures verifying under one key are linkable, and the reasoning is exactly what a student would give: the verification key names the signer, so a successful SIGNVERIF over both signatures identifies them as coming from the same party. Two ring signatures over the same ring are not linkable, even though RINGSIGNVERIF also succeeds over both, because a successful ring verification names a set of possible signers and never a member of it. The engine knows the difference because the specification table records which argument positions identify a participant: SIGNVERIF declares its key argument as identifying, and RINGSIGNVERIF deliberately declares none. That declared emptiness is the only thing standing between this query and a false attack against the one primitive whose entire purpose is unlinkability, which is why the two models sit next to each other in the test suite.

From structural tests to a witness the attacker has to exhibit. The old procedure answered questions about the model's syntax. The new one asks for a value in the attacker's hands that ties both queried values to one participant, and prints whichever witness it finds as the trace. Like the rest of the tool, it is sound for attacks and incomplete: a reported link is real, and a passing result means that this search found no witness.

If you have unlinkability queries in existing models, please re-run them, because verdicts can move in both directions and both movements are corrections. Models that used to fail on the freshness clause will now pass, since a value the attacker can neither reach nor observe cannot be linked. Models with a compromised seed high in a derivation chain may now fail where they previously passed, which is the case the old procedure was structurally unable to detect. In both directions, a failing query now hands you a witness you can check by hand rather than a condition you have to take on faith.

Getting it, and what to re-check

brew tap verifpal.com/source https://github.com/symbolicsoft/verifpal
brew install verifpal

On Windows, scoop bucket add verifpal https://github.com/symbolicsoft/verifpal.git followed by scoop install verifpal.

There is no migration this time. Annotations are entirely opt-in, an unannotated model behaves as it did under 0.70.0, and the result code format is unchanged. Two things are worth your attention. Re-run any model containing an unlinkability? query, and read the witness if the verdict has changed. And look at any leaks declaration that was standing in for “this primitive is broken”, since it may now be expressible directly, with the added benefit that anyone reading the output will see the assumption stated alongside the result.

The rest of the toolchain is current. The Workbench runs 0.80.0 and displays declared weakening assumptions alongside results, internal-json attaches the assumption list to every result it emits, the Verifpal User Manual documents both additions, and the VS Code extension (1.0.12) and Neovim extension highlight the new syntax.

If you model something and a result looks wrong to you, please open an issue. The unlinkability rework in this release began with noticing that the old procedure disagreed with the tool’s own manual and its own freshness query, and that sort of noticing is how the tool improves.

Verifpal 0.70.0: Post-Quantum Key Exchange, and an Attacker That Works Backwards

Wed, 05 Aug 2026 00:00:00 +0000

Verifpal 0.70.0 is out. It is the biggest change to the Verifpal language since the project started, and the first release in years that asks you to edit your existing models, so this post goes through what changed and why.

Three things landed. Diffie-Hellman equations are gone: G^a is now PUBKEY(a), ga^b is now DH_KEX(ga, b), and the ^ operator no longer exists. There is a new key encapsulation mechanism, KEM_ENCAP and KEM_DECAP, for modelling post-quantum and hybrid key exchange. And the active attacker has been rebuilt around a different way of searching for attacks, and around explaining them, because an attack Verifpal finds is now narrated to you as a numbered sequence of things the attacker does, rather than dumped as a pile of state for you to decode.

If you have not used Verifpal before: you describe a protocol in a small language (who knows what, who generates fresh values, who sends what to whom, what gets hashed, signed and encrypted) and then you write down the security properties you want, as queries. Verifpal plays an attacker on the network, reading everything and, if you ask for an active attacker, tampering with anything you have not explicitly protected. It then tries to break those properties. If it cannot, your protocol holds against every attack Verifpal knows how to look for, under the model you wrote. If it can, it shows you how, step by step.

An example: one missing character

Signal’s session setup was, for a decade, X3DH. Since 2023 it has been PQXDH, the same construction with a KEM encapsulation mixed in, a shape the primitives introduced later in this post can now express. This example models the classical X3DH. Bob publishes a bundle of public keys in advance, including a signed prekey: a medium-term key carrying a signature from his long-term identity key. Alice fetches the bundle, checks that signature, and mixes four Diffie-Hellman values into a master secret (three, when Bob has run out of one-time prekeys; this model includes one). The Double Ratchet takes over from there and gives every message its own key.

In Verifpal, Alice’s signature check looks like this:

_ = SIGNVERIF(gblongterm, gbs, gbssig)?

The ? is what makes it a check. It tells Verifpal that Alice stops if verification fails. Without it, Alice computes the verification, discards the result and carries on. That is a realistic bug: the line is present, it calls the right function with the right arguments, and only the return value is missing.

Below is Verifpal 0.70.0 on a model of X3DH plus three Double Ratchet messages, with that ? removed. This model and the correct one both end with phase[1], in which Alice and Bob leak their long-term identity keys. That is how you ask Verifpal about forward secrecy: when these keys are compromised later, do the earlier messages stay secret?

verifpal verify signal_unchecked_signature_forward_secrecy.vp

1 of 6 failed · 0.28s

     Fail ✗ confidentiality? m1
            ╭─ Attack trace:
            │ 1. Attacker replaces gbs, gbo (sent by Bob to Alice) with
            │    PUBKEY(nil), PUBKEY(nil). (gbs was PUBKEY(bs); gbo was PUBKEY(bo))
            │ 2. Attacker observes e1 on the wire.
            │ 3. Attacker observes gae2 on the wire.
            │ 4. Attacker constructs akshared1 from gae2, nil.
            │ 5. Attacker constructs gbs from nil.
            │ 6. Attacker is handed alongterm by a leaks declaration.
            │ 7. Attacker constructs DH_KEX(gbs, alongterm) from gbs, alongterm.
            │ 8. Attacker observes gae1 on the wire.
            │ 9. Attacker is handed blongterm by a leaks declaration.
            │ 10. Attacker constructs DH_KEX(gblongterm, ae1) from gae1, blongterm.
            │ 11. Attacker constructs DH_KEX(gbs, ae1) from gae1, nil.
            │ 12. Attacker constructs amaster from DH_KEX(gbs, alongterm),
            │     DH_KEX(gblongterm, ae1), DH_KEX(gbs, ae1), DH_KEX(gbs, ae1).
            │ 13. Attacker constructs arkba1 from amaster, nil, nil.
            │ 14. Attacker constructs ackab1 from akshared1, arkba1, nil.
            │ 15. Attacker constructs MAC(ackab1, nil) from ackab1, nil.
            │ 16. Attacker constructs akenc1 from MAC(ackab1, nil), nil, nil.
            │ 17. Attacker opens e1 with akenc1, obtaining m1.
            ╰▸ m1 (m1) is obtained by Attacker.
     Pass ✓ authentication? Alice -> Bob: e1
     Pass ✓ confidentiality? m2
     Pass ✓ authentication? Bob -> Alice: e2
     Pass ✓ confidentiality? m3
     Pass ✓ authentication? Alice -> Bob: e3

The order of the steps matters here, so it is worth walking through them.

In step 1, before anything has been encrypted, the attacker swaps two of Bob’s public values for its own. That works because Alice’s signature check is not a check. At that point the attacker still cannot read anything: X3DH mixes four Diffie-Hellman values into the master secret, and two of them involve keys it does not have.

Then phase 1 arrives and the long-term keys leak. Two of the four Diffie-Hellman values now come from the leak, and the other two come from the substitution made much earlier, because PUBKEY(nil) is a public key whose private half the attacker knows. The master secret completes, the key schedule runs forward, and m1 opens.

The substitution has to be planned before it can be used. Swapping Bob's public values in phase 0 gains the attacker nothing at the time; it only pays off once the long-term keys leak in phase 1. A search that judges each substitution by what it immediately reveals will not find this.

The queries that passed are worth reading too, because they tell you where the damage stops.

m2 and m3 survive because the Double Ratchet heals. By the second message the key schedule has moved on to ephemerals the attacker never touched, and touching them now would fail a checked decryption on the far side and halt the protocol. Verifpal is reporting the boundary of the break as well as the break itself, which is usually the more useful half for a protocol designer.

All three authentication queries also pass. The attacker reads m1, but it never gets Alice or Bob to accept a message the other one did not send. Reading and forging are separate properties, and the tool keeps them separate.

The whole analysis takes 0.28 seconds.

How the search finds it

Seventeen steps, two simultaneous substitutions on one message, and a payoff a full phase later. That combination is why the search engine was replaced.

The old active attacker searched forwards: pick some combination of wire values to replace, try it, see what the attacker learns. The number of combinations grows quickly, since six controllable values already give you six single substitutions, fifteen pairs and twenty triples, so the search needed a depth limit and a per-principal budget. Once those exist, they decide which attacks are reachable, rather than the protocol deciding.

Signal is the clearest example. The classic man-in-the-middle against X3DH needs three public keys replaced at the same time, and no affordable budget reliably got there. Whether Verifpal found it came down to a constant that could not be justified by looking at the model.

The new engine starts from the query instead. Given an unresolved query, what would the attacker need to contradict it? That requirement is broken into subgoals. Each subgoal is discharged against something the attacker already holds, or against the shape of what a principal is about to compute. A subgoal that can only be discharged under a particular substitution forces that substitution as a binding.

An attack requiring four simultaneous substitutions is then not a four-element combination that has to be affordable. It is four bindings, each forced independently, merged at the end.

The difference is the direction the search runs. Forwards, the number of combinations is a cost that has to be paid, and a cap ends up deciding what is reachable. Backwards, nothing is enumerated: each subgoal forces at most one binding, and a simultaneous substitution is what you get when several independent requirements agree.

Termination now comes from the structure of the search rather than a cap on it. Goals are memoised, so the same question is never answered twice. A goal that ends up depending on itself is cut as a cycle. The two rules that could otherwise generate unboundedly many new terms are restricted to a finite basis drawn from the protocol. Each of those is a property of the term algebra that you can check by reading it.

The old engine is gone: verifyactive.rs, inject.rs and mutationmap.rs, 1,624 lines between them, along with the rayon dependency that parallelised the sweep. There is no SearchConfig in the new code, no depth cap, and nothing to tune.

Why a reported attack can be trusted

Replacing the search engine in a verification tool is risky in one specific direction. Verifpal is sound but incomplete by design: the search may miss an attack, but any attack it reports has to be real. A missed attack is a disappointment. A false attack costs someone a day of work and their trust in the tool.

So soundness is enforced by the structure of the code rather than argued for in a comment. No module under src/solve/ can record a query result. The solver only proposes a substitution. Every proposal is materialised into a real principal state, re-executed through the ordinary analysis pipeline, and re-checked against actual attacker knowledge before anything is allowed to resolve. A bug in the solver costs a missed attack and cannot produce a false one.

The validator also owns one more check that does a lot of work: a substituted term that reduces back to the honest value is a replay, not a forgery. A replay can still be an attack, which is what freshness? queries exist to catch, but it never makes a principal accept a message its partner never sent, and conflating replay with forgery is one of the easiest ways to produce a false authentication result. Four models in the test suite exist to hold that line.

How the analysis fits together. A model is parsed and checked once. The analysis then runs once per phase: attacker knowledge is seeded from what the wire and the leaks declarations make available in that phase, values are resolved and rewritten, and the deduction rules run until nothing new can be learned. Query evaluation is a separate step that never interleaves with that loop. Under an active attacker, unresolved queries are solved backwards, and anything validation uncovers feeds the next round of deduction.

Making the attack readable

A verifier that prints confidentiality? m1 and stops has done the easy half of the job. Knowing that something is broken is useful. Knowing what the attacker does is what lets you fix it, review it, argue about it, or teach it. Verifpal used to print the attacker’s knowledge set and the mutated state, and leave you to reconstruct the story from that yourself, which is a difficult reading exercise on anything the size of Signal.

So the engine does that work now. When a query resolves, two things happen before you see anything: the witness is minimized, and then it is narrated.

Minimizing: dropping everything the attack did not need

The solver pursues goals for every unresolved query at once and installs the union of the bindings it collects. That is the efficient thing to do, but it means the state that finally answers your query usually carries substitutions that some other query needed.

The forward-secrecy model from the top of this post is a good illustration. Analysing it, Verifpal made 1,805 proposals, and the one that broke confidentiality? m1 replaced five values on the wire simultaneously. You can watch this yourself by setting VERIFPAL_SOLVE_DEBUG=1, which logs every proposal the solver makes:

VERIFPAL_SOLVE_DEBUG=1 verifpal verify signal_unchecked_signature_forward_secrecy.vp

1805 proposals

[solve] Alice ran=true [gbs=PUBKEY(nil) gbo=PUBKEY(nil) gbssig=nil gbe=PUBKEY(nil) e2=nil]
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        the two the attack needs         the three the minimizer drops

The trace you actually saw named two of them. The other three went away one at a time, each dropped because the query kept resolving without it. gbssig is Bob’s prekey signature, and the attacker never needs to touch it precisely because Alice is not checking it. gbe and e2 belong to the second message, which has nothing to do with m1.

Minimization is deliberately paranoid, because a minimizer that cheats produces a trace that does not reproduce. Every probe re-runs the attack through the same re-execution path the search itself uses, in a scratch analysis context that is not permitted to record results. Each probe also re-seeds attacker knowledge from the passive baseline rather than from everything the attacker knew at the end of the search: knowledge only ever grows, so probing against the final state would make every substitution look droppable. And if nothing replays at all, Verifpal says so and reports only the derivation, instead of naming substitutions that may not be the ones that mattered.

Narrating: three kinds of step

What survives minimization gets rendered as numbered steps, of which there are exactly three kinds.

A substitution, grouped per wire message rather than one line per value, with the honest values in parentheses so you can see what was displaced:

1. Attacker replaces gbs, gbo (sent by Bob to Alice) with PUBKEY(nil),
   PUBKEY(nil). (gbs was PUBKEY(bs); gbo was PUBKEY(bo))

A gate: a checked primitive that passed even though its inputs were attacker-controlled. This is the step a reader is most likely to disbelieve, so it gets a line of its own rather than being left implicit.

A derivation: one line for each step of the knowledge derivation, ingredients before target. These are not reconstructed after the fact by a pretty-printer guessing at what must have happened. Every rule that adds something to attacker knowledge is required to record how it got there, so the narration is read straight off the derivation the engine performed. A step the attacker carried out inside a different principal’s session is labelled with that session, on the line itself.

Names, not terms

The other half of readability is vocabulary. Step 17 of that trace read:

17. Attacker opens e1 with akenc1, obtaining m1.

Here is the engine’s internal record of the same step, with the terms written out in full:

the same fact, before name compression

one step

Deduction › m1 obtained by decomposing AEAD_ENC(HKDF(MAC(HKDF(DH_KEX(PUBKEY(nil),
ae2), HKDF(HASH(DH_KEX(PUBKEY(nil), alongterm), DH_KEX(PUBKEY(blongterm), ae1),
DH_KEX(PUBKEY(nil), ae1), DH_KEX(PUBKEY(blongterm), ae1)), nil, nil), nil), nil),
nil, nil), m1, HASH(PUBKEY(alongterm), PUBKEY(blongterm), PUBKEY(ae2))) with
HKDF(MAC(HKDF(DH_KEX(PUBKEY(nil), ae2), HKDF(HASH(DH_KEX(PUBKEY(nil), alongterm),
DH_KEX(PUBKEY(blongterm), ae1), DH_KEX(PUBKEY(nil), ae1),
DH_KEX(PUBKEY(blongterm), ae1)), nil, nil), nil), nil), nil, nil).

Both say the same thing. The difference is that the narrator keeps a table mapping terms back to the names the model already gave them, so a value Alice calls akenc1 is called akenc1 in the trace, and only the parts with no name of their own get spelled out. The table also excludes the slots a step is itself touching, which is what stops a substitution line from reading “replaces gb with gb”, and the same table feeds the summary line so it quotes the same vocabulary as the steps above it.

None of this changes a single verdict. It changes whether the verdict is something you can hand to a colleague who has never opened Verifpal, walk through line by line, and check by hand. For the people who use Verifpal to teach protocol analysis, it also decides whether an attack is a thing students can read.

Phases, and when the attacker knows things

Phases are how Verifpal models time. phase[1] means later, and a leaks declaration inside it is a compromise that happens after the earlier traffic has already gone by. That is what makes forward secrecy, key compromise impersonation and post-compromise security expressible.

It also creates a trap. If the attacker’s phase-1 knowledge is allowed to justify an action it took in phase 0, then any key that ever leaks retroactively forges every signature that was ever checked, and forward secrecy queries stop meaning anything.

In 0.70.0, a proposed substitution is judged against the attacker’s knowledge as of the phase of the value it touches, not against everything accumulated by the end of the run. Attacker knowledge is snapshotted at the end of each phase, and a substitution that reaches back into an earlier phase is re-executed against that earlier snapshot.

Two models one line apart show the difference:

model	the prekey is…	phase 1	confidentiality? m
phase_signed_prekey.vp	signed, and checked with `?`	both identity keys leak	holds
phase_unsigned_prekey.vp	not signed at all	both identity keys leak	contradicted

In the signed model, the attacker would have to swap the prekey during phase 0, and in phase 0 it does not have the identity key it would need to forge the accompanying signature. The leak arrives too late to help. In the unsigned model there is no signature to forge, the swap succeeds when it is made, and the phase-1 leak completes it. It is the same shape as the Signal example above, in about twenty lines, which makes it a good teaching model for why signed prekeys exist.

Both directions matter. Too permissive and the tool invents retroactive forgeries; too strict and it misses the store-now-decrypt-later attacks that phases exist to express. Seven models in examples/test/ pin the boundary from both sides, including a three-phase one where the tampering, the compromise and the payoff happen at three different times.

Relaying is not forging

This distinction comes up as soon as a protocol has more than two parties.

Take a value that Alice signs and encrypts to Carol; Carol opens it and re-envelopes it to Bob; Bob verifies the signature and MACs it onward to Damian. The message Bob receives was sent by Carol, and it contains Alice’s content unchanged. Should authentication? Alice -> Carol: envelope fail?

It should not, because being known to the attacker is not the same as being forgeable by the attacker. A value the attacker can watch go past, relay unchanged, or rebuild identically out of honest pieces is not a value it can substitute for something else. An engine that blurs those two things reports man-in-the-middle attacks against protocols that do not have any.

verifpal verify four_party.vp

1 of 4 failed

     Fail ✗ confidentiality? msg
            ╭─ Attack trace:
            │ 1. Attacker observes msg on the wire.
            ╰▸ msg (msg) is obtained by Attacker.
     Pass ✓ authentication? Alice -> Carol: envelope
     Pass ✓ authentication? Carol -> Bob: re_envelope
     Pass ✓ authentication? Bob -> Damian: audit_mac

Confidentiality fails because the final hop sends the plaintext in the clear, which is what this model does deliberately, and the trace is one line long because that is the whole attack. The three authentication queries hold across the entire relay chain, through a re-envelope, a signature check and a MAC. relay_not_forgery.vp and key_ratchet.vp pin the same property in smaller models.

Removing equations

Verifpal has always had a kind of value that existed for exactly one purpose. Alongside constants and primitives there were equations, written G^a and G^a^b, with G as a reserved generator, a limit of two exponents, and their own handling in the parser, the pretty printer, the equational theory, the unifier and the attacker search. They modelled Diffie-Hellman and nothing else, and all five of those places had to be kept consistent by hand.

From 0.70.0, Diffie-Hellman is written with two ordinary primitives: PUBKEY(a) for a public key derived from a private value, and DH_KEX(gb, a) for a shared secret.

The same key exchange, with one kind of value fewer. None of the security semantics changed. DH_KEX(PUBKEY(a), b) and DH_KEX(PUBKEY(b), a) are still the same shared secret, and the attacker still cannot compute either one from two public keys. What changed is where those facts live: commutativity, and the argument restrictions that make computational Diffie-Hellman structural, are now two fields on a primitive spec instead of properties baked into the value representation.

Migration is mechanical, with five patterns to look for:

0.53	0.70
`ga = G^a`	`ga = PUBKEY(a)`
`gab = ga^b`	`gab = DH_KEX(ga, b)`
`SIGNVERIF(G^sk, m, sig)`	`SIGNVERIF(PUBKEY(sk), m, sig)`
`PKE_ENC(G^sk, m)`	`PKE_ENC(PUBKEY(sk), m)`
the attacker’s own key, `G^nil`	the attacker’s own key, `PUBKEY(nil)`

Value now has two variants instead of three. Every function in the engine that matched on a value used to carry a third arm whose behaviour had to be kept consistent with the other two by hand. Resolution, equivalence, matching and the solver each lost one.

KEM_ENCAP and KEM_DECAP

Removing equations was the prerequisite for this part, rather than the goal in itself.

principal Alice[
	generates r
	ss, ct = KEM_ENCAP(ekb, r)      // a shared secret, and a ciphertext
	e = AEAD_ENC(ss, m, nil)
]

Alice -> Bob: ct, e

principal Bob[
	ssb = KEM_DECAP(dkb, ct)        // where ekb = PUBKEY(dkb)
	d = AEAD_DEC(ssb, e, nil)?
]

A key encapsulation mechanism has no exponent to commute and no generator to sit in base position, so there was no way to express one through the equation interface. That was not for want of a feature: the interface was shaped around one algebraic structure that a KEM does not have. As two ordinary primitives, KEM_ENCAP and KEM_DECAP are about thirty-five lines of declarative data in primitive/spec.rs, and the rest of the engine picked them up without being told they exist.

They are generic rather than named after a specific algorithm. ML-KEM, HQC and Classic McEliece are indistinguishable in the symbolic model: what a symbolic attacker can do with a ciphertext does not depend on whether the underlying hardness assumption is module-lattice or code-based. Naming the primitive MLKEM_ENCAP would imply a precision the model does not have.

Since we started recommending post-quantum native design, the question we get most often is what a hybrid actually buys you. Three models answer it:

model	what leaks in phase 1	confidentiality? m
kem_hybrid_classical_broken.vp	both Diffie-Hellman private values	holds
kem_hybrid_pq_broken.vp	the decapsulation key	holds
kem_hybrid_both_broken.vp	both, together	contradicted

All three are the same protocol: an X25519 shared secret and a KEM shared secret, both fed into HKDF, with the resulting session key protecting one message. The only difference is what phase 1 leaks. It is the hybrid construction argument as three files you can run in a design review.

One detail in the KEM rules is easy to get wrong. An attacker holding the decapsulation key can open an encapsulation even if no principal in the model ever calls KEM_DECAP, because the decomposition rule yields one of the primitive’s outputs rather than one of its arguments. Holding the ciphertext and a decapsulation key of its own gets the attacker nowhere: kem_secret_not_forgeable.vp gives the attacker its own key pair, leaks it outright, hands it the ciphertext from the wire, and both confidentiality queries still hold.

Two more shapes follow from encapsulation being a function of its arguments. Encapsulate twice to the same key with the same randomness and the shared secret is identical, so equivalence? ss1, ss2 holds, which is how the hazard becomes visible, since two secrets from two separate encapsulations should not be interchangeable. With fresh randomness the query is contradicted. Freshness works the same way: a shared secret is only as fresh as the randomness behind it, so freshness? ssfresh passes and freshness? ssstatic does not.

Twelve messages of Signal

In February, Verifpal verified X3DH and the Double Ratchet across three messages under an active attacker, which was then the deepest result the tool had produced. examples/messaging/signal_twelve.vp extends the same model to twelve messages. Each one generates a fresh ephemeral, mixes it with the peer’s most recent ephemeral public value, and chains the resulting root key onto the previous one: twelve rounds of nested key derivation, and twenty-four queries covering every message in both directions.

verifpal verify signal_twelve.vp --result-code

24 of 24 verified

attacker[active] · 2 principals · 12 messages · 24 queries
 
c0a0c0a0c0a0c0a0c0a0c0a0c0a0c0a0c0a0c0a0c0a0c0a0
 
confidentiality and authentication, for every message, all holding.
real 37.19s

Thirty-seven seconds is slower than we would like, and we intend to bring it down. But it finishes, and it finishes with the right answer, which the old search could not do at this depth.

Getting it, and moving your models over

brew tap verifpal.com/source https://github.com/symbolicsoft/verifpal
brew install verifpal

On Windows, scoop bucket add verifpal https://github.com/symbolicsoft/verifpal.git followed by scoop install verifpal. Either way you get automatic updates.

There is no automatic migration tool, deliberately. A rewriter would have to guess which side of a ^ was meant to be the exponent in the cases where a model was doing something unusual, and a wrong guess gives you a model that parses cleanly and means something else. The parser points at every line that needs attention instead:

Error: mymodel.vp:5:8: parse error: cannot use reserved keyword in name: g
   ga = G^a
         ^

Work through the five patterns above and most models take a few minutes. The rest of the toolchain is already updated: the browser-based Workbench runs 0.70.0 with nothing to install, Print 20 of the Verifpal Manual documents the new primitives and the backwards search, and both the VS Code extension (1.0.11) and the Neovim extension highlight and document PUBKEY, DH_KEX, KEM_ENCAP and KEM_DECAP.

If you model something and a result looks wrong to you, please open an issue. Several of the changes in this release started with exactly that.

Meet the Symbolic Software Summer 2026 Team

Wed, 29 Jul 2026 00:00:00 +0000

Symbolic Software is a bigger team than usual this summer, and we’d like you to meet everyone. Five people joined us: two research interns, Lorenzo and Hossein, who came on board through our Summer 2026 research internship, and three teaching assistants, Faysal, Abd El Kader and Rabab, who are helping run the Applied Cryptography online course for the Summer 2026 cohort.

The interns have been working on soundcalc-lean, a project proposed and backed by the Ethereum Foundation: a Lean 4 restatement of soundcalc, the calculator that evaluates the concrete bit security of hash-based zkVMs under different parameter choices. In soundcalc-lean, every cell of a soundness report is re-derived as a machine-checked theorem over exact rationals rather than computed with floats. The teaching assistants, meanwhile, have been grading, proctoring, answering questions and handling logistics for the fifty Lebanese students taking the course this summer.

Rather than describe everyone ourselves, we asked each of them to introduce themselves and their work. Here they are, in their own words.

The research interns

Hossein Hafezi

I’m Hossein Hafezi, a PhD student at the University of Cambridge (previously at NYU), where I work on applied cryptography and systems security. You can find out more about me at hosseinhafezi.com.

At Symbolic Software I worked on rewriting soundcalc in Lean, with added semantics. The project was proposed and backed by the Ethereum Foundation, and it computes the bit security of different hash-based zkVMs under different parameter choices — an important effort given how widely these zkVMs are used, especially in zk-rollups, and the role they are likely to play in post-quantum blockchains. I started this project with zero knowledge of Lean and formal methods, and came away having learned a great deal. We hope the Ethereum and ArkLib communities will keep building on top of our library. One small note: working with Nadim is fun, because he’s very hands-on.

Lorenzo Magliocco

I am Lorenzo Magliocco, a PhD graduate in Cybersecurity from Sapienza University of Rome and LUISS. My research efforts focused on foundational theoretical cryptography, particularly in the design of multi-party protocols and theoretical models where truly honest parties do not exist.

Coming from a background in engineering and cybersecurity, I always had an inkling for exploring more applied avenues, and that’s what brought me to Symbolic Software! From no prior experience in formal verification and open-source development, I was able to contribute towards writing a Lean port of soundcalc: a Python tool that enables zkVM developers to evaluate the overall soundness and proof size of different zkVM configurations. Early on, I gave an introductory bullet talk on our efforts to the broader Ethereum formal verification community (Ethproofs #9). Ever since, I have been working mostly on the engineering side of the project, while diving into Lean subtleties and proofs as needed. I am already happy with the results we achieved so far, and I hope the broader zkVM ecosystem will be able to benefit from our efforts!

The teaching assistants

Faysal El Estwani

Hi, my name is Faysal El Estwani! I’m currently pursuing a Master’s degree in Computer Science at the American University of Beirut, where my thesis focuses on cybersecurity, specifically malware analysis. I’m passionate about software engineering and enjoy tackling programming problems. Outside of cybersecurity, I have a strong interest in game development and love exploring how software can be used to create interactive experiences. In my free time, I’m also an avid music enthusiast and enjoy learning about and playing musical instruments.

This summer, I’ve been working as a Teaching Assistant for the Applied Cryptography course. I spend most of my time grading assignments and exams, answering students’ questions, and helping explain concepts that they find challenging. It’s been a great opportunity to strengthen my own understanding while helping others learn. It’s so rewarding explaining something to a student and then seeing them apply it correctly on an exam or exercise!

Abd El Kader Kahil

Hello, my name is Abd El Kader Kahil. I am a graduate student, finishing up my Master’s thesis in Lebanon at the American University of Beirut. My technical interests include programming language design and implementation, cryptography, graphics/game programming and algorithm optimizations. Here’s my website with links to my socials.

At Symbolic Software I worked as a Teaching Assistant with Professor Nadim Kobeissi at his independent summer course. During this period I corrected assignments, answered questions, held exams and handled logistics. My goal is to minimize the friction between Lebanese students and learning cryptography and make this subject more widely studied and researched in the country. This opportunity also allowed me to connect with promising students in Lebanon and help shape their knowledge base and future.

Rabab Salim

Hello, I’m Rabab Salim, a Master’s student at the American University of Beirut where I’m currently finishing up my thesis on topics related to cybersecurity and machine learning. I have also TA’ed many courses as part of my Graduate Assistantship here, which has ignited my passion towards teaching.

Working with Professor Nadim under Symbolic Software as part of the Applied Cryptography course has been a wonderful experience. Being a teaching assistant here isn’t constricted to grading assignments and proctoring exams, but is part of a bigger goal of making cryptography easy and accessible to Lebanese students, and this is what I hope to accomplish by the end of the course. Meeting and engaging with students has been insightful and inspiring in many different ways. I aspire to make the most out of it while pushing towards many more meaningful goals like this one!

Our thanks to all five. The summer’s research output and the course both rest on their work. We’ll have more to say about soundcalc-lean as the project matures, and the Summer 2026 cohort runs through October 10.

Why I Teach Cryptography in Lebanon

Wed, 22 Jul 2026 00:00:00 +0000

Cedarcrypt, an applied cryptography summer school and conference, concluded on July 16 after four days at the American University of Beirut’s campus in Paphos, Cyprus, about two hundred kilometers of sea from Lebanon. All year, colleagues and friends have asked me some version of the same question, and I have asked it of myself: why spend a year of eighty-hour weeks building a cryptography course, then a scholarship program, then a conference, for a region the field has never counted? This is the mission of my lifetime.

Communication in the presence of adversaries

Ron Rivest defined cryptography as communication in the presence of adversaries. It remains the best definition available, and it is a strange one: a science whose object is defined by hostility, by the standing assumption that someone is working against you. Number theory assumes no enemy. Cryptography assumes little else.

I was born in Beirut. In the country I come from, Rivest’s phrase is not a technical definition; it is a description of conditions. Since 2019, Lebanon’s currency has lost roughly ninety-eight percent of its value, and depositors have watched their savings sealed inside a banking system that had quietly become insolvent. The state provides a few hours of electricity a day; diesel generators cover the rest. In 2020, a warehouse of ammonium nitrate leveled the port of Beirut in one of the largest non-nuclear explosions ever recorded. In 2024, a war killed thousands and displaced more than a million people in a country of five million. The World Bank ranks the compound collapse among the most severe crises anywhere since the middle of the nineteenth century. Ordinary life in Lebanon has become an exercise in operating in the presence of adversaries: institutional, economic, military, and increasingly digital.

So when I began teaching applied cryptography to fifty-five students at the American University of Beirut in the fall of 2025, certain things did not need to be taught. I have watched seasoned engineers in peaceful countries struggle to take metadata seriously as a threat. My students had relatives who were tracked through their phones during the war. Nobody asked why forward secrecy matters, or why a protocol should assume the server is hostile, or why anyone would bother hiding who talks to whom. Their threat model predated my whiteboard: it was the family group chat.

The geography of cryptographic expertise is upside down. The field concentrates its people, funding, conferences, and prestige in a handful of prosperous capitals, places where cryptography is a profession. It is thinnest where cryptography is a lifeline: post-conflict states, blackout zones, societies under active surveillance. I claim no position outside this pattern; I built my career and my firm in Paris and have spent years enjoying the field’s comforts. But a discipline that theorizes adversarial conditions while absenting itself from nearly every place that suffers them has an incomplete claim to its own name. Bringing the expertise to where the adversaries actually operate is what the phrase real-world cryptography ought, at minimum, to mean.

Fifty-five students

The course was built from scratch: about 1,500 slides, eight problem sets, eight implementation projects in Go and Rust, a syllabus that starts at the one-time pad and ends at zero-knowledge proofs and post-quantum systems. Most of the fifty-five had never seen a security definition. The conditions were what they were. Israeli drones passed low over campus most days, often during lecture. Power cuts were routine, and students debugged their Double Ratchet implementations on laptop batteries. I expected all of this to degrade the course, and it did the opposite. Simone Weil called attention the rarest and purest form of generosity; whatever that is as metaphysics, as a description of a classroom in a collapsing country it is exact. Attention there is expensive, and people who choose to spend it on you have made an actual decision.

The Applied Cryptography class at the American University of Beirut, fall 2025.

Teaching there showed me something that I suspect is invisible from inside the field’s usual venues: most of the difficulty of cryptography is not difficulty. It is intimidation. The notation is more frightening than the ideas it encodes. When I presented Diffie–Hellman in full formal dress, safe primes and cyclic subgroups and a decisional assumption quantified over probabilistic polynomial-time adversaries, I watched faces close. When I presented the same idea as clock arithmetic, the same students started asking exactly the right questions, and weeks later were reading the formal treatment on their own, because by then they knew the notation was shorthand for something they already understood. The obstacle was never the mathematics but an acquired belief, installed by years of small signals, that this field belongs to other people. We treated that belief as a technical problem and worked on it deliberately: optional student presentations that filled the room anyway, a poster session, a weekly coffee-shop-style, donut-laden gathering called The Key Exchange where the conversation ran from lattice reductions to how one writes to a professor one has never met. The field helped more than I had any right to expect. Jean-Philippe Aumasson flew to Beirut to lecture in person; Kenny Paterson, Rolfe Schmidt, Nigel Smart, Vitalik Buterin and others gave their time in a semester when engaging with Lebanon was not a light decision.

Student presentation sessions on the AUB campus.

Students who found the first problem set bewildering earned near-perfect scores on the fourth. The final exam, which I published openly so that colleagues could judge its difficulty for themselves, averaged 82 out of 100. By semester’s end, students who had begun with nothing had implemented Signal’s Double Ratchet, built hybrid post-quantum systems on ML-KEM and ML-DSA, written zero-knowledge applications, and formally verified protocols. One of them, Silina Elfil, produced state-separable proofs cleaner and shorter than the published ones in the textbook she was learning from. Strong departments in Europe and North America now write to ask me for these students. A door was opened, and the people on the other side of it turned out to be as capable as anyone should have assumed all along.

Suleiman Jaber presenting on zero-knowledge proofs.

That semester took five months of eighty-hour weeks, and I corrected more than 2,300 pages of assignments and exams by hand, alone. In the accounting my field uses to allocate careers, all of it counts for less than a single workshop paper. I knew this going in; colleagues confirmed it, kindly, as a warning. We have built an economy of recognition in which the work that most changes lives is the work that does not count, and professors at every university you know spend entire careers on the wrong side of that ledger. I said a version of this from the stage at Real World Crypto earlier this year: we hand one another recognitions we will not care about at the end of our lives while withholding them from the work we will. Two of my students were supposed to be at that conference with me. Their flights out of Beirut were canceled at the last minute because of the war, and I opened the talk beneath their photographs. The field’s incentive structures, unlike the war, are ours: we built them, and we can build different ones.

Precedents

Cedarcrypt’s logo is a broken Phoenician tablet mended back together with gold, in the manner of Japanese kintsugi, the craft of repairing fractured pottery with lacquer dusted or mixed with gold so that the seams are not hidden but illuminated. I chose it because the break is not disguised. The mend is worth more than the unbroken original precisely because it makes the fracture part of the object’s history. The Phoenician tablet stands for the region that gave the alphabet to the world; the gold seams stand for what can be made of a thing after it has been shattered.

The university stands for the same thing. AUB was founded in 1866 and has held classes through famine, world wars, fifteen years of civil war, and the current collapse. In 1948, Constantine Zurayk, a historian there, wrote a short, severe book called The Meaning of the Disaster, arguing that the answer to regional catastrophe was neither slogan nor lament but the patient, generational mastery of modern science. I make no grand claims for one cryptography course, but I know whose program I am following. And when Bana Bashour opened Cedarcrypt with a talk on higher education that turned on Plato’s cave, her point being that the ascent toward the light is only half of Plato’s argument and that the one who ascends is obligated to go back down, she was making a general case about universities. For me it doubled as a precise account of why I went back to Beirut to teach.

Four days in Paphos

Cedarcrypt was hosted in Paphos instead of Beirut because I could not yet responsibly ask the international community to convene inside Lebanon, and I could not hang two dozen student scholarships on travel logistics that one bad week could unmake. Cyprus is the standing answer to this problem. During the civil war, when Beirut’s port and airport closed, the ferry from Jounieh to Larnaca became Lebanon’s route to the world, and a good part of Lebanese commercial life ran from the island until home reopened. AUB now keeps a campus in Paphos, AUB Mediterraneo, our host and co-organizer, and its teaching therefore no longer depends entirely on conditions at home. Convening there was a compromise. I want a future edition of Cedarcrypt to meet in Beirut, the moment it can be done responsibly.

The program itself: Bart Preneel, who heads the COSIC group at KU Leuven, traced fifty years of the Crypto Wars, from the Clipper Chip to client-side scanning, before an audience for whom the question of who may read one’s messages has never been academic. Meryem Cherkaoui Semmouni, of Sidi Mohamed Ben Abdellah University in Morocco, spent the first afternoon leading students through lattice attacks on RSA with the LLL algorithm. Engineers and researchers from Mozilla, The Guardian, Nokia Bell Labs, and the threshold-cryptography world taught constant-time programming, web transparency logs, homomorphic encryption in production, and group messaging for whistleblowing systems. Students implemented components of hash-based SNARKs in a three-hour workshop. A panel put a former IACR president and the co-founder of Ethereum in front of students who twelve months earlier had no path into the field. There were lightning talks; the best won a hardcover of Mike Rosulek’s excellent The Joy of Cryptography. There was a dinner on a mountaintop above Paphos, and a day trip along the coast before the program began, to the sanctuary of Aphrodite at Palaepaphos and the theatre at Kourion, because communities form on buses and over long lunches at least as reliably as in lecture halls.

The panel on the future of applied cryptography: Vitalik Buterin, Lucas Meier, Bart Preneel, and Giacomo Fenzi, with me moderating.

On the morning of July 11, most of our scholarship students boarded the same Middle East Airlines flight out of Beirut, and a chartered bus met them at Larnaca airport to take them to the student dorms. More than two dozen attendees came on scholarship support, the majority from Lebanon, joined by two more who flew in from Cairo and Zurich. The funding came from Cure53, Zama, PQShield, Electi, and Passbolt, and from anonymous donors, one of whom, a private individual, gave more than any company; the event ran in collaboration with the IACR. Among the students on that flight were some of those whose flights to Real World Crypto the war had canceled in the spring. This time the plane took off.

The pre-conference outing along the Cyprus coast.

The full Cedarcrypt 2026 photo album is available on Flickr.

This conference was organized in substantial part by my former students. The workshop chair, the web secretary, the sponsorship secretary, the logistics secretary, the ethics officer: a year ago, every one of them was sitting in a lecture hall in Beirut learning what a pseudorandom function is. This summer they negotiated with sponsors, ran international logistics, and staffed the registration desk of an institution that had not existed a year earlier. The distance from student to builder of institutions was twelve months.

On the first day, three of these organizers walked on stage and gave Bart Preneel a painting: a woman in the embroidered dress of the old Levant, carrying a water jar up through a hillside village.

Faysal Elestwani, Abd El Kader Kahil, and Rabab Salim presenting Bart Preneel with the painting.

The attendees are writing their own accounts now. One, a master’s student at AUB, wrote that this was their first conference and that a highlight was discussing their own research with Vitalik Buterin. Another, a graduate student at Beirut Arab University who came on scholarship, wrote of leaving with more questions and more motivation than they had arrived with, and that this felt like the whole point. I could not have put the success criterion better, and I did not have to. A student wrote it!

A workshop session in the AUB Mediterraneo auditorium.

Meanwhile the teaching continues. This summer’s free online cohort, which initially accepted fifty students from nine institutions with the Lebanese University foremost among them, is mid-semester right now, meeting Tuesdays and Thursdays at eleven in the morning, Beirut time. The materials are open under Creative Commons, permanently. And the course written for Beirut is now the foundation of applied cryptography teaching at Ruhr University Bochum, Technische Hochschule Lübeck, the University of Vienna, and the University of Edinburgh. The expertise was supposed to flow in the other direction.

Students of the Summer 2026 online cohort sitting their midterm exam, in a hotel conference room rented for the occasion.

The decades ahead

The strongest of my students receive offers from abroad; I write their recommendation letters gladly, and every letter costs me something. A region does not keep its field by barring the door. It keeps its field by building reasons to stay and bridges for those who leave to remain part of the work. The old cities of this coast never held an empire; they held a network, and the network outlasted the empires that sacked them. That is the working model: a community whose members may sit in Waterloo or Zurich or Hamra, with its center of gravity in the Levant all the same.

Cedarcrypt returns in 2027. The summer program will run again, free, for as long as I can fund and staff it. The course materials remain open, and I will help any university anywhere that wants to teach from them, as four already do. I will keep making the argument about incentives in every venue that will have me: a field that cannot count the work of building people has resigned itself to remaining a guild of the fortunate. And the long-term goal, at the ten- and twenty-year mark, is for this mission to become unnecessary. Cryptography in the Levant will have succeeded when it is unremarkable, when a student in Tripoli or Saida can find a course, an advisor, a community, and a career without any of it depending on one exhausted man and his friends.

None of this belongs to me alone. Wassim El Hajj, AUB Mediterraneo’s rector, Malek Tabbal, my co-chair, and the leadership of AUB and AUB Mediterraneo, who said yes when yes was expensive. Jean-Philippe Aumasson and Lucas Meier, who helped me build the program. Ghady Youssef, Abd El Kader Kahil, Rabab Salim, Nai Hamdan, and Faysal Elestwani, the students who became organizers. The AUB faculty who carried the course with me through the fall. The sponsors, and the donors who asked for nothing, not even their names. The speakers who crossed the world for a first-edition conference on the strength of an idea. My wife, Arij, who kept believing in this throughout. And my students, who are the entire point.

The painting the students chose is an image of provision as work: unglamorous, scheduled, indispensable. That is what teaching is, and it is what building a field will be: water carried uphill, on a schedule, for years. Two hundred kilometers east of that stage is the city where this started and where I intend for it to continue. In the meantime there is a cohort mid-semester, a 2027 edition to plan, and water to carry.

How Jevil works

Sun, 31 May 2026 00:00:00 +0000

Most signature schemes are designed so that nothing bad ever happens. Jevil is designed so that something catastrophic happens exactly once, at a moment you choose in advance.

It is a few-time signature scheme. You pick a budget (say, a thousand signatures) at key generation. The first thousand signatures are ordinary, unforgeable, post-quantum signatures. The thousand-and-first publishes your secret key to the entire world. Not “weakens.” Not “degrades.” Publishes. Anyone watching can sit down with a piece of paper and reconstruct it.

That is the whole idea, and the rest of this post is about why anyone would want such a thing, and how the machinery underneath actually works. The best way to start is to break it yourself. Go ahead: sign a few messages, then push it over the edge.

interactive figure

Enable JavaScript to explore this figure.

If you cranked the budget up and signed past it, you saw the fog of possibilities collapse onto a single curve. Hold that picture; everything below explains it.

Why would you want a cliff?

A few-time signature caps how many signatures you can safely issue. That sounds like a limitation, and it is, but plenty of things in the real world are intrinsically finite and would rather be finite: a firmware vendor that will sign a bounded number of releases and then go quiet for a decade; an operator binding themselves to a fixed per-tenure attestation budget; an audit-budgeted credential that issues its allowance and then has no further business existing. In all of these, “you may sign at most $n^\star$ times” is not a nuisance. It is the actual security goal.

The obvious way to enforce a count is with state: a counter, a synced database, a hardware register that ticks up and refuses to go past the budget. This is how stateful hash-based schemes like XMSS and LMS work, and it is notoriously fragile in deployment. Restore a backup, clone a VM, fork a container, and the counter silently rolls back, so the signer happily re-uses key material it already spent and security quietly collapses with no alarm. That fragility is exactly what motivated the move to stateless schemes in the first place.

Stateless schemes route around the counter by making the cap a property of the cryptographic object itself. The dominant family, HORS and its descendants (which sit at the leaves of SPHINCS⁺ and the standardized SLH-DSA), does this, but its failure is soft. After $n$ signatures, a forger’s success probability rises gradually, roughly as $\left(\tfrac{nK}{T}\right)^{K}$. There is no single moment where anything breaks; “how many signatures is safe” is a slider on a continuum, and you pick a point on the slope and hope.

Jevil’s degradation is the opposite of soft. It is a wall.

interactive figure

Enable JavaScript to explore this figure.

To the best of my knowledge, Jevil is the first few-time signature scheme that is simultaneously post-quantum, transparent (no trusted setup), and cliff-shaped: its key-recovery threshold is a single sharp edge rather than a probabilistic ramp. Cliff-like behavior has shown up before, but always in a corner that fails one of those three tests. Nonce reuse in Schnorr or ECDSA recovers the key from two signatures, but it is classical and an accident, not a designed feature. Chaum-style offline e-cash extracts a double-spender’s identity, but it is classical and interactive. Polynomial-witness constructions over KZG or IPA commitments have exactly this geometry, but KZG needs a trusted setup and both are broken by Shor. Jevil’s one technical move is to bring that geometry into the post-quantum, transparent world. We will get to how.

The secret is a polynomial

Here is the entire trick, with no cryptography in it yet, just a fact about polynomials you already half-remember.

Two points determine a line. Three points determine a parabola. In general, $D+1$ distinct points determine a unique polynomial of degree $D$, and fewer than that determine nothing: through any $D$ points there run infinitely many degree-$D$ curves. This is the seesaw the whole scheme balances on. Give an observer $D$ evaluations of a secret degree-$D$ polynomial and they have learned, in a precise sense, nothing about which polynomial it is. Give them one more, the $(D{+}1)$-th, and it is pinned forever; they can recover every coefficient in $O(D^2)$ arithmetic by Lagrange interpolation.

That is the snap you saw in the sandbox. Below the threshold, a fog of curves all fit the revealed points equally well. At the threshold, the fog has exactly one member.

So here is the plan. The secret key is the coefficient vector of a degree-$D$ polynomial $f$. Signing a message will reveal a few evaluations of $f$. If we arrange for each signature to reveal exactly enough, and for the budget $n^\star$ to be the number of signatures that just barely keeps the total below $D+1$, then signatures $1$ through $n^\star$ leave $f$ undetermined, and signature $n^\star{+}1$ tips it over. The cliff is not bolted on. It is the same Lagrange fact that powers Shamir secret sharing and threshold signatures, simply inverted: where those schemes hand out evaluations on purpose so that enough parties can reconstruct, Jevil accumulates them as the penalty for over-use.

There is one detail worth flagging now because it reappears everywhere: the public key carries a single free evaluation of $f$, a point $(z, w=f(z))$ I will call the out-of-domain point. Think of it as one of the $D+1$ pins handed out for free at key generation. It is the purple point in the sandbox, and it earns its keep later.

A polynomial becomes a signature

If the secret is a polynomial, signing a message has to mean revealing some evaluations of it, and the choice of where to evaluate has to come from the message, deterministically, so that the verifier can re-derive the same points.

That is exactly what happens. The message is hashed to produce $K$ positions (Jevil fixes $K=16$), and the signature reveals $f$ at those $K$ points. “Hashed” means the positions are unpredictable and effectively random, but not fresh on every call: the same message always yields the same positions, so re-signing a message you already signed is free and tells the world nothing new. Type the same string into the figure below twice and watch the second one change nothing.

interactive figure

Enable JavaScript to explore this figure.

Now, “reveal $f$ at a point” needs to be something a verifier can check against the public key without holding $f$, and ideally something expressible in the narrow language that our commitment scheme will speak. The bridge is almost embarrassingly simple. Write $f(X)=\sum_{k} c_k X^k$ with coefficient vector $c$. Then evaluating $f$ at a point $x$ is just a dot product of $c$ against the powers of $x$:

$$ f(x) \;=\; \langle\, c,\; (1, x, x^2, \dots, x^{M-1}) \,\rangle. $$

This is the lift: it turns “evaluate the secret polynomial” into “take a linear form of the secret vector.” Drag $x$ below and watch the powers vector fill in and the dot product compute to $f(x)$.

interactive figure

Enable JavaScript to explore this figure.

Two things fall out of this little identity, and both matter later. First, whatever vector the signer is committed to lives in $M$ coordinates, so $\langle c, (1,x,\dots)\rangle$ is always a polynomial of degree at most $D=M-1$. There is no room to cheat the degree. Second, the claim “this is $f(x)$” is purely a statement about $c$, which is what lets us hide everything except the evaluations we meant to reveal.

The catch, and the fix

If signing just meant publishing the pairs $(x_t, f(x_t))$ in the clear, we would be done, and also broken in three different ways.

A dishonest signer could lie, publishing a $y_t$ that is not actually $f(x_t)$, to dodge the consequences of an honest reveal.
A dishonest signer could cheat the degree: secretly use a higher-degree polynomial so that the “$D+1$ points pin it” accounting never catches up, and keep signing forever past the budget.
And even an honest reveal might leak more than the $K$ points if the verification machinery exposed side information about $f$.

The fix for all three is a polynomial commitment. At key generation the signer commits to the coefficient vector $c$, producing a short public digest, a 32-byte root. From then on, the signer can open evaluations: prove “the polynomial behind root takes value $y$ at point $x$” without revealing anything else about it. Jevil uses zk-WHIR, a hash-based commitment I will treat here as a sealed box with three buttons.

interactive figure

Enable JavaScript to explore this figure.

The box gives us exactly the two guarantees we need. It is hiding: an opening reveals the asked-for evaluation and nothing more. Formally, it is zero-knowledge, so the proof could have been simulated from the evaluation alone. And it is binding to the degree: the thing inside is a vector of $M$ coordinates, so every value it ever opens is consistent with one fixed polynomial of degree at most $D$. The signer cannot lie (an inconsistent opening fails to verify) and cannot smuggle in a higher-degree secret. The “lie” attack and the “leak” attack both die here.

The “cheat the degree” attack is worth lingering on, because it is what makes the cliff unavoidable rather than merely default. You might worry that a malicious signer could pick a weird public key, not the honest output of key generation, engineered so the cliff never fires. It cannot. zk-WHIR’s knowledge soundness means that behind any root the verifier ever accepts, there provably exists a degree-$\le D$ polynomial that every accepted opening agrees with. The degree cap is a property of the public key itself, not of honest behavior. So the cliff binds even an adversary who chose their key in bad faith.

interactive figure

Enable JavaScript to explore this figure.

Why zk-WHIR specifically? Because it is the commitment that satisfies all of Jevil’s constraints at once. It is post-quantum (its security rests on hash functions and Reed–Solomon proximity, not on discrete logs, so Shor does not touch it), it is transparent (no trusted setup, so nobody has to generate and then destroy a secret), it supports the linear-form openings our lift produces, and it is zero-knowledge. It sits at the end of a lineage of Reed–Solomon proximity tests (FRI, then DEEP-FRI, then STIR, then WHIR) with the zero-knowledge layer added on top. For this post it stays a black box; if you want the inside of the box, the paper and the zk-WHIR paper it builds on are the places to go.

One proof, not seventeen

Each signature reveals $K=16$ evaluations, plus we want to fold in that free out-of-domain point, so naively that is $K+1 = 17$ openings per signature, each with its own proof. That would be bulky. Instead Jevil batches them into a single opening.

The trick is a random linear combination. Squeeze $K+1$ random coefficients $\beta_t$ out of the transcript (Fiat–Shamir: hash everything so far), and combine the $K+1$ separate claims “$f(x_t)=y_t$” into one claim about a single linear form. Because the lift already turned each evaluation into a linear form of $c$, a combination of them is again a linear form of $c$, so the whole bundle becomes one zk-WHIR opening.

interactive figure

Enable JavaScript to explore this figure.

What stops a signer from sneaking one false value into the bundle, hoping it averages out? Schwartz–Zippel. If even a single one of the $K+1$ claimed values is wrong, the combined claim is wrong for all but a $1/|\mathbb{F}|$ fraction of the random $\beta$’s, and $|\mathbb{F}|\approx 2^{256}$, so the signer is caught with overwhelming probability. Lie once, get caught. One proof now stands in for seventeen, at no security cost.

Why you can’t forge below the cliff

The cliff is the dramatic part, but a few-time signature is worthless if the signatures before the cliff are forgeable. They are not. Below the budget, Jevil is unforgeable at roughly $124$-bit classical security against an adversary making up to $2^{128}$ hash queries.

A forger trying to sign a fresh message has only three moves, and each is a wall. They can lie about an evaluation, but we just closed that door with the commitment and Schwartz–Zippel. They can try to guess the value of $f$ at a position nobody has seen, but below the cliff $f$ is information-theoretically undetermined, so any unseen evaluation is uniform over a $2^{256}$-element field, and guessing it is hopeless. Or they can hope that the fresh message’s positions happen to land entirely inside the set of positions already revealed by past signatures, the only case where they could quote honest values without ever signing.

That last move is the classic HORS coverage attack, and it is the one the parameters are tuned against. The “seen pool” grows by $K$ positions per signature; a fresh message’s $K$ positions are an independent random subset of the whole space $\{0,\dots,T-1\}$; the forger wins only if all $K$ land in the pool, which happens with probability at most $\left(\tfrac{n^\star K}{T}\right)^{K}$ per attempt. Make the position space $T$ big enough and that probability stays negligible even after grinding $2^{128}$ messages. Throw some forgeries below and watch the odds.

interactive figure

Enable JavaScript to explore this figure.

Add the three bounds together (the commitment’s soundness, the Schwartz–Zippel term, and the coverage term) and the total forgery advantage comes in under $2^{-124}$. Signatures below the budget are real signatures.

Tuning it, and when to reach for it

Everything is driven by one knob: the budget $n^\star$, chosen from $\{1, 3, 7, 15, \dots, 2^{14}-1\}$, the values where $n^\star+1$ is a power of two, so the cliff lands exactly at signature $n^\star+1$. From $n^\star$ and the fixed $K=16$, the rest falls out: the polynomial has $M=(n^\star{+}1)K$ coefficients, degree $D=M-1$, and the cliff sits at $n^\star+1$. Slide the budget below and watch the sizes move.

interactive figure

Enable JavaScript to explore this figure.

The numbers are friendly. Public keys are 68 bytes flat: a 32-byte commitment root, the 32-byte out-of-domain value, and 4 bytes naming the budget. Secret keys are 32 bytes, a single seed everything else is derived from. Signatures run from about 40 KB at the smallest budget to a few hundred KB at the large end, growing only logarithmically in the polynomial size, so a thousand-fold increase in budget costs only a handful of times more bytes. Key generation, signing, and verification are all comfortably sub-second across the deployable range. The ceiling on the budget, $n^\star = 2^{14}-1$, comes from an arithmetic property of the working field: a degree-4 extension of the 64-bit Goldilocks prime, with about $2^{256}$ elements and just enough power-of-two structure to index the positions.

So when is the cliff the right tool? When over-signing should be self-punishing rather than merely forbidden. A stateful scheme says “don’t sign past the budget” and trusts your storage to enforce it; lose that bet to a rolled-back counter and you are silently insecure. Jevil moves the cap into the math: oversign and the polynomial becomes public, in $O(D^2)$, for everyone, immediately. There is no silent failure mode, because the failure is the loudest event the scheme can produce. That is a strictly stronger promise than discipline, and it does not depend on durable state, on operator vigilance, or on anyone trusting anything operational.

The paper and the code

If you want the formal version, with the security proofs, the exact parameters, and the cap-binding theorem stated properly, it is all in the paper. The reference implementation in Rust tracks the construction module for module.

Paper: eprint 2026/1103
Reference implementation: github.com/symbolicsoft/jevil

On Our Telegram MTProto Review

Thu, 21 May 2026 00:00:00 +0000

On May 18, 2026, iStories, part of the OCCRP investigative network, published a piece describing a Symbolic Software technical review of Telegram’s MTProto protocol. The review, titled Telegram’s MTProto: Assessing Deanonymization Potential for a Network Attacker and identified as GNMX-01, was commissioned in 2025 by Global Network Solutions, Inc. (“GNM”), the Telegram infrastructure provider that figures centrally in OCCRP’s 2025 investigation Telegram, the FSB, and the Man in the Middle. We did not publish the report. It entered the public record because GNM attached it to a civil filing in Switzerland, and iStories obtained it from the materials of that case.

We are publishing this post because the report is now being characterised through third-party paraphrase in coverage of a contested matter, and we would prefer the substance to stand without that mediation. The full report is available for download.

The conditions of the engagement

The report could not have been written without the following conditions, which are reproduced verbatim in Section 2.4:

Symbolic Software retains full editorial control over all findings, conclusions, and recommendations presented in this report;

Symbolic Software has the unconditional right to reach any conclusion deemed technically appropriate based on the evidence, regardless of whether such conclusions align with the expectations or preferences of any party;

No party may modify, censor, or otherwise interfere with the technical content or conclusions of this report;

Symbolic Software maintains sole authority over the methodology, scope, and presentation of the technical analysis;

The integrity of this report and its findings shall be preserved in any publication or distribution.

These were non-negotiable prerequisites of the engagement, and the commissioner agreed to them. Their relevance to the present situation is clear. The final clause in particular continues to bind the commissioner, even though the route by which the report became public was the commissioner’s own decision.

A second methodological note deserves quoting alongside that disclaimer. The OCCRP investigation’s principal technical source is Michał “rysiek” Woźniak, who formerly served as OCCRP’s Head of Infrastructure and Information Security. OCCRP disclosed this conflict of interest in the original reporting. The report addresses it directly in a footnote:

Mr. Woźniak’s technical claims were independently verified to be correct regardless of this potential conflict of interest. The political claims and personal opinions made in Mr. Woźniak’s technical analysis were disregarded during our independent verification.

The same standard runs through the report in both directions. Testable technical claims are evaluated against the evidence. Characterisations that blend technical fact with geopolitical framing are noted as falling outside the scope of technical validation, regardless of which party offers them.

The core technical finding

Telegram’s MTProto protocol prepends a 64-bit auth_key_id to the external header of every encrypted message. The identifier is the 64 lower-order bits of a SHA-1 hash of the 2048-bit authorisation key established at registration. MTProto 2.0 continues to use SHA-1 here even though it migrated to SHA-256 elsewhere, because the identifier must outlive any single protocol version. The underlying authorisation key is long-lived by design: it is generated on the client device, never transmitted over the network, and tied to the device’s persistent state.

The question the report examined was whether this identifier is exposed to passive network observers in deployed clients. On every platform tested, it is.

Telegram for Android. We replicated Michał Woźniak’s prior analysis of Telegram for Android v11.9.2 (5901). MTProto runs over plain TCP under a trivial obfuscation layer. Telegram’s own documentation describes that layer as designed only to defeat naïve protocol detection, not to provide cryptographic protection. The obfuscation is an XOR with a pseudo-random stream derived from a public, documented initialisation procedure, so deobfuscation is computationally trivial. After deobfuscation, the auth_key_id appears in cleartext in the external header of every MTProto message.
Telegram Desktop on macOS (version 11.15.275369 at the time of testing). The desktop client connects to Telegram’s servers on port 443, the canonical HTTPS port, but the traffic is not HTTPS. We verified this with four independent techniques:
- TLS fingerprinting of the initial packets of each connection. No TLS ClientHello was ever observed, and the connections began immediately with MTProto exchanges.
- Certificate validation. No TLS certificates were exchanged at any point.
- Packet structure analysis. The MTProto external header, including the 64-bit auth_key_id and the 128-bit message key, begins immediately after the TCP header, with no intervening TLS record layer.
- Selective traffic blocking. We configured local firewall rules to block outbound HTTPS to Telegram’s IP ranges while permitting plain TCP on port 443. Telegram continued to function normally, confirming that it does not depend on TLS at all.

The use of port 443 appears designed to evade simple firewall rules and censorship classifiers that block non-standard ports while allowing HTTPS. It does not deliver transport-layer encryption. The Telegram Desktop codebase is shared with the Windows and Linux builds, so the finding almost certainly generalises.

To characterise persistence, we observed the auth_key_id across a range of conditions that would normally defeat or interrupt other forms of network-layer tracking. The result was uniform across all of them.

Condition tested	What this would normally defeat	Effect on `auth_key_id`
Application restart	Session-scoped identifiers, in-memory state	Unchanged
IP address change (DHCP renewal)	IP-based tracking	Unchanged
Switching between WiFi networks	Network-scoped fingerprints, IP attribution	Unchanged
Switching between WiFi and cellular	IP attribution and per-medium fingerprints	Unchanged
VPN activation	IP-based tracking, geolocation, network attribution	Unchanged
Routing through Tor	Origin IP attribution, network-path observation	Unchanged
Connecting to a different Telegram server IP within the same datacenter	Server-endpoint-pinned identifiers	Unchanged
Continuous observation over days and weeks	Short-lived or session-rotated identifiers	Unchanged

With Perfect Forward Secrecy enabled, the visible identifier corresponds to a temporary key rather than the permanent one. The report walks through in some detail why this does not address the tracking problem. The temporary keys remain valid and unchanged for their full lifetime, which is typically 24 hours, and during that lifetime the temporary auth_key_id is just as observable and just as persistent as a permanent one would be. The binding step that ties a new temporary key to the permanent key is itself a network-observable event from the same client, typically from the same IP address. The old temporary auth_key_id is used to negotiate and authorise the new one, and both appear in succession in the traffic. A passive observer maintaining a record of these binding events can follow a device across arbitrary numbers of rotations. In the report’s words, PFS “is designed to protect against post factum decryption of message contents if keys are later compromised — it is not designed to prevent real-time traffic analysis or device tracking.” It does what it was specified to do. Transport-layer tracking is a separate problem.

The capability this creates is straightforward, and it does not require an active attacker. The report enumerates the in-scope adversary classes: ISPs along the network path, mobile carriers’ deep packet inspection systems, corporate and institutional network administrators, public WiFi operators, parties operating at internet exchange points or in transit, malicious hotspot operators, state surveillance programs, and any passive eavesdropper with physical or wireless access to the medium. None of these requires a man-in-the-middle attack, a certificate compromise, or active protocol manipulation. Simple packet capture and the publicly documented deobfuscation step suffice.

On “auth_key_id changes regularly”

A statement attributed to Telegram in iStories’ coverage holds that the auth_key_id “changes regularly and does not reveal user information.” The empirical part of that claim is testable, and the report tests it. From the executive summary:

Our empirical testing demonstrated that auth_key_id rotation, while theoretically possible, occurs infrequently in practice — we observed no rotation across application restarts, network changes, or extended time periods in our tests. This persistence contradicts claims of frequent rotation and significantly amplifies the privacy implications of the exposure.

For rotation to defeat the tracking model, “regularly” would have to mean two things at once: rotation at a cadence shorter than an adversary’s correlation window, and rotation that is not itself observable from the network. The deployed protocol satisfies neither condition.

The long-term auth_key_id did not rotate at all across the conditions enumerated in the previous section. When PFS was enabled, the temporary auth_key_id persisted for its full 24-hour validity period, and the transition from one temporary key to the next was trivially linkable. The binding event between successive temporary keys appears in the same flow, from the same client, and typically from the same IP address. The report quotes Woźniak’s prior analysis on this point: “It is extremely unlikely for the IP address of the client and the temporary auth_key_id to both change at the exact same time.” The transition is therefore not a privacy boundary. It is a network-visible event that links the old identifier to the new.

If Telegram has empirical evidence to the contrary, that evidence has not been made public, and our testing did not observe its effects.

On what the report concludes about each claim

The report evaluates five claims drawn from OCCRP’s investigation, and it does not endorse them in identical terms.

Claims 1, 3, and 5: fully supported. The first claim is that the auth_key_id enables user tracking. The third is that Secret Chats’ end-to-end encryption does not prevent that tracking, because the identifier sits in the MTProto external header beneath the Secret Chat encryption layer. The fifth is that infrastructure with router-level visibility can read those identifiers. The report describes each of these as technically accurate without overstatement, and the empirical evidence in our analysis substantiates them in full.

Claim 2: substantially accurate but with elements of overstatement, and in places actively misleading. Phrases like “all possible information” overstate what passive network observation strictly provides. The assertion that observers can determine “who exchanges data packets with whom” overstates the visibility that client-to-server observation provides in a centralised architecture. Network observers see traffic flowing to and from Telegram’s servers, but they cannot directly reconstruct the server-side communication graph from that traffic alone. Beyond these overstatements, there is a more substantive problem. The metadata surveillance capabilities described in Claim 2 are not unique to Telegram. Signal, WhatsApp, iMessage, and every other major messaging platform expose comparable IP-layer metadata to network observers. Singling out Telegram on this point, without acknowledging that Signal and WhatsApp face identical metadata exposure, misrepresents the scope of the issue. The MTProto-specific problem is the auth_key_id exposure of Claim 1. The broader metadata picture of Claim 2 is a property of unencrypted internet traffic at large.

Claim 4: technically sound core, geopolitical attribution speculative. Infrastructure-level access combined with auth_key_id visibility can enable extensive device tracking. That much is sound. The problem is the inferential chain OCCRP uses to attribute that capability to Russian intelligence services specifically. Applied symmetrically, the same chain would implicate Western messaging platforms and their infrastructure providers just as readily. Signal runs on AWS, which holds a $600M CIA contract and subsequent NSA contracts. WhatsApp is owned by Meta, which discloses data in response to thousands of government requests annually. iMessage runs on Apple’s contracted data centres. Microsoft Teams runs on Azure. The report puts the asymmetry plainly:

The OCCRP investigation appears to apply a standard of suspicion to Russian-connected infrastructure that is not symmetrically applied to U.S.- or European-connected infrastructure, despite comparable (and often more direct) relationships between Western technology providers and Western intelligence services. This asymmetry suggests a politically motivated framing rather than a neutral security analysis.

The technical vulnerability is real. The specific adversary attribution is investigative work, not technical analysis.

None of these qualifications reduces the technical vulnerability. They sharpen the claim being made about it, and we hope they are preserved in future coverage.

What the tracking looks like in practice

Chapter 5 of the report walks through a hypothetical but technically faithful deanonymisation timeline for a journalist using Telegram to communicate with sources. The point of the case study is that the tracking does not require future technology or nation-state infrastructure. It uses standard ISP logging already deployed for troubleshooting and billing, mobile carrier deep packet inspection commercially available from vendors like Sandvine and Procera, captive portal authentication logs standard in enterprise and public WiFi, and database queries to correlate identifiers across datasets.

The chain runs in three steps. The first step is passive observation of an auth_key_id across several networks. The second step is the establishment of a single identity anchor. In the case study, a press-conference WiFi registration ties the auth_key_id to a name and outlet. The third step is retroactive search of all logged traffic for that identifier across home ISP, mobile carrier, airport WiFi, and even a VPN session. The VPN successfully masks the IP from Telegram’s perspective, but it does not protect the auth_key_id from observation by the VPN provider or by any infrastructure between the VPN exit and the Telegram server. The case study takes twenty days from initial observation to retroactive analysis, and it uses only logs the providers were already maintaining for unrelated reasons.

The report is careful to keep this on the right side of the line. Two legal and ethical disclaimers appear in the body of the report (in Chapters 1 and 5), and Appendix A summarises the legal framework governing interception in the EU, US, and Germany. The appendix concludes:

Where the report states that auth_key_id is technically observable, that should be read as a statement of technical possibility. Any operational collection or retention of such identifiers requires legal authority and appropriate procedural safeguards; otherwise it risks criminal and civil liability.

The vulnerability described in the report is a latent capability under the protocol design. It is for legal frameworks to constrain how that capability may lawfully be exercised.

On editorial independence

Two clarifications are worth offering.

The first concerns the engagement itself. We accepted it on the conditions quoted above, and we delivered on them. The report concluded against the commissioning party’s preferred outcome on the central technical questions. The auth_key_id exposure is real. The deployed protocol does not rotate at a cadence that defeats tracking. PFS does not address the tracking problem. The desktop client’s use of port 443 does not constitute transport encryption. The architectural responsibility for fixing this lies with Telegram, not with its infrastructure providers. This is the firm’s standing practice, and the engagement letter was structured the way it was precisely so that the practice could hold under pressure.

The second concerns the report’s qualifications of OCCRP’s framing. Those qualifications, on Claim 2 and on Claim 4, are not concessions to the commissioner. They are the same editorial standard applied in the other direction. The methodological footnote on Woźniak, quoted earlier, is the cleanest statement of that standard. Technical claims are evaluated on the evidence. Political characterisations are noted as falling outside the technical scope, regardless of which party offers them. We applied the same rule to OCCRP’s framing that we applied to GNM’s preferences.

On the publication route

The report became public because Global Network Solutions, Inc. attached it to a civil filing in Switzerland, where the matter is currently in litigation. We did not publish it. iStories obtained the document from the materials of that case.

We were not contacted by iStories prior to their publication. We note this without grievance, but for the record. The standard practice when attributing technical conclusions to a named expert firm is to confirm with that firm both that the document is genuine and that the proposed framing of its conclusions is accurate. The document is genuine. The framing is substantially accurate, but compressed in places where the report itself is more careful, particularly on Claims 2 and 4, where the report’s qualifications are the kind of detail a one-paragraph paraphrase tends to elide. We mention this because publications of iStories’ standing are normally diligent on the verification step. The situation it could have produced, in which a forged or altered document was attributed to us in a politically sensitive context, is the kind of failure that next-time diligence is designed to prevent.

What remains

The remedy is not novel and does not require theoretical advances. WhatsApp wraps its Noise transport in TLS. Signal uses TLS, and has historically used that TLS layer for further useful purposes such as censorship-circumvention domain fronting. iMessage and every other major messenger of comparable scale uses TLS or an equivalent transport-encrypted layer. The cost of TLS termination is well understood, and modern implementations are mature on every platform Telegram supports. The only remaining barrier to closing the auth_key_id exposure is an organisational decision on Telegram’s part to make transport-layer encryption mandatory for MTProto and to remove the unencrypted fallback paths.

Until that decision is taken, the privacy properties of Telegram against passive network observers are what the report describes. The report’s executive summary puts the conclusion more plainly than we will here: the present design represents “not merely a technical failing, but a fundamental abdication of Telegram’s responsibility to protect user privacy through appropriate cryptographic measures.” Users in high-risk categories, including journalists, activists, dissidents, and anyone whose communications may attract the interest of state or near-state actors, should incorporate that exposure into their threat models. The standard countermeasures, such as VPNs, Tor, regular network switching, and SIM swaps, do not address the underlying vulnerability, because the vulnerability is in the protocol rather than in the user’s network.

The full report is linked above. It contains the formal evaluation of each OCCRP claim, the illustrative deanonymisation case study, the appendix on legal context, and the engagement-letter clauses quoted in this post.

Applied Cryptography Course: Welcome, Class of Summer 2026!

Tue, 12 May 2026 00:00:00 +0000

The Summer 2026 cohort for our Applied Cryptography online program has been selected, and we are delighted with who is coming. Fifty students from nine institutions across Lebanon will join us online from June 9 through October 10 for a full semester of modern cryptography, taught the way we teach it at AUB.

This is a full-featured university course delivered completely free to Lebanese students, and reading the applications we could already tell this was going to be a good cohort to teach.

cohort · summer 2026

50 admitted

students admitted

institutions

course topics

hands-on projects

What the course covers

Applied Cryptography is a two-part course. Part 1 builds the theoretical foundations of modern cryptography from first principles: pseudorandomness, chosen-plaintext and chosen-ciphertext security, collision-resistant hash functions, hard problems and Diffie-Hellman, elliptic curves, and digital signatures, all developed inside a rigorous provable-security framework. Part 2 then applies that foundation to the systems that actually run the modern internet: TLS, the cautionary tale of RC4, secure messaging protocols like Signal, end-to-end encrypted cloud storage, high-assurance cryptographic implementations, post-quantum cryptography, cryptocurrency cryptography, zero-knowledge proofs, secure multiparty computation, and fully homomorphic encryption. Eighteen topics in total, paced over a full semester.

Around the lectures sits a serious problem-set program (eight problem sets, paced with the topics) and a hands-on project track. Students choose one or two projects from a menu of eight: build a password manager, design a secure messenger, formally verify a TLS-like protocol in ProVerif, implement a zero-knowledge Battleship game, migrate a system to post-quantum cryptography, build private set intersection for contact discovery, design a privacy-preserving age verification system, or construct a time-locked message capsule. The implementation languages are Go and Rust, and the course ships Go and Rust starter kits so students can get writing code from day one.

There is also a four-week rotating schedule running alongside the technical content. Week 1 is a paper reading, where the cohort tears apart a seminal or recent cryptography paper together. Week 2 is student presentations, with 15-minute talks and lightning talks. Week 3 is a writing workshop on technical and academic writing, including LaTeX, audit reports, and security disclosures. Week 4 is a career café with guest speakers from industry and academia. The goal is to send students out of the semester with cryptographic knowledge, plus the surrounding skills the field actually needs.

The full setup, including the two required textbooks (Mike Rosulek’s The Joy of Cryptography and Jean-Philippe Aumasson’s Serious Cryptography, 2nd Edition), the extensive reading list of around ninety research papers and technical resources, problem-set specifications, and project briefs, is all available on the course website under a Creative Commons license. Everyone is welcome to use it, cohort or not.

What an opportunity this is

Lebanon has a remarkable density of talented computer-science students. Dedicated cryptography coursework is not always easy to come by, and the gap between a standard undergraduate curriculum and what is needed to do serious work in the field can be a wide one to cross alone. Applied Cryptography 2026 is built to help close that gap, no matter which Lebanese university you happen to be enrolled at, and at no cost.

A few fun snapshots of the cohort

We thought it would be fun to share a quick demographic look at the group of fifty before the course kicks off. Nothing scientific, just some incidental snapshots.

Where they study

distribution · institution

n=50

Lebanese University23 · 46%
American University of Beirut17 · 34%
Non-Lebanese5 · 10%
Saint-Joseph University2 · 4%
Lebanese International U.1 · 2%
Islamic University of Lebanon1 · 2%
University of Balamand1 · 2%

A nice spread across Lebanese universities, with the Lebanese University and AUB contributing the most students. The five non-Lebanese admits joined us through instructor discretion as exceptional cases, and most of them are from the Middle East and North Africa region: a Tunisian graduate student at the EPFL/ETH joint program in Zurich, a Syrian formal-verification specialist, and a Lebanese national pursuing a PhD in Luxembourg. The other two come from further afield: a graduate student from Latin America and a career applied-cryptography engineer based in the UK.

Gender

composition · gender

n=50

Male34 · 68%
Female16 · 32%

Roughly a third of the cohort is women, which sits a touch above the typical Lebanese-engineering-school baseline, and we are happy to see that and committed to pushing it higher in future editions.

What the cohort brings to the room

accomplishments · incidental highlights

aggregate

Master's or PhD student

Applied-crypto / E2EE build

CTF or pen-test competition

Top GPA / national-ranking top-10

Peer-reviewed publication

Founded startup or initiative

Formal verification (Lean / Dafny / Certora)

admitted students with this on their CV (out of 50)

The range of what this cohort has already done is wild. Graduate-level coursework, peer-reviewed publications, formal-verification contributions to widely deployed protocols, CTF placements, applied-cryptography builds already in users’ hands, and several founded companies and initiatives. We cannot wait to see what this group does together over the summer.

See you on June 9

Lectures run Tuesdays and Thursdays, 11:00 to 12:30 Beirut time. To the admitted students: congratulations, welcome aboard, and we will see you in three weeks for what is going to be a really fun semester.

To everyone else: every piece of course material is publicly available on the course website under Creative Commons, so you can follow along at your own pace. And we plan to run the program again. Come back next year!

hpke-ng: Faster, Smaller, Harder HPKE for Rust

Fri, 08 May 2026 00:00:00 +0000

Today we’re releasing hpke-ng, a clean-slate Rust implementation of HPKE (RFC 9180). It is published under Apache-2.0 OR MIT, and you can install it now with cargo add hpke-ng.

We benchmark hpke-ng against the two major Rust HPKE libraries: hpke-rs, CE Labs’ library and currently the most widely deployed, and rust-hpke, the older type-state-based implementation by Michael Rosenberg. Across 126 head-to-head measurements, 76 against hpke-rs and 50 against rust-hpke (which doesn’t support every ciphersuite hpke-ng or hpke-rs do), hpke-ng wins 103, ties 19, and loses 4. The wins concentrate in the post-quantum decap path (−54% to −55% on ML-KEM, the largest deltas in the dataset; rust-hpke has no post-quantum support), the classical decap path (−41% on X25519 vs hpke-rs, −31% vs rust-hpke), the single-shot open path (every payload size a clean win against both libraries), the post-quantum and ChaCha20 setup paths, and the export path (a new datapoint added in this round: −72% to −76% across all five output lengths vs hpke-rs). End-to-end roundtrip, one full seal-and-open against the same recipient, comes in at −30% vs both libraries on a 1 KiB message. The ties cluster on rows where the underlying primitive crate dominates wall time and the framing overhead is too small to matter.

cargo bench · comparative

126 head-to-head benchmarks · 2 libraries

vs hpke-rs76 benchmarks

62wins

10tied

4losses

vs rust-hpke50 benchmarks

41wins

9tied

0losses

combined126 benchmarks

103wins

19tied

4losses

hpke-ng faster (>3% delta) within criterion noise band (±3%) competitor faster

All three libraries lean on the RustCrypto family of primitive crates, with one exception we’ll flag below: rust-hpke pulls a different P-256 implementation, and you’ll see the gap show up at the primitive layer when we get there. On the rows where the underlying primitive crate matches, the cryptography itself is identical: all three pass the full RFC 9180 known-answer-test set on the vectors we hand-checked, and all three produce byte-identical wire output to each other on every ciphersuite we differentially tested. The wins are gains in framing, monomorphization, allocation behaviour, and dispatch, not in the underlying crypto math. That is the point: the math is a solved problem, and the surrounding library is where the engineering still has slack.

Why we built another HPKE library

Earlier this year we found and reported two security bugs in hpke-rs. The first was a missing RFC 9180 §7.1.4 zero-shared-secret check: a low-order or identity public key forces the X25519 shared secret to all zeros, after which the rest of the key schedule becomes deterministic and predictable to anyone who knows the static recipient key. The fix is a single comparison against zero, which RFC 9180 explicitly requires; it was missing. The second was a u32 sequence-counter that silently wrapped in release builds, reusing nonces after 2³² messages. Nonce reuse in AEAD is catastrophic: for AES-GCM it leaks the authentication key, and for ChaCha20-Poly1305 it leaks plaintext via XOR. The wrap was happening below the type system, in a release build, with no diagnostic. Both are now fixed. We documented the broader pattern of bugs we kept finding in libraries marketed under “high assurance” branding in February.

rust-hpke, by contrast, is not a library we have audit findings against. It is older (its 0.x line predates hpke-rs by years), uses a type-state design similar to the one we settled on for hpke-ng, and has the careful, hand-tuned feel of a personal project that has aged well. We added it to this round of benchmarks for exactly that reason: comparing only against hpke-rs invites the objection that the bar is low. rust-hpke raises it. The deltas you’ll see below are against both libraries; where rust-hpke supports a ciphersuite, we show its row alongside hpke-rs’s. It doesn’t support post-quantum KEMs, X-Wing, or secp256k1, so those rows stay two-way.

That experience, together with the day-to-day frictions of integrating HPKE through libraries that weren’t built to make those bug classes structurally impossible, is what got us thinking about a rewrite. Three frictions in particular kept showing up in hpke-rs.

The provider abstraction. hpke-rs is structured as a generic library over an HpkeCrypto trait, with two backend implementations, RustCrypto and libcrux, shipped as separate crates. The abstraction is real engineering and serves a real purpose: it lets a deployment swap the underlying crypto stack without touching call sites. The cost is that every primitive call goes through a trait dispatch, every Hpke value carries a 344-byte instance struct (most of it a 256-byte ChaCha20 PRNG state), and the workspace is four crates instead of one.

The struct-owned PRNG. Hpke<Crypto>::new constructs and stores a PRNG. That PRNG is reused across operations, which is fine functionally but creates a subtle aliasing hazard: cloning an Hpke does not clone the PRNG state, per the rustdoc, so a careless clone can reset randomness in ways that aren’t visible at the call site. Nothing in the type system stops it, and nothing in a test suite is likely to catch it.

Option<&[u8]> for required-by-mode arguments. hpke.seal(&pk, info, aad, pt, None, None, None) is the canonical Base-mode call. The three Nones are the PSK, PSK ID, and sender static key, all of which are required in the Auth or AuthPsk modes. The single seal method accepts every mode by making mode-specific arguments optional, which means the type system can’t tell you that you’ve built a Base-mode call with a PSK supplied.

These are not catastrophic problems. They’re the kind of small persistent costs you stop noticing until you build the alternative.

The shape change: enum dispatch becomes type-state

The single biggest design difference between hpke-ng and hpke-rs is what carries the ciphersuite. In hpke-rs, the ciphersuite is four runtime enums (Mode, KemAlgorithm, KdfAlgorithm, AeadAlgorithm) constructed at Hpke::new time. In hpke-ng, the ciphersuite is the type itself, as in Hpke<DhKemX25519HkdfSha256, HkdfSha256, ChaCha20Poly1305>, and the struct body is PhantomData<(K, F, A)>. Zero bytes at runtime; everything resolved at the call site by the compiler.

canonical seal · "encrypt one message"

hpke-rs7 args · 3× Option<&[u8]>

let mut hpke = Hpke::<HpkeRustCrypto>::new(
    Mode::Base,
    KemAlgorithm::DhKem25519,
    KdfAlgorithm::HkdfSha256,
    AeadAlgorithm::ChaCha20Poly1305,
);
let kp = hpke.generate_key_pair()?;
let (sk, pk) = kp.into_keys();
let (enc, ct) = hpke.seal(
    &pk, info, aad, pt,
    None, None, None, // psk, psk_id, sk_s
)?;

hpke-ng5 args · zero placeholders

type Suite = Hpke<
    DhKemX25519HkdfSha256,
    HkdfSha256,
    ChaCha20Poly1305,
>;
let mut os = OsRng;
let mut rng = os.unwrap_mut();
let (sk, pk) = DhKemX25519HkdfSha256::generate(&mut rng)?;
let (enc, ct) = Suite::seal_base(
    &mut rng, &pk, info, aad, pt,
)?;

rust-hpke’s API is closer to hpke-ng’s: it also encodes KEM / KDF / AEAD as type parameters, and exposes setup_sender::<Aead, Kdf, Kem, _>(&OpModeS::Base, &pk, info, &mut rng) as the canonical entry point. The visible consequence is the same as in hpke-ng: no Option placeholders for unused fields. The wider difference between rust-hpke and hpke-ng is in scope rather than shape. rust-hpke ships fewer ciphersuites (no secp256k1, no post-quantum KEMs), bundles the AEAD into the type chain rather than letting Context specialize on it, and doesn’t expose raw encap/decap separately from setup. We’ll come back to that last point in the methodology note.

The visible consequence of hpke-ng’s type-state choice is the call site. The invisible consequence is what the compiler can rule out:

Operationhpke-rshpke-ng

Hpke::<XWingDraft06, _, _>::seal_auth(...)

runtime Error::UnsupportedKemOperation

compile trait bound K: AuthKem not satisfied

Hpke::<_, _, ExportOnly>::seal_base(...)

runtime HpkeError::InvalidConfig

compile no seal_base on ExportOnly

Wrong KemAlgorithm for a private key

runtime mismatch error at setup_*

compile key types are KEM-tagged

Base-mode call with Some(psk) argument

runtime HpkeError::UnnecessaryPsk

compile seal_base has no PSK parameter

Each row is a runtime error in hpke-rs and a compiler diagnostic in hpke-ng. rust-hpke catches most of the same shapes at compile time too, but hpke-ng goes further on the Auth/Base and ExportOnly rows, because the method-set split there relies on per-KEM trait bounds (K: AuthKem) and per-AEAD method availability that rust-hpke doesn’t model.

This isn’t theoretical. We’ve seen each of those four shapes in production code reviews, usually as a stale match arm catching the runtime error and turning it into a generic 500. Surfacing them as compile errors deletes a class of code path entirely.

Feature parity

Before going further: the obvious skeptical question is what got cut? The answer is one thing, deliberately, and it’s the thing that buys the wins everywhere else.

hpke-rsrust-hpkehpke-ng

DH KEMs (X25519, X448, P-256, P-384, P-521, secp256k1)✓ all 64 (no X448, no secp256k1)✓ all 6

Post-quantum KEMs (X-Wing draft-06, ML-KEM-768, ML-KEM-1024)✓ all 3 (experimental, upstream-flagged unstable)none✓ all 3 (pq feature)

KDFs (HKDF-SHA-256 / -384 / -512)✓ all 3✓ all 3✓ all 3

AEADs (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, ExportOnly)✓ all 4✓ all 4✓ all 4

Modes (Base, Psk, Auth, AuthPsk)✓ all 4✓ all 4✓ all 4

RFC 9180 KAT conformance✓ pass✓ pass✓ pass

Type-state ciphersuite selectionruntime enums✓ type-params✓ type-params + per-mode method-set

Compile-time-rejected operation classes0~24

Raw encap / decap exposed (separable from setup)no (only via setup_*)no (only via setup_*)✓ yes

Pluggable crypto provider (multiple backends)✓ RustCrypto + libcrux✓ generic over CryptoRng— RustCrypto only

hpke-ng supports every ciphersuite hpke-rs’s RustCrypto provider supports (it’s a superset of rust-hpke), passes the RFC 9180 KAT vector set, and adds two structural capabilities neither alternative has: a deeper method-set split that catches more configuration errors at compile time, and standalone encap/decap exposed alongside the high-level setup paths.

The one thing hpke-rs has that hpke-ng deliberately doesn’t: a pluggable crypto provider. hpke-rs ships an HpkeCrypto trait with two backend implementations, RustCrypto and libcrux; a deployment can swap one for the other at compile time. hpke-ng ships one provider, RustCrypto, and removes the abstraction. Everything else follows from that tradeoff. It’s why Hpke<...> is zero-sized, why Context::seal is monomorphized rather than dispatched, why the workspace is one crate, and why the canonical call site is five arguments instead of seven.

The libcrux half of that tradeoff is, in our view, not a feature worth chasing. Our February audit of CE Labs’ “formally verified” libraries found undisclosed silent cryptographic failures in libcrux-ml-dsa (platform-dependent SHA-3 corruption that was patched without a public advisory), entropy-reducing pre-hash clamping in Ed25519, and a denial-of-service panic in libcrux-psq’s AES-GCM decryption path. CE Labs’ public response acknowledged the findings without retracting the “highest level of assurance” marketing language attached to the library; our follow-up analysis and an independent paper have since surfaced further specification deviations in libcrux-ml-dsa. The “formally verified” framing that draws users to libcrux does not, on the evidence we have assembled, describe the engineering you are getting. If you’re using RustCrypto anyway, which is what hpke-ng does by default and what most hpke-rs deployments do in practice, the provider abstraction is paying rent for a backend you would be wise to avoid.

Speed

The full benchmark protocol is in cargo bench --features comparative in the hpke-ng repository: criterion harness, sample sizes 40–60 per group depending on per-iteration cost, 2–3 second measurement windows, RUSTFLAGS="-C target-cpu=native", lto = "thin", codegen-units = 1. Apple Silicon M-series, macOS. The numbers below are the median across two independent bench runs. The post-quantum rows enable hpke-rs-rust-crypto’s experimental feature flag. Without it, hpke-rs’s PQ KEMs return UnsupportedKemOperation at runtime; the upstream comment on the gate is “broken and pre-releases. Disabling them until they are stable.” rust-hpke doesn’t ship post-quantum at all, so the PQ and X-Wing rows are two-way (hpke-ng vs hpke-rs only).

Methodology note: the _via_setup_* suffix. hpke-ng exposes raw encap and decap as separable KEM operations. hpke-rs and rust-hpke do not. Their nearest public API is setup_sender / setup_receiver, which performs the KEM operation plus the HPKE key schedule plus Context construction. Where the benchmark name carries a _via_setup_* suffix, it is measuring that fuller path because there is no narrower one available; rows so labeled are explicitly not apples-to-apples with hpke-ng’s bare-operation rows, and that is the honest framing. We still include them, because the gap reflects an API granularity difference that is itself meaningful to anyone trying to batch KEM operations or pre-compute encap material. We also seed hpke-rs’s deterministic PRNG once per benchmark group, in setup, never inside a timed b.iter() closure; the bare seed() cost (~58 ns) is deliberately hoisted out so it does not bias any hpke-rs measurement.

The wins concentrate in five places: the post-quantum KEM path (the largest deltas in the entire dataset, peaking at −55% on ML-KEM-1024 decap), the classical KEM decap path, the single-shot open path (every payload size, both AEADs, against both competitors), the post-quantum and ChaCha20 setup paths, and the brand-new export path (−72% to −76% across all five output lengths). Start with the KEM operations on X25519:

KEM operations · X25519

hpke-rsrust-hpkehpke-ng

generate

8.00 µs

9.23 µs

8.27 µs

+3% rs · −10% rh

derive_key_pair

8.80 µs

8.94 µs

7.93 µs

−10% rs · −11% rh

encap†

37.97 µs

40.45 µs

30.41 µs

−20% rs · −25% rh

decap†

37.03 µs

32.00 µs

21.96 µs

−41% rs · −31% rh

Lower is faster. Bars normalized per-row to max(rs, rh, ng). † on encap/decap: hpke-ng measures the raw KEM op; hpke-rs and rust-hpke have no such API, so the bar shows their setup_sender/setup_receiver (KEM op + key schedule + Context construction). See the methodology note.

The decap row is where hpke-ng’s design pays off most: hpke-ng caches the recipient’s serialized public-key bytes alongside the secret, so decap no longer pays a base-point scalar multiplication just to rebuild the recipient-PK piece of kem_context on every call. The classical libraries each run that scalar mult per setup_receiver. The encap row is the methodology note in action: hpke-ng can isolate encap from the surrounding key schedule, the others can’t, and a use case that wants to precompute encap material or batch ephemeral generation can exploit that gap directly. The generate and derive_key_pair rows are fully comparable across all three libraries; hpke-ng wins by 10% on derive_key_pair (cached-PK monomorphization) and is tied with hpke-rs on generate (the bare X25519 keypair generation, where everyone reaches the same primitive ceiling).

Setup is the combined fixed cost paid every time a sender or receiver context is constructed: KEM op + key schedule + Context allocation. The wins are consistent across ChaCha20, AES-128, AES-256, all three modes:

Setup paths · sender / receiver / PSK · X25519 and P-256

hpke-rsrust-hpkehpke-ng

X25519+ChaCha20
sender (Base)

38.69 µs

43.07 µs

30.60 µs

−21% rs · −29% rh

X25519+ChaCha20
receiver (Base)

38.31 µs

34.86 µs

21.95 µs

−43% rs · −37% rh

X25519+ChaCha20
sender (PSK)

39.87 µs

40.53 µs

29.56 µs

−26% rs · −27% rh

X25519+AES-128
sender (Base)

40.60 µs

41.07 µs

31.91 µs

−21% rs · −22% rh

X25519+AES-256
sender (Base)

38.16 µs

41.51 µs

30.75 µs

−19% rs · −26% rh

P-256+AES-128
sender (Base)

150.16 µs

220.93 µs

139.35 µs

−7% rs · −37% rh

P-256+AES-256
sender (Base)

150.66 µs

220.46 µs

139.53 µs

−7% rs · −37% rh

secp256k1+ChaCha20
sender (Base)

59.05 µs

47.12 µs

−20% rs · — rh unsupported

Receiver-side wins are larger than sender-side because both decap and the post-decap key schedule benefit from the cached public-key bytes. rust-hpke's P-256 path is markedly slower than hpke-rs's, and the gap there is at the primitive layer (rust-hpke uses a different P-256 crate); hpke-ng is faster than both regardless.

The post-quantum KEMs add a structural dimension to the comparison that the classical KEMs don’t. hpke-ng stores MlKem* private keys as the 64-byte (d, z) seed plus the materialized FIPS 203 expanded decapsulation key, built once at construction, kept in the PrivateKey wrapper, reused on every decap. hpke-rs stores only the seed and rebuilds the expanded key on every setup_receiver call by re-running FIPS 203 KeyGen_internal. That single design choice is why ML-KEM decap shows up at −54% to −55%, the largest single deltas in the dataset. rust-hpke doesn’t ship post-quantum at all, so these rows are two-way. ML-KEM-768 first:

KEM operations · ML-KEM-768 (rust-hpke unsupported)

hpke-rshpke-ng

generate

18.85 µs

17.66 µs

−6% rs

derive_key_pair

14.54 µs

14.26 µs

−2% rs

encap†

24.62 µs

14.70 µs

−40% rs

decap†

40.86 µs

18.58 µs

−55% rs

decap −55%, encap −40%. hpke-ng caches the expanded decapsulation key in the private key and the parsed encapsulation key in the public key; hpke-rs rebuilds both from raw bytes on every call.

ML-KEM-1024, the higher-security parameter set, shows the same shape with larger absolute numbers and the same architectural delta in the same place:

KEM operations · ML-KEM-1024 (rust-hpke unsupported)

hpke-rshpke-ng

generate

27.55 µs

28.43 µs

+3% rs

derive_key_pair

23.07 µs

24.59 µs

+7% rs

encap†

36.97 µs

22.99 µs

−38% rs

decap†

61.03 µs

27.24 µs

−55% rs

Same pattern as ML-KEM-768 at higher security level: encap −38%, decap −55%. The +7% on derive_key_pair is the cost of cloning the larger ML-KEM-1024 expanded encapsulation key into the public-key wrapper at construction, paid once and recovered on every subsequent decap.

X-Wing, the X25519 + ML-KEM-768 hybrid, picks up the same DecapsulationKey-caching trick we applied to ML-KEM, plus the parsed EncapsulationKey cache on the encap side. The decap delta lands close to the ML-KEM rows:

KEM operations · X-Wing draft-06 (rust-hpke unsupported)

hpke-rshpke-ng

generate

40.42 µs

38.15 µs

−6% rs

derive_key_pair

38.77 µs

37.63 µs

−3% rs

encap†

66.01 µs

55.26 µs

−16% rs

decap†

115.75 µs

72.64 µs

−37% rs

decap −37%: the construction-side expand_key that DecapsulationKey::from(seed) runs (SHAKE-256 + ML-KEM-768 keygen) is now amortized to once per private key.

The same pattern propagates to setup paths. setup_sender is dominated by encap; setup_receiver is dominated by decap; the ML-KEM rows widen accordingly. rust-hpke is unsupported across all of these:

Setup paths · post-quantum (HKDF-SHA-256 + ChaCha20-Poly1305) (rust-hpke unsupported)

hpke-rshpke-ng

X-Wing
sender (Base)

67.10 µs

58.38 µs

−13% rs

X-Wing
receiver (Base)

125.95 µs

74.83 µs

−41% rs

ML-KEM-768
sender (Base)

23.90 µs

16.39 µs

−31% rs

ML-KEM-768
receiver (Base)

39.74 µs

19.16 µs

−52% rs

ML-KEM-1024
sender (Base)

34.19 µs

23.77 µs

−31% rs

ML-KEM-1024
receiver (Base)

60.28 µs

27.99 µs

−54% rs

All six post-quantum setup rows: 6 wins, 0 ties, 0 losses.

The single-shot open path, meaning setup_receiver plus Context::open for one message, is where hpke-ng wins most consistently across payload size. Six rows across two orders of magnitude, against both competitors, every row is hpke-ng:

Single-shot open · X25519 + HKDF-SHA-256 + ChaCha20-Poly1305

hpke-rsrust-hpkehpke-ng

64 B

38.19 µs

35.52 µs

23.21 µs

−39% rs · −35% rh

256 B

39.09 µs

33.79 µs

22.85 µs

−42% rs · −32% rh

1 KiB

38.57 µs

34.08 µs

23.30 µs

−40% rs · −32% rh

4 KiB

42.89 µs

38.18 µs

27.69 µs

−35% rs · −28% rh

16 KiB

61.20 µs

58.12 µs

45.32 µs

−26% rs · −22% rh

64 KiB

131.77 µs

128.58 µs

116.16 µs

−12% rs · −10% rh

Lower is faster. Open inherits the full setup-receiver win, including the cached pk_bytes shaving a scalar mult off every decap, so the small-payload regime where setup dominates picks up the largest deltas. All 12 cells against both libraries are hpke-ng wins.

The AES-128-GCM seal sweep shows hpke-ng 6–22% ahead from 64 B through 64 KiB against both competitors. The cached AES cipher state (round keys plus the GHash precomputed table, built once at key-schedule time) eliminates the per-call expansion that hpke-rs runs on every seal:

Single-shot seal · X25519 + HKDF-SHA-256 + AES-128-GCM

hpke-rsrust-hpkehpke-ng

64 B

39.16 µs

41.46 µs

31.87 µs

−19% rs · −23% rh

256 B

39.67 µs

42.18 µs

30.91 µs

−22% rs · −27% rh

1 KiB

42.41 µs

44.71 µs

33.60 µs

−21% rs · −25% rh

4 KiB

55.20 µs

56.50 µs

44.25 µs

−20% rs · −22% rh

16 KiB

99.38 µs

100.21 µs

93.00 µs

−6% rs · −7% rh

64 KiB

286.56 µs

282.39 µs

260.29 µs

−9% rs · −8% rh

At 64 KiB the AES-NI bulk encryption cost dominates and the framing delta is the residual, still a clean ~8% win against both competitors.

The ChaCha20 seal sweep mirrors the AES one but reaches further into the large-payload regime (up to 256 KiB) where the AEAD primitive dominates and all three libraries converge to the same ceiling. The interesting story is what happens before convergence:

Single-shot seal · X25519 + HKDF-SHA-256 + ChaCha20-Poly1305

hpke-rsrust-hpkehpke-ng

16 B

44.40 µs

44.59 µs

30.46 µs

−31% rs · −32% rh

64 B

40.46 µs

41.98 µs

31.84 µs

−21% rs · −24% rh

256 B

38.95 µs

41.38 µs

30.03 µs

−23% rs · −27% rh

1 KiB

40.11 µs

42.50 µs

31.81 µs

−21% rs · −25% rh

4 KiB

44.70 µs

47.03 µs

35.85 µs

−20% rs · −24% rh

16 KiB

62.65 µs

64.97 µs

53.70 µs

−14% rs · −17% rh

64 KiB

135.19 µs

138.98 µs

126.17 µs

−7% rs · −9% rh

256 KiB

423.89 µs

420.97 µs

409.19 µs

−3% rs · tie rh

At 256 KiB the ChaCha20-Poly1305 primitive both libraries call identically dominates the wall time and the deltas vanish into noise. At the primitive's ceiling, the framing has nothing left to remove.

Once setup is paid, the post-setup hot path is just Context::seal and Context::open: nonce computation + AEAD primitive call, no KEM, no key schedule. We benchmark these in isolation by running sender and receiver contexts in lockstep outside the timed loop, then measuring seal-then-open on every iteration. This is where the framing-vs-primitive divide is sharpest:

Post-setup hot path · `Context::seal` · X25519+ChaCha20

hpke-rsrust-hpkehpke-ng

64 B

252.51 ns

222.61 ns

217.77 ns

−14% rs · tie rh

1 KiB

1.63 µs

1.60 µs

1.58 µs

tie rs · tie rh

16 KiB

23.46 µs

25.24 µs

23.48 µs

tie rs · −7% rh

64 KiB

93.48 µs

97.70 µs

97.94 µs

+5% rs · tie rh

At 64 B framing dominates and hpke-ng's stack-array nonce + monomorphized AEAD call wins 14% vs hpke-rs; at 64 KiB the AEAD primitive owns the wall time and hpke-rs's slightly tighter inner loop edges ahead by 5%, the only post-setup loss in the entire suite.

Post-setup hot path · `Context::open` · X25519+ChaCha20

hpke-rsrust-hpkehpke-ng

64 B

507.59 ns

460.40 ns

439.10 ns

−14% rs · −5% rh

1 KiB

3.28 µs

3.21 µs

3.27 µs

tie rs · tie rh

16 KiB

46.99 µs

46.74 µs

46.88 µs

tie rs · tie rh

64 KiB

187.32 µs

187.28 µs

187.35 µs

tie rs · tie rh

Open's pattern mirrors seal: framing-dominant at 64 B (hpke-ng −14% vs hpke-rs), primitive-bound everywhere else (all three libraries hit the same ceiling within 0.04%).

The convergence at 64 KiB on both seal and open is the most diagnostic single result in the suite: all three libraries reach the same wall-clock cost of the underlying ChaCha20-Poly1305 primitive, because all three call the same code. hpke-ng matches that ceiling without overhead.

Export

The HPKE secret-export interface, Context::export(ctx, len), is a new addition to this round of benchmarks. It is also the largest single delta in the dataset by a wide margin. Five output lengths, ranging from 16 B (typical for keying a downstream symmetric cipher) to 256 B (room for several derived secrets), against hpke-rs only. rust-hpke’s export() writes into a caller-supplied &mut [u8] rather than returning a Vec, so benchmarking it at these lengths would include a Vec allocation in the timed path and bias the comparison; we omit it rather than ship a misleading number.

Export · X25519 + HKDF-SHA-256 + ChaCha20-Poly1305 (rust-hpke API-incompatible)

hpke-rshpke-ng

16 B

497.37 ns

117.09 ns

−76% rs

32 B

500.27 ns

131.15 ns

−74% rs

64 B

842.48 ns

223.93 ns

−73% rs

128 B

1.52 µs

406.16 ns

−73% rs

256 B

2.87 µs

806.43 ns

−72% rs

All five rows wins of 72–76%, the largest sustained delta in the suite. Export is on the small enough path that the per-call cost is dominated by what the library does *around* the HKDF call.

The −72% to −76% range is consistent across all five sizes, which tells you the win is structural, not size-dependent. hpke-ng’s export is a labeled-HKDF call with a stack-allocated label and a single allocation for the output Vec; hpke-rs’s path goes through the HpkeCrypto trait, allocates intermediate buffers for the LabeledExtract and LabeledExpand arguments, and routes the HKDF call itself through the provider abstraction. That’s overhead that doesn’t appear in hpke-ng because the type system already knows the KDF at the call site.

End-to-end roundtrip

A single number for the eyes-glaze-over question of “how fast is the whole thing, end to end”: one 1 KiB seal-and-open against the same recipient keypair, full setup on each side every iteration, three libraries:

End-to-end roundtrip · 1 KiB · X25519+ChaCha20

hpke-rsrust-hpkehpke-ng

seal + open

77.31 µs

77.11 µs

53.90 µs

−30% rs · −30% rh

hpke-rs and rust-hpke land within 0.3% of each other, so the framing differences between them roughly cancel at this granularity. hpke-ng is a clean 30% faster than both.

Memory

Memory has two halves. The configuration and per-context state, where hpke-ng is uniformly smaller, and the per-key footprint, where the post-quantum KEMs introduce a deliberate tradeoff in the other direction. The memory comparison below is against hpke-rs only; rust-hpke’s Context shape varies with its type parameters in ways that aren’t directly comparable to hpke-rs’s enum-keyed instance struct.

sizeof(Hpke<K, F, A>)−344 B (zero-sized)

hpke-rs

344 B

hpke-ng

PhantomData · 0 B

sizeof(Context<_, _, ChaCha20Poly1305>)−312 B (−78%)

hpke-rs

400 B

hpke-ng

88 B

sizeof(Context<_, _, Aes128Gcm>)+392 B (cached AES round keys + GHash)

hpke-rs

400 B

hpke-ng

792 B

sizeof(Context<_, _, Aes256Gcm>)+648 B (cached AES round keys + GHash)

hpke-rs

400 B

hpke-ng

1,048 B

hpke-ng::Hpke<K, F, A> is PhantomData<(K, F, A)>. There is no runtime presence; it costs zero bytes and cargo expand confirms the compiler optimizes it out completely. hpke-rs::Hpke<Crypto> carries a 256-byte ChaCha20 PRNG plus four enum discriminants and padding (344 bytes measured at the time of writing).

Context is where hpke-ng’s per-AEAD specialization shows up. With ChaCha20Poly1305 the cipher state is just the 32-byte key, so Context is 88 bytes, under a quarter of hpke-rs’s 400, since hpke-rs’s Context carries a per-instance PRNG plus trait-object overhead that hpke-ng’s monomorphized design doesn’t need. With AES-GCM the trade goes the other way: hpke-ng caches the expanded round keys plus the precomputed GHash table inline so that Context::seal doesn’t pay key-schedule expansion on every call. That is why AES-128 single-shot seal is 6–22% faster across the sweep. Streaming AES applications get the throughput; ChaCha20 deployments stay at the small footprint.

Practical impact: an application that holds a thousand long-lived ChaCha20 contexts, such as a server with persistent client sessions, a relay, or MLS group state, saves ~310 KB of resident memory over hpke-rs. An AES-128-GCM deployment with the same shape pays ~390 KB of additional context state for the per-call seal-side speedup. Whether that’s a good trade is application-specific, and it’s now an explicit choice the type system makes visible.

The post-quantum and PK-cache tradeoff: hpke-ng private keys are larger across the board

Per-key footprint is where the speed/memory trade lands explicitly. Every KEM private key in hpke-ng now caches material that hpke-rs reconstructs from raw bytes on demand: the recipient’s serialized public key for the DH-KEMs (so decap doesn’t recompute it via base-point scalar multiplication), the expanded x_wing::DecapsulationKey for X-Wing (so decap doesn’t re-run SHAKE-256 + ML-KEM-768 keygen), and the materialized FIPS 203 decapsulation key for ML-KEM (same trick at the parameter-set boundary). The size impact is uniform and easy to reason about:

KEM private key footprint · stack + heap, in bytes

hpke-rshpke-ng

X25519

56 B

88 B

+32 B

P-256

56 B

121 B

+65 B

X-Wing

56 B

1,698 B

+1,642 B

ML-KEM-768

88 B

3,266 B

+3,178 B

ML-KEM-1024

88 B

4,290 B

+4,202 B

Every row spends extra memory at private-key construction in exchange for not paying the same work on every subsequent decap. That is the explicit memory cost of the −37% to −55% decap deltas.

So the trade is concrete: an extra 32–65 B per DH private key, ~1.7 KB extra per X-Wing private key, ~3.2 KB extra per ML-KEM-768 private key, and ~4.2 KB extra per ML-KEM-1024 private key. In exchange the recipient skips a base-point scalar mult per DH decap, a SHAKE-256 + ML-KEM-768 keygen per X-Wing decap, and a FIPS 203 KeyGen_internal per ML-KEM decap. For a server pinning a few thousand long-lived receiver keys this is good arithmetic in essentially every setting we can think of, a possibly-bad trade on a microcontroller pinning very few keys, and we’d rather you have the numbers than guess.

Public keys grow in the same direction on the post-quantum side, because hpke-ng now caches the parsed EncapsulationKey alongside the wire bytes so encap doesn’t re-decode the 1,184/1,568-byte payload on every call. X-Wing public keys are 1,656 B, ML-KEM-768 public keys are 1,624 B, ML-KEM-1024 public keys are 2,136 B (vs hpke-rs’s Vec<u8> of just the wire bytes). DH public keys are unchanged: 32 B for X25519, 96 B for P-256 (uncompressed encoded point form).

Smaller

Project surface area

hpke-rshpke-ng

End-user binary (stripped, release)

561 KB

392 KB

−30%

Total project code (cloc)

5,631

4,817

−14%

Library source (cloc)

2,623

2,426

−8%

Test code (cloc)

2,230

1,124

−50%

Bench code (cloc)

759

~1,700

+124%

Crates in workspace

−75%

User-facing Cargo features

−36%

Expanding on the above:

End-user binary, −30%. A minimal application (generate a key, seal a message, open it back, ten lines of Rust) compiled with RUSTFLAGS="-C target-cpu=native", lto="thin", codegen-units=1, strip="symbols". hpke-ng comes in at 392 KB; hpke-rs at 561 KB. 169 KB is not nothing on embedded targets, in WASM bundles, or in CDN-served binaries.

Library code, −8%. hpke-ng is 197 lines smaller than hpke-rs at the library level (2,426 vs 2,623), while implementing strictly more: the full HPKE surface plus the optional post-quantum suite (X-Wing draft-06, ML-KEM-768, ML-KEM-1024) that hpke-rs reaches only via experimental feature flags. The type-state design earns its keep here: ciphersuite selection lives entirely in the type system, so there is no provider trait, no per-primitive enum dispatch, and no glue between the two. Inline #[cfg(test)] modules are kept tight: anything covered by tests/roundtrip.rs’s 59-cell macro matrix is deleted from src/.

Test code, −50%. hpke-rs’s test suite is 167 tests in 2,230 lines; hpke-ng’s is 128 tests in 1,124 lines, with deeper coverage on roundtrips (59 macro-generated (mode, KEM, KDF, AEAD) combinations vs hpke-rs’s 17 hand-written cases). The reduction is structural. The type system carries information that would otherwise be repeated test setup, and the roundtrip! macro generates one test per supported configuration from a single declaration.

Bench code, +124%. This row runs against the section’s grain, and it’s deliberate. hpke-ng’s bench harness has more than doubled, all of it concentrated in a new comparative.rs that loads hpke-rs and rust-hpke as dev-dependencies and benchmarks every supported ciphersuite against both, including the post-quantum suite that hpke-rs ships only behind an experimental feature flag and that rust-hpke doesn’t ship at all. That single-source-of-truth harness is what made the 126-row tally at the top of this post possible. Coverage, not waste.

The one place this chart doesn’t reach is the fuzz harnesses. hpke-ng spends substantially more code on cargo-fuzz targets than hpke-rs does, deliberately so. That’s the next section.

Harder

cargo test · --features pq,kat-internals,differential

128 / 128 passing

128

tests passing

1.9s

total wall time

37×

faster than hpke-rs's KAT runner

4 / 1

cargo-fuzz targets (hpke-ng / hpke-rs)

unit (lib)46/46

RFC 9180 KAT13/13

roundtrip matrix59/59

differential vs hpke-rs8/8

doctests2/2

cargo-fuzz targets4 / 4 clean

The 1.9-second figure is the headline number. The full hpke-ng test matrix runs in about 1.9 seconds: 128 tests across library unit tests, RFC 9180 KAT, generative roundtrips over every ciphersuite × mode combination, and byte-by-byte differential vs hpke-rs. The roundtrip layer alone is 59 macro-generated tests covering every supported (mode, KEM, KDF, AEAD) combination including all four post-quantum and X-Wing/ML-KEM rows. hpke-rs’s KAT runner is structured as a single test that iterates 144 vectors sequentially and takes about 70 seconds. Same vectors, same coverage, structured to take advantage of cargo test’s thread pool.

For day-to-day development the headline number understates the impact. A 70-second feedback loop is one you avoid running until you’re “done”; a 1.9-second feedback loop is one you run after every save.

The fuzz layer is where hpke-ng makes its biggest investment in lines of code. hpke-rs ships one cargo-fuzz target, a seal/open harness for one ciphersuite. hpke-ng ships four:

pk_from_bytes — fuzzes public-key parsing for all 9 KEMs (X25519, X448, P-256, P-384, P-521, secp256k1, X-Wing, ML-KEM-768, ML-KEM-1024).
enc_from_bytes — fuzzes encapsulated-key parsing for all 9 KEMs.
key_schedule — fuzzes the internal key schedule with arbitrary mode bytes (including invalid 0x04..=0xFF mode values), arbitrary PSK / PSK-ID combinations, and arbitrary shared secrets.
open — fuzzes Hpke::open_base with arbitrary [encap || ciphertext] byte splits against a fixed receiver keypair.

The shared invariant across all four is that panics are bugs. Authentication failures, decode errors and length mismatches are all expected outcomes that the harness considers a successful run. A panic, a misaligned-pointer fault, or a debug-assertion failure under cargo-fuzz’s instrumentation is a finding. As of release, all four targets run clean.

There are also several structural footgun-prevention details that don’t show up in the fuzz output but are worth listing.

Context is not Clone. Cloning an HPKE context lets two callers reuse the same (key, base_nonce, seq) triple, which is a nonce-reuse bug that produces correct-looking output right up until an attacker XORs two ciphertexts together. hpke-ng’s Context deliberately doesn’t implement Clone; cloning is a compile error.

Context::seal refuses to encrypt at seq == u64::MAX. A pre-check, before nonce computation. This makes nonce-reuse via counter wraparound structurally impossible regardless of how the caller handles a MessageLimitReached error.

All-zero shared-secret rejection (RFC 9180 §7.1.4) uses subtle::ConstantTimeEq for X25519 and X448. An attacker who supplies a small-order point and watches for timing variance is one of the more subtle attacks on DHKEM; the constant-time comparison closes it.

AEAD nonce length is enforced at compile time. Context::compute_nonce uses a const assertion that the AEAD’s NONCE_LEN is between 8 and 12 bytes. Any AEAD that violates this is a compile error at the call site that uses it.

Interop

We tested interop two ways. The first is RFC 9180 known-answer tests: both libraries are run against the same vendored test vector JSON (8 MB, derived from RFC 9180’s own test vector tooling) and required to produce byte-equal key, base_nonce, exporter_secret, decrypted ciphertexts, and exported values for every vector. The second is byte-by-byte differential testing: a deterministic ChaCha20Rng feeds identical inputs to both libraries; hpke-ng plays sender, hpke-rs plays receiver, and every byte that crosses the wire is asserted equal. Roughly 600 byte-equality assertions per CI run, all passing.

CiphersuiteRFC 9180 KATDifferential vs hpke-rs

DHKEM(X25519, SHA-256) × ChaCha20-Poly1305✓ Base / Psk / Auth / AuthPsk✓ Base + Psk

DHKEM(X25519, SHA-256) × AES-128-GCM✓ Base / Psk✓ Base

DHKEM(X25519, SHA-256) × AES-256-GCM✓ Base / Psk✓ Base

DHKEM(X25519, SHA-256) × ExportOnly✓ Base / Psk— no AEAD

DHKEM(P-256, SHA-256) × ChaCha20-Poly1305✓ Base / Psk✓ via KAT

DHKEM(P-256, SHA-256) × AES-128-GCM✓ Base / Psk / Auth / AuthPsk✓ Base + Psk

DHKEM(P-521, SHA-512) × AES-256-GCM✓ Base / Psk / Auth / AuthPsk— hpke-rs/RustCrypto unsupported

DHKEM(secp256k1, SHA-256) × ChaCha20-Poly1305✓ Base / Psk✓ via KAT

DHKEM(X448, SHA-512) × ChaCha20-Poly1305✓ Base / Psk— hpke-rs/RustCrypto unsupported

ML-KEM-768 × ChaCha20-Poly1305— no RFC vectors— seed-derivation differs by design

X-Wing draft-06 × ChaCha20-Poly1305— no RFC vectors— seed-derivation differs by design

Some gaps worth covering, for full disclosure:

Auth and AuthPsk differential. hpke-rs’s seed() injects raw bytes for the base ephemeral; for Auth modes there is also a sender static keypair derived earlier, before any seed-injection happens. Aligning the two libraries’ state for byte-by-byte Auth-mode differential testing would require a deeper hpke-rs API hook than hpke-test-prng exposes. Auth/AuthPsk-mode interop is verified at the KAT layer instead. Both libraries pass the X25519+ChaCha20 Auth/AuthPsk vectors, the P-256+AES-128 vectors, and the P-521+AES-256 vectors.

Post-quantum differential. hpke-rs’s X-Wing and ML-KEM implementations use different SHAKE-256 seeding from hpke-ng’s RFC 9180 §7.1.3-compliant derive_key_pair construction, so the libraries produce different ephemeral keys from the same IKM bytes. The encap wire format itself is determined by the underlying KEM crate (which both use), so they should agree at the wire level. We haven’t tested it in this repository.

rust-hpke differential. Not currently wired up. rust-hpke’s PRNG is a generic CryptoRng + RngCore parameter and is straightforward to align with a deterministic ChaCha20Rng, so adding a third differential leg is on the to-do list. As of this release, interop with rust-hpke is verified only at the speed-bench layer (each library opens what hpke-ng sealed, ad hoc, in unit tests).

Migrate today

All three libraries pass the same RFC 9180 KATs against the same primitive crates. If your code uses HPKE through a small wrapper, which most production HPKE code does, switching is mechanical:

// hpke-rs
let mut hpke = Hpke::<HpkeRustCrypto>::new(
    Mode::Base,
    KemAlgorithm::DhKem25519,
    KdfAlgorithm::HkdfSha256,
    AeadAlgorithm::ChaCha20Poly1305,
);
let kp = hpke.generate_key_pair()?;
let (sk, pk) = kp.into_keys();
let (enc, ct) = hpke.seal(&pk, info, aad, pt, None, None, None)?;

// rust-hpke
let (sk, pk) = X25519HkdfSha256::gen_keypair(&mut rng);
let (enc, mut ctx) = hpke::setup_sender::<ChaCha20Poly1305, HkdfSha256, X25519HkdfSha256, _>(
    &OpModeS::Base, &pk, info, &mut rng,
)?;
let ct = ctx.seal(pt, aad)?;

// hpke-ng
type Suite = Hpke<DhKemX25519HkdfSha256, HkdfSha256, ChaCha20Poly1305>;
let mut os = OsRng;
let mut rng = os.unwrap_mut();
let (sk, pk) = DhKemX25519HkdfSha256::generate(&mut rng)?;
let (enc, ct) = Suite::seal_base(&mut rng, &pk, info, aad, pt)?;

The most common migration shape: define a type Suite = Hpke<…, …, …> alias once, change hpke.seal calls to Suite::seal_base (or seal_psk / seal_auth / seal_auth_psk per mode), thread an &mut rng through the call sites that need encap entropy, drop the Option placeholders. The rust-hpke → hpke-ng shape is even closer: keep the type-state ciphersuite alias, swap module paths, and replace the per-iteration setup_sender with the appropriate Suite::seal_* if you only ever encrypt one message per recipient.

Get it

[dependencies]
hpke-ng = "0.1.0-rc.3"

GitHub: github.com/symbolicsoft/hpke-ng
docs.rs: docs.rs/hpke-ng
License: Apache-2.0 OR MIT
MSRV: Rust 1.95 (edition 2024)

If you find a row in our benchmark suite that’s wrong, an interop gap we haven’t documented, or a footgun we missed, file an issue. We’d rather know.

Announcing the Post-Quantum Migration Playbook

Wed, 06 May 2026 00:00:00 +0000

We get the same questions in almost every engagement now. Which post-quantum primitive should we pick? When do we hybridize, and when do we stop? How do we migrate TLS without breaking production? Which library can we trust? What should we test for? The answers have stabilized enough that writing them down once feels more useful than reciting them in another kickoff call.

So we did. The Post-Quantum Migration Playbook is a 52-page guide for the engineer or architect who has been told their system needs to be “post-quantum ready” and is now trying to figure out what that actually means in practice. It is organized around decisions rather than theory. Each chapter is short, scoped to a single migration concern, and ends with our recommendation and the contingency it depends on. Skim the TL;DR boxes if you only have ten minutes; the Pitfall boxes for mistakes we watch teams stumble into; the From the audit floor boxes for the bug classes we have actually found in production code, anonymized but real.

The topics are what you would expect: choosing primitives, when hybrid constructions are worth their cost (KEMs yes, signatures usually no), TLS and PKI migration, secure messaging, which libraries are worth using, conformance testing with Crucible, rollout strategy, and a closing gallery of bug classes. None of it is new research. Most of it is the stuff our clients keep wishing someone had handed them at the start.

The Companion Scorecard

We also built a small site to go with it: pq-migration.symbolic.software. Twelve questions, three minutes, no signup, and you get a verdict across six dimensions of post-quantum readiness. There is also a one-host TLS scanner that checks what your endpoint actually negotiates, in case it doesn’t match what your team thinks.

If you read the playbook and want to talk about your specific system, get in touch. The whole reason this is a guide and not a checklist is that the right answers depend on context.

Download the playbook (PDF, 52 pages)
Try the scorecard

Verifpal 0.51.0: Sharper Semantics for Passwords, Assertions, and AEAD

Mon, 20 Apr 2026 00:00:00 +0000

Verifpal 0.51.0 is out. Where 0.50.0 was a deep architectural redesign of the analysis engine, 0.51.0 is a short, correctness-focused release: three semantic fixes, one UI fix, and a few new models, all driven by bug reports filed against the 0.50.0 series. None of the changes affect the Verifpal modeling language. Every existing model still parses, still runs, and produces results that are at worst the same and in several cases strictly more accurate.

Thanks to Cédric Picard (@cym13) for issues #11, #12, and #13, and to @EFCCWEB3 for issue #10. This release exists because of them.

Passwords: From Static Tables to Verifiable Guesses

The largest change in 0.51.0 is a rewrite of how Verifpal reasons about password-qualified values. Passwords occupy a strange place in the Verifpal model: they are secrets, but they are low-entropy secrets, so the attacker is assumed to be able to brute-force them if and only if the attacker has a way to verify guesses. Getting that “if and only if” right turns out to be subtle.

What Was Wrong

Before 0.51.0, password protection was defined by a static password_hashing field on each primitive’s spec, a list of argument positions at which passwords were considered cryptographically protected. For ENC, that list was vec![1]: the plaintext is protected, the key is not.

This captures the common case, where encrypting a password with a known key lets the attacker brute-force it, but it fails on compositions. Consider:

principal Alice[
    knows private key
    knows public  data
    knows password pwd_2

    msg2 = ENC(key, CONCAT(pwd_2, data))
]

In 0.50.0, a passive confidentiality query on pwd_2 would fail. The password sits inside CONCAT, which has no password_hashing list of its own, so the engine treated the password as “unprotected” and assumed the attacker could brute-force it, even though the attacker does not know key and therefore has no way to verify a guess. This was Cédric’s issue #11.

The same shape arose elsewhere: ENC(secret, pwd), MAC(secret, pwd), AEAD_ENC(pwd, secret, pubdata), BLIND(secret, pwd), SIGN(pwd, secret). Each one has a different “right answer” depending on whether the attacker actually has enough of the surrounding context to mount an offline dictionary attack. A flat static table cannot express that.

The New Model

0.51.0 replaces the table with a dynamic, position-sensitive check. A password-qualified value at position i of primitive P(a₀, …, aₙ) is obtainable by the attacker only when both of the following hold at every primitive level in the nesting chain:

No inherent protection. Position i is not listed in P.password_hashing. This field is now reserved exclusively for primitives that resist brute-force by construction (only PW_HASH qualifies, since it is expensive by design). Every other primitive loses its static entry.
Verifiable guess. The attacker knows every sibling argument aⱼ (j ≠ i), which is what it takes to reconstruct P(…, guess, …) and compare against the observed output. If any sibling is unknown, the guess cannot be verified and the password is safe.

Protection, check (1), propagates to descendants: once you are inside a PW_HASH argument, everything below is protected. Verifiability, check (2), propagates only as long as every ancestor has known siblings; the first ancestor with an unknown sibling blocks the check all the way down.

This gives much more accurate results across the matrix of primitives. For instance, in the canonical ENC(key, pwd) case where key is private, the attacker does not know key, the only sibling of pwd, so the password is safe. For ENC(pwd, pubdata) where pubdata is public, the attacker knows every sibling of pwd, so the password is guessable. Both outcomes fall out of the same rule, with no per-primitive configuration.

The new examples/test/password_underspec.vp file walks through eleven queries across ENC, MAC, AEAD_ENC, SIGN, BLIND, and SHAMIR_SPLIT, with an inline comment on each one explaining what the attacker can and cannot do and why. It is probably the fastest way to get intuition for the new semantics.

This fix addresses issue #11 in full and substantially refactors the machinery that issue #12 was asking to clarify. #12 remains open for further discussion of edge cases, but the core formalism is now in place.

Checked `ASSERT?` Now Actually Halts the Principal

Issue #13, also from Cédric, was a pleasing little bug. Consider a protocol where Alice checks a tag before leaking a derived value:

principal Alice[
    tag_ = DEC(Ka, enctag)
    Kab_ = DEC(Ka, Kab_alice)
    Kab_bob_ = DEC(Ka, Kab_bob_alice)

    _ = ASSERT(tag_, HASH(Kab_, Kab_bob_))?
    leaks Kab_bob_
]

The ? on the ASSERT makes it a checked assertion: if the two sides are not equivalent, the principal halts, and the leaks statement that follows does not execute. Any downstream reasoning about what the attacker can learn must respect that halt.

In 0.50.0, Verifpal reported a false-positive attack against this protocol. An active attacker could swap two ciphertexts on the wire, making the assertion symbolically fail. The trace literally read ASSERT(HASH(kab, ENC(kb, kab)), HASH(kab, kab))?, which is not equivalent under any substitution, and yet the engine still treated leaks Kab_bob_ as firing in that branch and harvested values from it. The attack trace was nonsensical: the assertion it relied on was clearly false, but Verifpal was claiming the attacker had won anyway.

The underlying issue was that leaks was represented as a single leaked: bool flag on the target constant, with no record of which principal had declared the leak or where in that principal’s execution it sat. Active-attacker analysis can truncate a principal’s state after a failed checked primitive, but a constant declared before the failed assertion is still in the truncated state, and the attacker was using the leaked-constant token to re-resolve that constant in the mutated state and pick up a value the principal never actually leaked.

0.51.0 fixes this by adding an explicit LeakEvent record for every leaks declaration:

pub struct LeakEvent {
    pub constant_id: ValueId,
    pub principal_id: PrincipalId,
    pub declared_at: i32,
    pub phase: i32,
}

Each PrincipalState now carries an Option<halted_at> stamp set whenever a checked primitive fails during mutation analysis. The rule_equivalize deduction rule, which lets the attacker re-resolve a known constant in the current state, consults both: if a leak event belongs to this principal with declared_at > halted_at, the principal never reached it, and the equivalize step is suppressed.

The examples/test/assert_junglegym.vp model is the reduced test case from Cédric’s report, now enforced as a regression test. Behavior with unchecked ASSERT (no ?) is deliberately unchanged: unchecked assertions are informative only, and the attacker is free to walk past them.

AEAD_ENC No Longer Leaks Associated Data

Up until 0.50.0, AEAD_ENC(key, plaintext, ad) was declared with passive_reveal: vec![2], meaning a passive attacker watching the ciphertext on the wire was automatically given the associated data. This was wrong in two ways.

First, the AD is an input to AEAD encryption, not a part of the ciphertext output. It is bound into the authentication tag, but the tag commits to AD without necessarily revealing it. Whether AD is public depends on how the protocol transmits it, not on the encryption primitive itself.

Second, the blanket passive reveal was blocking legitimate queries where the AD was a secret (for example, a password used as AD), because Verifpal was automatically handing that secret to the attacker.

0.51.0 removes the passive_reveal: vec![2] entry. Associated data is now treated like any other argument: if the protocol sends it in the clear, the attacker sees it; if not, the attacker does not. The aead_leak.vp test has been updated to reflect the corrected semantics, and a new password_aead.vp test demonstrates that a password used as AD is safe when the other inputs are secret.

TUI: Multi-Output Primitive Labels

Issue #10, from @EFCCWEB3, was a small but annoying display bug in the terminal UI. The compact deduction ticker strips a "Output of " prefix off each deduction message to show a short label like HASH via reconstruct. For the multi-output primitives (HKDF, SPLIT, SHAMIR_SPLIT), the underlying message uses indexed forms like "First output of HKDF(…)" or "Second output of SPLIT(…)". The literal-prefix match missed those, and the ticker fell back to the first whitespace-separated word, which was "First" or "Second".

The fix is one line: look for the shared " of " delimiter instead of the literal prefix. Multi-output primitives now show up correctly in the ticker.

New Models

Two models of note ship with the release:

examples/transport-layer/tls13.vp — a 326-line TLS 1.3 model, included explicitly as a case study in Verifpal’s current limitations on large multi-phase protocols with many key-schedule stages. It is useful both as a reference and as motivation for future engine work.
examples/messaging/scuttlebutt.vp — the existing Scuttlebutt model has been updated to guard longTermBPub (Bob -> Alice: [longTermBPub]), which exercises more interesting branches of the analysis than the unguarded form.

The password, assertion, and AEAD fixes each ship with at least one new dedicated test model in examples/test/.

Getting Verifpal 0.51.0

Scoop (Windows):

scoop update verifpal

Homebrew (macOS, Linux):

brew upgrade verifpal

From source:

cargo install --path . --features cli

Binaries for Windows, Linux, macOS, and FreeBSD are attached to the 0.51.0 GitHub release. As always, issues and contributions are welcome at github.com/symbolicsoft/verifpal.

Hybrid Constructions Are a Safety Blanket, and That's Fine

Mon, 13 Apr 2026 00:00:00 +0000

Soatok published a clear-eyed piece today on hybrid post-quantum constructions, meaning the practice of combining a classical algorithm (X25519, ECDSA) with a post-quantum one (ML-KEM, ML-DSA) so that the system remains secure even if one of the two is broken. The post argues that hybrid KEMs are a reasonable safety blanket while hybrid signatures have a weaker justification, and that the industry should stop letting the perfect be the enemy of the deployed. We broadly agree, and this post explains why.

The Asymmetry Between KEMs and Signatures

Soatok’s central observation is one that deserves wider uptake: the harvest-now-decrypt-later (HNDL) threat that motivates hybrid KEMs has no analogue for signatures.

When an adversary captures ciphertext today, they can store it indefinitely and decrypt it once a cryptographically relevant quantum computer (CRQC) arrives. The data that was confidential in 2026 is still confidential in 2036. A hybrid KEM like X-Wing, which combines ML-KEM-768 with X25519, hedges against this threat by ensuring that an attacker must break both the lattice problem and the elliptic curve discrete logarithm to recover the plaintext. If ML-KEM turns out to be flawed, X25519 is still there. If X25519 falls to a quantum adversary, ML-KEM is still there. The cost is modest: a slightly larger key exchange, a second KDF call, and some additional bandwidth. The insurance is real.

Signatures are different. A signature is verified at the time it is received. A quantum adversary who arrives in 2036 cannot retroactively forge a signature that was verified and acted upon in 2026. There is no stockpile of signatures waiting to be broken. The threat model that justifies hybrid KEMs, store now and exploit later, does not apply in the same way.

That said, hybrid signatures are not without merit. Long-lived signatures on software packages, certificates, or firmware could in principle be forged by a future quantum adversary, and there is a reasonable belt-and-suspenders argument for hedging against a lattice break even in the authentication context. The case is simply less urgent than for KEMs, where the consequences of a wrong bet are retroactive and irrecoverable.

We have been recommending post-quantum native design for all new systems since April 2, with hybrid constructions where backward compatibility requires them. That recommendation was deliberately agnostic about signatures versus KEMs. We are now refining it: hybrid KEMs are a compelling transitional measure; hybrid signatures are far less necessary, and should be evaluated against the specific threat model rather than adopted as a default.

Lattice Confidence Is Earned, Not Assumed

A recurring objection to pure post-quantum deployment is that lattice-based cryptography is “too new” to trust without a classical fallback. Soatok addresses this directly, and the numbers bear repeating: NTRU was patented in 1997. The learning-with-errors problem was introduced by Regev in 2005, the same year Curve25519 was published. ML-KEM and ML-DSA survived nearly a decade of the most intensive public cryptanalysis effort the field has ever organized, the NIST Post-Quantum Cryptography Standardization Process, in which hundreds of researchers from dozens of countries actively tried to break every candidate.

The process worked. SIKE, the supersingular isogeny-based scheme, was broken during the competition by a catastrophic attack that the evaluation process was designed to surface. The lattice candidates survived. This is not absence of scrutiny; it is scrutiny that produced a result.

We have additional evidence from our own work. When we built Crucible and tested 15 ML-KEM and ML-DSA implementations across five languages, we found two minor conformance gaps and zero security vulnerabilities. The implementations that ship inside AWS-LC, Cloudflare CIRCL, the Go standard library, and wolfSSL’s FIPS module all passed every test. The post-quantum ecosystem is not speculative anymore. It is production-grade software that has been tested, audited, and deployed at scale.

The Real Risk Is Complexity

Our audit practice keeps landing on the same lesson. The most common source of cryptographic failure is the complexity surrounding the primitive rather than the primitive itself: the state machine that manages keys, the serialization layer that encodes messages, the fallback logic that negotiates which algorithm to use.

Every hybrid construction doubles the number of moving parts in exactly these layers. A hybrid KEM requires two key generations, two encapsulations, two decapsulations, and a combiner that must be correctly implemented to preserve the security properties of both components. A hybrid signature requires two signing operations, two verification operations, and a composition that must not introduce verification oracle attacks. Each additional algorithm is additional attack surface, not because the algorithm itself is weak, but because the integration is where bugs live.

We have spent the past two months documenting what happens when cryptographic implementation complexity outpaces engineering discipline. The bugs we found were not in the cryptographic primitives. They were in the wrappers, the serialization, the specification-to-code translation, the build system defaults. Adding a second algorithm to every cryptographic operation in a system multiplies exactly these surfaces.

For KEMs, the HNDL threat clearly justifies this cost. The insurance against a catastrophic retroactive loss of confidentiality is worth the additional integration complexity. For signatures, the calculus is less clear-cut. Hybrid signatures carry the same complexity costs, but the threat they hedge against, a lattice break that enables forgery, is one where the damage is prospective rather than retroactive. That does not make hybrid signatures pointless; it makes them a less urgent priority than hybrid KEMs, and one where the complexity tradeoff deserves more scrutiny.

Migration Friction Kills

Soatok makes a pragmatic point that matches everything we see in practice: the biggest risk to the post-quantum transition is not that the algorithms are wrong. It is that the transition takes too long because the industry overcomplicates it.

Every additional requirement adds friction to migration: hybrid signatures on top of hybrid KEMs, dual certificate chains, negotiation for four algorithms instead of two. Friction means slower adoption. Slower adoption means more years of classical-only systems exposed to the HNDL threat that the entire transition is supposed to address. The irony is acute: treating hybrid signatures as a prerequisite for deployment may extend the window during which systems are vulnerable to exactly the quantum threat they are trying to mitigate.

Our recommendation stands: design new systems as post-quantum native. Use ML-KEM for key encapsulation. Use ML-DSA for digital signatures. Use hybrid KEMs (X-Wing or equivalent) where backward compatibility with classical systems is required during transition. Hybrid signatures may be appropriate for specific use cases, such as long-lived code signing, certificate authorities, and scenarios where signature validity must span decades. But they should not be the default, and they should not gate the broader migration.

Where That Leaves Us

Soatok’s post captures something the applied cryptography community has been circling around without stating plainly: hybrid constructions are a safety blanket, and for KEMs, that blanket is clearly worth the cost. For signatures, the case is weaker. The distinction turns on whether the urgency of the threat model justifies the additional complexity, not on how much anyone trusts lattices.

We have audited a lot of post-quantum implementations. We built the conformance testing framework that the ecosystem uses to validate them, and we documented what happens when verification complexity outpaces engineering reality. From that vantage point: the lattice primitives are sound, the implementations are maturing, and the greatest risk to the transition is making it harder than it needs to be.

Deploy post-quantum cryptography. Use hybrid KEMs where they make sense. Consider hybrid signatures where the use case warrants them, but do not treat them as a prerequisite. And above all, do not let the pursuit of a theoretically perfect transition delay the practically necessary one.

The full version of this argument, alongside the rest of our migration recommendations, lives in our Post-Quantum Migration Playbook, a free practitioner guide covering primitives, hybrid constructions, TLS migration, libraries, conformance testing, rollout strategy, and the bug classes we keep finding in audits. It is the companion to our live PQ Migration Readiness scorecard and scanner.

The Verification Facade: Structural Gaps in Cryspen's Hax Pipeline

Tue, 07 Apr 2026 00:00:00 +0000

On the Promises of 'High-Assurance' Cryptography 2026.02.05
We Found Bugs in CE Labs' Verified Code 2026.02.12
Even More Bugs in CE Labs' libcrux: ML-DSA 2026.02.17
CE Labs' Approach to TLS: A Critical Analysis 2026.03.07
The Verification Facade: Structural Gaps in Cryspen's Hax Pipeline 2026.04.07

Over the past two months, we have documented sixteen vulnerabilities across six CE Labs projects: bugs in unverified wrappers, wrong formal specifications, false proofs, and unsound axioms. Those findings concerned the product. We now turn to the toolchain.

Today, we’re publishing our latest paper, Verification Facade: Masquerading Insecure Cryptographic Implementations as Verified Code, which examines Hax, Cryspen’s verification pipeline and the toolchain that underlies CE Labs’ “formally verified” claims.

Hax translates a subset of Rust into F*, enabling machine-checked proofs of panic freedom and functional correctness. ML-KEM and ML-DSA implementations verified via hax are being developed in partnership with Google and tested in Signal’s PQXDH protocol. If hax’s translation is faithful, the F* proofs transfer to the Rust code. If it is not, the proofs verify a model that diverges from what actually executes.

We find that it is not, in three distinct ways. We identify three classes of semantic gap in hax’s pipeline and demonstrate each through proof-of-concept exploits against ML-DSA, ML-KEM, Ed25519, and ChaCha20. Every exploit must pass all four of our inclusion gates:

Correct Rust: the code compiles as valid Rust.
Successful extraction: hax extracts it to F* without errors or warnings.
Security-relevant model divergence: the verified F* model diverges from the deployed Rust code in a way that compromises a cryptographic security property.
Invisible to testing: the divergence escapes detection by functional tests (sign-then-verify, encrypt-then-decrypt, test vectors all pass).

All source code and pre-extracted F* output are available on GitHub.

We call the resulting phenomenon a verification facade: verification that is performed but covers less than it appears to cover. In verification theatre, verification is claimed but not performed. In a facade it is performed, but the model either diverges from the deployed code, depends on unenforceable assumptions, or cannot express a security-critical property.

How Hax Works

Hax translates Rust to F* through three stages. A frontend hooks into rustc and extracts the Typed High-Level Intermediate Representation (THIR), a representation where references are still present, borrow-checker constraints are implicit, and Drop glue has not been elaborated. A transformation engine then applies 35 sequential phases, each eliminating a language feature: by the time the AST reaches the backend, mutable variables, references, raw pointers, lifetimes, all loop forms, and the ? operator have been eliminated, leaving a purely functional representation. Finally, the F* backend translates this to F* surface syntax. Integer types become refinement-typed wrappers (e.g., u8 becomes int_t U8 with range $[0,255]$). Rust’s + becomes +! (strict, with overflow proof obligation); wrapping_add becomes +. (modular).

The pipeline’s feature-witness system ensures structural correctness (the output has the right shape) but not semantic preservation (the output has the same meaning). For hax’s verification claims to hold, three unverified components must be correct: the 35 OCaml transformation phases, the F* proof libraries (which axiomatize 113 operations via assume val, roughly 19% of the integer model), and user annotations (#[opaque], assume!, fstar::replace, verification_status(lax)).

For code that fits its extraction model, meaning deterministic for loops over bounded ranges, pure arithmetic with explicit bounds, and array transformations with statically known indices, hax provides genuine verification. Every +! and *! generates a real overflow proof obligation. Bounded for loops extract to a defined (not axiomatized) fold_range combinator with real loop invariants. And ensures clauses are proof obligations, not axioms: if the function body violates the postcondition, F* rejects the code. We confirmed this experimentally.

The gaps arise elsewhere.

The Gaps and Their Exploits

We identify three classes of semantic gap and demonstrate each with proof-of-concept exploits. We distinguish three gradations: facade gaps (E1, E3, E4), where the F* model actively diverges from Rust; a conditional gap (E2), where the divergence depends on the compilation mode; and a scope gap (E5), where the model is faithful but cannot cover a critical property.

E1: ML-DSA Rejection Sampling (Facade Gap)

The gap: while-loop ghosting. When a while loop lacks a loop_decreases! annotation, hax generates a fuel function returning constant 0. The F* while_loop combinator requires fuel to strictly decrease on each iteration (fuel(next) < fuel(current)). With constant fuel 0, that obligation becomes $0 < 0$, which is $\mathsf{False}$. The loop body is proof-inert: it exists syntactically but cannot support any verification claim.

The exploit. ML-DSA signing (FIPS 204) uses rejection sampling: the signer computes $\mathbf{z} = \mathbf{y} + c\mathbf{s}_1$ and retries until $\|\mathbf{z}\|_\infty < \gamma_1 - \beta$. This loop is what makes ML-DSA signatures zero-knowledge. Our implementation is straightforward:

pub fn sign_message(s1: &SecretS1, seed: u64) -> SignatureZ {
    let mut nonce: u32 = 0;
    let mut z = generate_mask(seed, nonce);
    z = compute_z(&z, s1);
    while !check_norm_bound(&z) { // rejection sampling
        nonce = nonce.wrapping_add(1);
        z = generate_mask(seed, nonce);
        z = compute_z(&z, s1);
    }
    z
}

The code compiles, the rejection loop runs correctly, and sign-then-verify tests pass. But the extracted F* tells a different story:

let sign_message (s1: t_SecretS1) (seed: u64) =
 let z = compute_z (generate_mask seed 0) s1 in
 let (nonce, z) =
  Rust_primitives.Hax.while_loop
   (fun _ -> true)                        (* invariant *)
   (fun (_, z) -> ~.(check_norm_bound z)) (* condition *)
   (fun _ -> Int.from_machine (mk_u32 0)) (* fuel = 0 *)
   (0, z)                                 (* accumulator *)
   (fun (nonce, z) ->                     (* body *)
    let nonce = wrapping_add nonce 1 in
    let z = compute_z (generate_mask seed nonce) s1
    in (nonce, z))
 in z

Line 7 is the problem. The fuel function returns constant 0, so the body’s refinement type requires $0 < 0$—impossible. Z3 cannot use the body to prove anything about how the accumulator changes. The Rust code correctly rejects candidates, but F* has no way to verify this.

ML-DSA’s security relies on the Fiat-Shamir with Aborts paradigm: rejection sampling ensures that $\mathbf{z}$’s distribution is statistically independent of $\mathbf{s}_1$. Without this property, lattice techniques can recover the secret key from approximately 1000 signatures. The verification is supposed to cover exactly this, and it cannot.

A stronger variant. Because the while loop is proof-inert, F* cannot distinguish a correct rejection loop from a broken one. An adversarial developer could invert the loop condition, writing while check_norm_bound(&z) instead of while !check_norm_bound(&z), causing the function to return the first candidate that fails the norm bound, directly leaking $\mathbf{s}_1$. The extracted F* would be structurally identical: the same while_loop call with the same fuel=0, and the same inability to prove anything about the output. A conforming verifier would eventually reject some of the resulting signatures (since FIPS 204 Algorithm 8 checks the same bound), so functional testing would catch it, but F* provides no earlier warning. The verification facade is the same whether the underlying code is correct or broken.

E2: ML-KEM Barrett Overflow (Conditional Gap)

The gap: deployment model divergence. Hax translates Rust’s + to F*’s +! (strict, panics on overflow), matching debug-mode semantics. In release mode, overflow wraps silently instead.

The exploit. Our proof-of-concept implements ML-KEM Barrett reduction with correct preconditions. The code compiles, passes debug-mode tests, and extracts to F* where arithmetic becomes strict. The F* proof establishes: “if the precondition holds, the result is correct; if not, the program panics.” But release mode introduces a third possibility that the F* model does not represent: precondition violated, no panic, silently wrong result. Incorrect Barrett reductions corrupt NTT polynomial arithmetic, breaking ML-KEM’s IND-CCA security.

This is a conditional gap: a correct implementation that always reduces after each multiplication stays within bounds. The divergence requires a caller that skips intermediate reduction, and such callers exist in the wild.

E3: Ed25519 Clamping (Facade Gap)

The gap: assumption laundering. assume!(P) compiles to () in Rust but introduces $P$ as an axiom in F*. A false assumption introduces $\mathsf{False}$ into the proof context, making every subsequent proof trivially satisfiable via ex falso quodlibet.

The exploit. Ed25519 clamps the secret scalar: clear bits 0–2, clear bit 255, set bit 254. Our proof-of-concept introduces a subtle bug: | (OR) instead of & (AND), setting bit 255 instead of clearing it. An assume! call immediately after asserts the bit is clear:

pub fn clamp_scalar(secret: &Scalar) -> Scalar {
    let mut s = *secret;
    s[0] = s[0] & 0xF0;
    hax_lib::assume!((s[0] & 0x07) == 0);
    // BUG: | 0x80 SETS bit 255 (should be & 0x7F)
    s[31] = s[31] | 0x80;
    // assume! LIES: claims bit 255 is clear
    hax_lib::assume!((s[31] & 0x80) == 0);
    s[31] = s[31] | 0x40;
    hax_lib::assume!((s[31] & 0x40) != 0);
    s
}

In the extracted F*, line 2 computes s[31] | 0x80 (sets bit 255), while line 4 assumes (s[31] & 0x80) = 0 (bit 255 is clear). The contradiction introduces $\mathsf{False}$, and from that point forward every postcondition in the function “verifies” vacuously. The developer sees green checks; the verification is meaningless.

The Rust code still produces valid Ed25519 signatures, because the curve math works for any scalar, so sign-then-verify tests pass. Only tests that check the clamped scalar directly would catch this. With bit 255 set, the scalar may exceed the group order $L$, and the effective signing key becomes $s \bmod L$, a different key than intended, enabling key-substitution attacks.

E4: ML-KEM SampleNTT (Facade Gap)

The gap: while-loop ghosting, compounded. This exploit combines the fuel=0 bug from E1 with a second problem: early return inside the loop body forces hax to use while_loop_return, an assume val combinator with no implementation at all:

assume val while_loop_return #acc_t #ret_t
  (inv: acc_t -> Type0)
  (condition: (c:acc_t {inv c}) -> bool)
  (fuel: (a:acc_t -> nat))
  (init: acc_t)
  (f: (acc_t -> ControlFlow ... acc_t))
  : ControlFlow ret_t acc_t

The exploit. ML-KEM’s SampleNTT is a rejection sampling loop that accepts coefficients only if they are less than $q = 3329$. Our implementation includes an early return None when randomness is exhausted. The extracted F* is doubly proof-inert: the combinator is an axiom Z3 cannot reason about, and the fuel is constant 0.

The property “all sampled coefficients are less than $q$” is essential, because coefficients $\geq q$ break the ring structure on which ML-KEM’s security rests. F* cannot verify this property. Even a correct loop_decreases! annotation would not help, because while_loop_return has no body for Z3 to unfold.

E5: ChaCha20 Rotations (Scope Gap)

The gap: proof library axioms. The proof library axiomatizes operations that could be defined—including bit rotations—via assume val with no postconditions. F* knows only the return type, not what the function computes.

The exploit. ChaCha20 quarter rounds use left rotation by 16, 12, 8, and 7 bits. Our implementation is correct, and it passes standard test vectors. The extracted F* shows the rotation amounts explicitly:

impl_u32__rotate_left (state.[ d ]) (mk_u32 16)
impl_u32__rotate_left (state.[ b ]) (mk_u32 12)
impl_u32__rotate_left (state.[ d ]) (mk_u32 8)
impl_u32__rotate_left (state.[ b ]) (mk_u32 7)

But rotate_left is declared as assume val impl_u32__rotate_left': x: u32 -> n: u32 -> u32—no postcondition. Z3 cannot distinguish rotate_left x 16 from rotate_left x 15. An implementation with amounts 15, 11, 7, 6, each off by one and producing a weak cipher, would “verify” identically.

This is a scope gap, not a facade gap: the model is faithful, but the verification cannot cover the core cryptographic property. E1 and E4 show models that are wrong; E5 shows a model that is right but incomplete. The axiomatization affects every primitive that uses rotations: SHA-256, ChaCha20, AES. HACL*’s Lib.IntTypes demonstrates that defining rotations via shift-and-or is tractable. The current library chose axiomatization for simplicity.

Classification and Verification Results

Gap	Class	Type	Exploits
While-loop fuel=0	I-A	Bug	E1, E4
Reference erasure	I-B	Fundamental	—
Debug/release divergence	I-C	Engineering	E2
Opaque function trust	II-A	Feature	—
Proof library axioms	II-B	Engineering	E5
Unmodeled Drop/RAII	II-C	Fundamental	—
`assume!`	III-A	Feature	E3

We ran the F* typechecker (v2025.03.25) on all five extracted files. In full verification mode, three pass completely: E2, E3, and E5 all report “All verification conditions discharged successfully.” These are the strongest findings: F* fully verifies the code, yet the security gaps are real and undetected. E1 and E4 fail full verification due to an F* solver limitation with inner let rec definitions, a failure unrelated to our exploits. In practice, projects using hax handle while-loop modules via ADMIT_MODULES, accepting them without full verification.

The while-loop fuel=0 default is a one-line fix; we notified the hax maintainers prior to publication. The proof library axioms could be replaced with definitions. Reference erasure and unmodeled Drop are fundamental, and fixing them would require extraction at the MIR level, as Aeneas does. Beyond these, the backend should offer a release-mode arithmetic option (+. instead of +!), and assume! should check consistency against the proof context via a Z3 query before injecting axioms.

The Full Picture

Our previous work documented code outside the verified perimeter: wrong specifications, false proofs, admitted modules. The verification facade concerns the perimeter itself. Even for code that is extracted and whose proofs are dispatched to Z3, the verified model can diverge from the deployed code: while loops are silently proof-inert, release-mode arithmetic differs from the model, assume! can poison the proof context, and axiomatized operations have no semantic content for Z3 to reason about.

These gaps have direct FIPS implications. ML-KEM and ML-DSA implementations verified via hax are deployed where FIPS compliance is relevant. Rejection sampling in both algorithms uses while loops. Production modules compile in release mode. The verification provides less assurance than it appears to.

Together with our earlier findings, the full picture is now this. The specifications are wrong. The proofs are false or never checked. The build system defaults to admitting everything. The unverified wrappers contain implementation defects. The TLS implementations reject valid signatures and accept certificates from anyone. And now: even when verification is performed, the model that F* verifies can diverge from the program that Rust executes.

Hax is an active research project that contributes real work to high-assurance cryptography. For pure, bounded-loop functions with precise specifications, it verifies what it claims to verify. Our critique targets structural limitations of the extraction approach, not the project’s intent. But the translation pipeline is part of the trusted computing base, and verification claims for extracted code require the same qualification and defense-in-depth practices that the formal methods community has long advocated, and that CE Labs has consistently failed to provide.

On the Promises of 'High-Assurance' Cryptography 2026.02.05
We Found Bugs in CE Labs' Verified Code 2026.02.12
Even More Bugs in CE Labs' libcrux: ML-DSA 2026.02.17
CE Labs' Approach to TLS: A Critical Analysis 2026.03.07
The Verification Facade: Structural Gaps in Cryspen's Hax Pipeline 2026.04.07

Recommending Post-Quantum Native Design Under Epistemic Duress

Thu, 02 Apr 2026 00:00:00 +0000

Effective immediately, Symbolic Software is recommending that all clients design new cryptographic systems as post-quantum native. This post explains the reasoning behind that recommendation, subjects the evidence to the scrutiny it deserves, and raises questions about the epistemic standards the applied cryptography community should be holding itself to as the post-quantum transition accelerates.

The recommendation is, on balance, probably correct. But “probably correct” is not the standard this profession is supposed to work to. The gap between the two deserves honest examination.

The Google Quantum AI Result

On March 30, 2026, a team led by Google Quantum AI, with co-authors from UC Berkeley, the Ethereum Foundation, and Stanford, published a whitepaper presenting updated quantum resource estimates for solving the elliptic curve discrete logarithm problem on the secp256k1 curve (ECDLP-256), the curve underpinning the vast majority of cryptocurrency wallet signatures and a significant share of TLS deployments. The headline claim is a nearly 20-fold reduction in physical qubit requirements compared to Litinski’s 2023 estimates, which were themselves already a substantial improvement over earlier work.

Two compiled circuits are presented, representing different points on the space-time tradeoff curve:

Circuit A (low-qubit variant): $\leq 1{,}200$ logical qubits and $\leq 90$ million Toffoli gates.
Circuit B (low-gate variant): $\leq 1{,}450$ logical qubits and $\leq 70$ million Toffoli gates.

Under assumptions about superconducting qubit hardware (physical error rates at or below $10^{-3}$, planar degree-4 connectivity), these circuits are projected to execute on fewer than 500,000 physical qubits in a matter of minutes. The resource cost curve for ECDLP-256 is now tracking the same downward trajectory that RSA-2048 followed over the preceding decade.

The result is significant regardless of one’s position on post-quantum timelines. It narrows the gap between theoretical quantum advantage and engineering feasibility in a way that demands serious attention.

A Novel Disclosure Model

The paper introduces something new to the quantum cryptanalysis literature. Rather than publishing the full circuit constructions, the authors provide a zero-knowledge proof, specifically a Groth16 SNARK executed within the SP1 zkVM, attesting that they possess a quantum kickmix circuit of the claimed size that correctly computes secp256k1 elliptic curve point addition on 9,024 Fiat-Shamir-sampled pseudo-random inputs. (A kickmix circuit, as defined in the paper, is composed of classical reversible logic gates, measurement-based uncomputation, and diagonal phasing gates for phase correction: efficiently simulable classically, but structured for direct quantum execution.)

The stated rationale is responsible disclosure. Publishing optimized quantum circuits for breaking deployed elliptic curve cryptography would hand a blueprint to any future adversary with access to a sufficiently large quantum computer. The ZK approach attempts to let the community verify the plausibility of the resource estimate without providing the means to execute the attack.

This is an intellectually interesting approach and, in principle, a reasonable application of zero-knowledge techniques to a disclosure problem that has no good precedent. The authors deserve credit for thinking carefully about the responsible communication of quantum cryptanalytic capability, particularly in a domain like cryptocurrency, where public confidence is itself a security-relevant property.

What the Proof Covers, and What It Doesn’t

The ZK proof must be evaluated precisely for what it attests to and what it leaves open.

What is proven: The authors possess a quantum kickmix circuit that correctly computes secp256k1 point addition, and that circuit fits within the claimed resource counts. This is verified against 9,024 pseudo-random inputs derived via the Fiat-Shamir heuristic (SHAKE256 seeded with the circuit’s own bytes). The paper provides an explicit soundness bound: if the circuit produced incorrect outputs on more than 1% of inputs, the probability of passing all 9,024 tests is at most $(1-0.01)^{9024} \approx 2^{-130}$, yielding 128 bits of cryptographic security for the claim that the circuit is approximately correct on at least 99% of inputs.

What is not proven:

The full Shor compilation is not attested. The ZK proof covers the elliptic curve point addition subroutine, which the authors identify as the computational bottleneck. The reduction from point-addition cost to full end-to-end Shor execution cost relies on published windowed arithmetic techniques (double-and-add chains, interleaved modular multiplication). These techniques are well-established in the literature and the reduction is reasonable, but it remains an inferential step. The proof does not verify the complete quantum circuit that would actually break a key. An error anywhere else in the compilation, in the modular inversion or the quantum Fourier transform or the classical pre- and post-processing, would not be caught by this proof.

The soundness guarantee covers approximate correctness, not exact correctness. The paper’s soundness analysis establishes that the circuit is correct on at least 99% of inputs with $2^{-130}$ failure probability, which is a strong bound. But Shor’s algorithm is tolerant of this: a superposition with 1% incorrect values causes the algorithm to fail at most 1% of the time. What is less explicitly analyzed is the end-to-end relationship between “the point addition subroutine is 99%-correct on random inputs” and “the full Shor circuit, composed of 28 windowed point additions interleaved with modular arithmetic and a quantum Fourier transform, produces correct discrete logarithms.” The subroutine correctness bound is rigorous; the compositional argument connecting it to the top-level ECDLP claim rests on standard but unstated assumptions about how errors in the subroutine propagate through the larger algorithm.

The physical qubit projection rests on hardware assumptions that do not yet hold. The 500,000 physical qubit figure assumes error rates at or below $10^{-3}$ sustained across planar degree-4 connectivity at scale. Current superconducting qubit hardware has demonstrated error rates in this range on small systems, but maintaining these rates at the 500,000-qubit scale involves engineering challenges (crosstalk, wiring density, cooling) that have not been demonstrated. The projection is plausible given current trajectories, but it is a projection, not a measurement.

The circuits themselves are not available for independent analysis. This is by design, since the entire point of the ZK approach is to withhold the circuits. But it means the community cannot independently verify the circuit architecture, check for optimization opportunities that might further reduce costs, or identify errors in the compilation strategy. The claim is auditable only to the extent that the ZK proof permits.

None of these observations make the paper wrong. Taken together, they make the paper a strong signal that is not yet conclusive evidence. This distinction matters.

The Risk Calculus Behind the Recommendation

Given the above, why is Symbolic Software recommending post-quantum native design?

The answer is the asymmetry of consequences.

Consider the two error modes. If the recommendation is premature, and the quantum timeline turns out to be significantly longer than the resource estimates suggest, the cost to clients is engineering overhead: larger key sizes, larger signatures, increased bandwidth, more complex protocol negotiations, and the implementation risks inherent in deploying newer cryptographic primitives. These costs are real and non-trivial, but they are recoverable. A system designed with ML-KEM and ML-DSA that turns out not to have needed them for another fifteen years is a system that over-invested in security. There are worse failure modes.

If the recommendation is late, and the estimates are roughly correct so that classical elliptic curve cryptography becomes vulnerable within the operational lifetime of systems being designed today, the consequences are categorically different. Private keys are extractable. Signatures are forgeable. Store-now-decrypt-later attacks, in which encrypted traffic captured today is decrypted by a future quantum adversary, become retroactively devastating. These consequences are not recoverable. Data that has been exfiltrated cannot be un-exfiltrated.

This asymmetry is not new. It has been the standard argument for post-quantum preparedness for years. What the Google result changes is the urgency of the timeline, not the structure of the argument. The resource estimates have now improved to the point where “within the operational lifetime of systems being designed today” is no longer a worst-case assumption but a median-case projection.

The Harder Question: Epistemic Standards Under Pressure

The risk calculus is straightforward. The harder question is about the epistemic standards the community is applying as it navigates the post-quantum transition.

Applied cryptography has historically operated under a norm of open, reproducible, and fully auditable evidence. Protocols are published. Proofs are checked. Implementations are reviewed. When a vulnerability is claimed, the expectation is that the claim can be independently verified, not as a matter of trust but as a matter of scientific practice. This norm exists for good reason: the history of the field is littered with examples of informal reasoning, indirect signals, and trusted-but-wrong claims leading to catastrophic outcomes. Snake oil gets sold on the basis of plausible-sounding arguments. Bad standards get adopted because the evidence supporting them was not subjected to sufficient scrutiny.

The Google team’s ZK disclosure model represents a deliberate departure from this norm. The departure is well-motivated, and there is a legitimate argument that publishing optimized quantum attack circuits would cause more harm than benefit. But it creates a new epistemic regime in which the community is asked to make critical infrastructure decisions based on claims that are, by design, not fully auditable.

Several aspects of this regime deserve scrutiny:

The precedent effect. If “trust the ZK proof, don’t ask to see the circuits” becomes the accepted standard for quantum cryptanalysis disclosure, the community will be building security policy on a foundation where the underlying evidence is structurally unverifiable beyond what the prover chooses to reveal. This is an uncomfortable position regardless of the credibility of the prover, and Google Quantum AI is a very credible prover. The question is not whether this team can be trusted, but whether this disclosure model should become normative. Norms are not evaluated against the best-case actor; they are evaluated against the full range of actors who will invoke them.

The gap between verified and verifiable. A ZK proof provides cryptographic assurance that a specific computation was performed correctly. It does not provide the community with the ability to understand what was computed, to identify potential improvements, or to catch errors in the broader reasoning that connects the proven subroutine to the top-level claim. In traditional disclosure, a published circuit can be independently optimized, refuted, or extended. Under ZK disclosure, the community’s role is reduced from auditor to verifier of a predefined claim. These are different epistemic positions, and the latter is weaker.

The relationship between conservatism and rigor. The natural response to all of the above is: “Just be conservative. Assume the attack works and design against it. That’s Kerckhoffs’ principle applied to threat modeling.” This response is correct as far as it goes, and it is the basis of the recommendation being made here. But there is a meaningful difference between conservatism as a design principle, where uncertainty is resolved in favor of caution, and conservatism as an epistemic shortcut, where uncertainty is invoked to avoid the hard work of evaluating evidence rigorously. The former strengthens the field. The latter, if left unchecked, erodes the standards that make the field’s work meaningful.

The applied cryptography community has spent decades building a culture in which claims are expected to be substantiated, assumptions are expected to be explicit, and “it seems plausible” is not considered sufficient grounds for action. The post-quantum transition is now testing whether that culture holds under the pressure of urgency.

What Should Happen Next

Several concrete steps would strengthen the evidentiary basis for post-quantum migration decisions:

Independent reproduction of the resource estimates. The Google result is currently a single data point. A well-attested single data point, but a single data point nonetheless. Independent teams should attempt to reproduce or improve on the ECDLP-256 resource estimates using the publicly available literature on quantum arithmetic and Shor compilation. This is not an expression of doubt in the Google result. It is standard scientific practice. A global cryptographic migration should not be calibrated against a claim that only one team can verify.

End-to-end soundness analysis of the ZK disclosure model. The paper provides a clear soundness bound for the subroutine ($2^{-130}$ failure probability for 99%-correctness). What remains implicit is the compositional argument: how subroutine-level approximate correctness propagates through the full Shor circuit (28 windowed point additions, modular arithmetic, QFT) to yield a correct discrete logarithm. The authors also note a striking irony: the Groth16 SNARK itself relies on pairing-friendly elliptic curves vulnerable to the very quantum attacks the paper analyzes, which bounds the proof’s validity to the pre-CRQC era. A formal end-to-end analysis connecting the ZK-attested subroutine properties to the top-level ECDLP claim would strengthen the disclosure model considerably.

Continued hardware benchmarking against the projected requirements. The 500,000 physical qubit projection is credible given current trajectories, but it depends on engineering parameters that should be tracked publicly. As superconducting qubit systems scale, the community should maintain a clear, openly accessible mapping between demonstrated hardware capabilities and the requirements of the published quantum circuits. This mapping would provide a more rigorous basis for timeline estimates than trend extrapolation alone.

An honest conversation about epistemic norms under uncertainty. The applied cryptography community needs to explicitly discuss how it will handle situations where the evidence for a threat is strong but not fully transparent. The current post-quantum transition is the first instance of this problem at scale, but it will not be the last. The field would be served well beyond the current transition by settling now on what constitutes sufficient evidence for different classes of decisions, what obligations fall on provers who withhold details, and what role independent verification should play.

The Recommendation

Symbolic Software is advising all clients to design new cryptographic systems as post-quantum native. This means ML-KEM for key encapsulation, ML-DSA for digital signatures, and hybrid constructions where backward compatibility with classical systems is required during transition. The recommendation applies to systems currently in the design phase; guidance on migrating existing systems is available on a per-engagement basis.

This recommendation is made with full awareness that the evidence base, while strong, is not conclusive in the way the profession traditionally demands. The risk asymmetry justifies action. The evidentiary gaps justify continued scrutiny. Both of these things can be true simultaneously.

The post-quantum transition should be pursued with urgency. It should not be pursued with credulity. The applied cryptography community’s greatest asset is its insistence on rigor, and that insistence should not be the first casualty of the transition it is meant to protect.

For the operational follow-through on this recommendation, covering primitive selection, hybrid construction, TLS migration mechanics, the state of the libraries, conformance testing, rollout strategy, and the bug classes we keep finding in audits, see our free Post-Quantum Migration Playbook, companion to the live PQ Migration Readiness scorecard and scanner.

Applied Cryptography: Free Online Course for 50 Lebanese University Students This Summer

Mon, 23 Mar 2026 00:00:00 +0000

The Applied Cryptography course that I taught last year at the American University of Beirut is coming back this summer as a free online program, open to 50 students at Lebanese universities nationwide.

This is a full-featured course with strong instructor-student engagement. The same lectures, the same problem sets, the same projects, the same rigor, delivered online over the summer to a small, selectively admitted cohort. If you are a university student in Lebanon and you want to learn modern cryptography properly, this is your application: apply here. The deadline is May 10, 2026. The course starts June 9, 2026.

What the Course Covers

Applied Cryptography is a two-part course. The first part builds the theoretical foundations: provable security, pseudorandomness, chosen-plaintext and chosen-ciphertext attacks, collision-resistant hash functions, the discrete logarithm problem, Diffie-Hellman, elliptic curves, and digital signatures. The second part applies those foundations to real-world systems: TLS, the story of RC4, secure messaging (Signal, OTR, MLS), end-to-end encrypted cloud storage, high-assurance implementations, post-quantum cryptography, cryptocurrency cryptography, zero-knowledge proofs, secure multiparty computation, and fully homomorphic encryption.

The course has 18 topics, 8 problem sets, and 8 hands-on projects (students choose one or two). Projects range from building a password manager to designing a secure messenger, formally verifying a TLS-like protocol in ProVerif, implementing a zero-knowledge battleship game, and migrating a system to post-quantum cryptography. The programming languages are Go and Rust.

The required textbooks are Mike Rosulek’s The Joy of Cryptography and Jean-Philippe Aumasson’s Serious Cryptography, 2nd Edition. There is also an extensive reading list of around 90 research papers and technical resources, all linked from the course website.

How It Works

The program runs entirely online:

Lectures are delivered live, then published on YouTube so you can watch them on your own schedule.
Discussion, Q&A, and community happen on a dedicated Discord server.
Problem sets and projects are submitted and graded through Google Classroom.

All course materials (slides, readings, problem sets, project specifications) are already publicly available on the course website under a Creative Commons license. The online program adds structured pacing, graded assignments, direct access to the instructor, and a cohort of peers to work with.

Who Should Apply

You must be currently enrolled at a qualifying Lebanese university. Undergraduate or graduate. We will select 50 students based on:

Motivation. Why do you want to learn cryptography? What do you intend to do with it?
Background. Familiarity with at least one programming language and basic mathematical maturity (discrete math, probability, or any proof-based coursework).
Diversity. We want representation from across Lebanese universities and academic backgrounds, not just the usual suspects.

No prior cryptography experience is required. The course starts from first principles. If you have never seen a security reduction before, that is fine. You will by the end.

Certificate and Recommendation Letters

Students who complete the course will receive a signed certificate of completion. High-achieving students may be eligible for personalized letters of recommendation for graduate school applications.

Why We’re Doing This

Lebanon has a remarkable density of talented computer science students who, for various well-known reasons, do not always have access to specialized coursework in areas like cryptography. This is not a commentary on any university’s curriculum. It is an observation that the gap between what is taught in a standard undergraduate CS program and what is needed to do serious work in cryptography, in research or industry or open source, is large, and that closing it should not depend on which university you happened to enroll in or whether you can afford a semester abroad.

This course exists because I believe applied cryptography education should be accessible to any motivated student in Lebanon who wants it. The course materials are already open. The lectures will be open. The only scarce resource is structured mentorship and graded feedback, and we are making that available to 50 students this summer at no cost.

Looking for TAs

My students from last semester: in case you’re reading this, get in touch. There’s no way I’m grading fifty students on my lonesome again! I need your help!

Apply

The application is short. Tell us who you are, where you study, why you want to take this course, and what background you bring. That’s it.

Apply now!

Crucible: Forging Post-Quantum Implementations in the Fire of Real Audit Findings

Mon, 23 Mar 2026 00:00:00 +0000

NIST’s Known Answer Tests verify final outputs. Formal verification tools verify abstract models. Neither catches the bugs that live in between: the off-by-one rounding, the bounds check compiled to dead code, the inverse NTT omitted from the decryption path.

We know these bugs exist because we’ve found them in production cryptographic code, including code marketed as “formally verified.” So we built a tool to catch them systematically.

Crucible is a conformance testing framework for ML-KEM (FIPS 203) and ML-DSA (FIPS 204) implementations. It encodes the specific bug classes we’ve encountered in real audits as targeted, reusable test batteries that any implementation can be wired up to. Then we pointed it at every ML-KEM and ML-DSA implementation we could find.

The Setup

Crucible communicates with implementations through a simple JSON line protocol over stdin/stdout. A thin harness shim maps Crucible’s function calls to the implementation’s API. We built harnesses for 15 implementations across Rust, Go, C, C++20, and Java:

Implementation	Language	Who uses it
Reference (Crucible)	Rust	Our known-good baseline, built alongside the test suite
libcrux	Rust	CE Labs’ formally verified library
Kyber-K2SO	Go	Our own implementation
mlkem-native	C	Ships inside AWS-LC and liboqs
Go stdlib `crypto/mlkem`	Go	Every Go 1.26+ binary using TLS 1.3
AWS-LC	C	AWS KMS, S3, CloudFront
pq-crystals ref	C	The original reference from the algorithm designers
CIRCL	Go	Cloudflare’s TLS deployment
liboqs	C	The most widely used PQC prototyping library
Bouncy Castle	Java	The dominant JVM crypto library
wolfCrypt	C	Embedded/IoT, FIPS 140-3 validated
itzmeanjan/ml-kem	C++20	Header-only, fully `constexpr`
pqcrypto	Rust	Rust FFI bindings to PQClean
PQClean	C	Clean portable C implementations
Trail of Bits ml-dsa	Go	Side-channel resistant ML-DSA

The ML-KEM battery has 78 tests across 6 categories (compression arithmetic, NTT correctness, coefficient bounds enforcement, decapsulation robustness, serialization, rejection sampling). The ML-DSA battery has 51 tests across 6 categories (norm checks, arithmetic, signing internals, verification edge cases, serialization, constant-time behavior). Every test is tagged with the bug class it targets, the FIPS spec section it verifies, and, where applicable, the audit finding that motivated it.

The Results

We ran 1,296 test executions. Here’s the ML-KEM scorecard:

Implementation	Pass	Fail	Skip
Reference (Crucible)	78	0	0
libcrux v0.0.8	54	0	24
Kyber-K2SO v1.0.0	54	0	24
mlkem-native	21	0	45
Go stdlib	25	0	45
AWS-LC	33	0	45
CIRCL (Cloudflare)	33	0	45
liboqs	33	0	45
wolfCrypt	33	0	45
itzmeanjan	21	0	45
Bouncy Castle 1.80	25	2	45
pq-crystals ref	19	2	45
PQClean	19	2	45
pqcrypto (rustpq)	21	6	45

(Skipped tests are NTT/sampling internals that implementations don’t expose through their public API. Errors from single-parameter-set harnesses are omitted for clarity.)

Finding 1: Missing Encapsulation Key Modulus Check

Affected: pq-crystals/kyber ref, PQClean, pqcrypto/rustpq Severity: Conformance gap Spec reference: FIPS 203 §7.2, Equation 7.1

FIPS 203 requires that before encapsulation, the encapsulation key must pass a modulus check:

test ← ByteEncode₁₂(ByteDecode₁₂(ek[0 : 384k])). If test ≠ ek[0 : 384k], then input checking failed.

This check ensures that no 12-bit coefficient in the serialized public key encodes a value ≥ q = 3329. All three affected implementations accept a key with coefficient value 3329 without error. None of them provide a separate key validation function.

This is a spec conformance gap, not a vulnerability. The practical impact is limited to interoperability: if two implementations handle an out-of-range coefficient differently (one reduces mod q, another wraps), the same key produces different shared secrets. The pq-crystals codebase predates FIPS 203, and the modulus check was added during standardization.

Finding 2: Bouncy Castle Accepts Wrong-Length Decapsulation Keys

Affected: Bouncy Castle 1.80 (Java) Severity: Input validation gap Spec reference: FIPS 203 §7.3

Bouncy Castle’s MLKEMPrivateKeyParameters constructor accepts byte arrays of any length without validating against the expected size for the parameter set. Crucible sends a decapsulation key that is 1 byte too short (2399 bytes for ML-KEM-768, expected 2400) and Bouncy Castle proceeds with decapsulation.

A truncated dk means the implicit rejection secret z is partially missing, which could weaken the FO transform’s security guarantee. In practice, the dk is private and an attacker wouldn’t normally control it, but a corrupted key file should fail loudly rather than silently produce wrong results.

What About the Other 11 Implementations?

They all passed. Every test. libcrux, mlkem-native, AWS-LC, CIRCL, liboqs, wolfCrypt, itzmeanjan, the Go standard library, and Trail of Bits ml-dsa: all clean.

What This Means

We set out to find the kinds of bugs we’d found in audits: missing inverse NTTs, dead bounds checks, incorrect rounding, timing leaks. We built 129 tests specifically targeting those bug classes. We tested the 15 most deployed post-quantum implementations in the world.

We found two conformance gaps and zero security vulnerabilities.

This is actually the good news. The implementations that matter, the ones shipping inside AWS, Cloudflare, the Go standard library, and wolfSSL’s FIPS module, are doing the right things. The FIPS 203 standardization process added the right checks. The formally verified implementations (libcrux) pass. The clean-room implementations (mlkem-native, CIRCL, Trail of Bits) pass.

The bugs we designed Crucible to catch existed in the pre-FIPS era and have largely been fixed. The ecosystem learned from the CE Labs findings, from KyberSlash, from the various timing advisories. The 2026 implementations are better than the 2024 ones.

Crucible Is Open Source

Crucible is available on GitHub. It ships with harness templates for Rust, Go, and C. If you maintain an ML-KEM or ML-DSA implementation, wire it up and run the battery. If you find a bug we missed, it becomes a new test. The framework grows sharper over time.

cargo build --release
cargo run --bin crucible -- ./your-harness
cargo run --bin crucible -- ./your-harness --battery ml-dsa --json

The test batteries will continue to expand as we encounter new bug classes in future audits. The name is a Star Wars reference: the Crucible is the ancient Jedi vessel where younglings forge their lightsabers.

For more on where Crucible fits in a production post-quantum migration, covering primitive selection, hybrid constructions, library evaluation and rollout strategy, see our Post-Quantum Migration Playbook and the companion PQ Migration Readiness scorecard and scanner.

Summer 2026 Research Internship at Symbolic Software

Thu, 19 Mar 2026 00:00:00 +0000

Symbolic Software is looking for a research intern to join us for the summer of 2026. This is a hands-on position: you will co-author papers with me, Nadim Kobeissi, on real-world cryptography, with a focus on designing new secure constructions that address open problems in cryptographic applications people actually deploy.

I already have specific, concrete research projects and I want you to help me turn them into solid papers and artifacts that we can publish at strong conferences.

What We’re Working On

The research agenda centers on the gap between cryptographic theory and deployed systems. Secure messaging, authenticated key exchange, post-quantum migration and end-to-end encrypted media all rely on constructions that were often designed under assumptions that no longer hold, or that leave meaningful security properties on the table. We want to work out what the state of the art should be now.

Concretely, the internship will involve working on new papers that propose, formalize, and analyze cryptographic constructions addressing real problems in real systems. This means:

Identifying concrete shortcomings in cryptographic constructions used by deployed applications today.
Designing new constructions that improve on the state of the art, whether that means stronger security guarantees, better efficiency, or cleaner compositional properties.
Writing security proofs and building formal or semi-formal arguments for why the new constructions achieve their claimed properties.
Producing publication-ready papers targeting top-tier venues in applied cryptography and security.

The specific problems we tackle will depend in part on your interests and strengths, but the common thread is practical relevance: we are not interested in constructions that exist only to be proven secure. We want constructions that people will actually deploy.

Who Should Apply

You should be a graduate student (Master’s or PhD) in cryptography, computer science, or a related field, or an exceptional undergraduate with demonstrated research ability. What matters most:

Strong foundations in cryptography. You should be comfortable with standard security definitions, reduction-based proofs, and the range of modern cryptographic primitives. If you’ve taken a graduate-level cryptography course and found it straightforward, that’s a good sign.
Interest in real-world systems. The best candidates are curious about how cryptography is actually used, and misused, in practice. If you’ve ever read a protocol specification and spotted something that bothered you, we should talk.
Writing ability. Research papers require clear, precise writing. You don’t need to have published before, but you should be able to communicate technical ideas effectively in English.
Self-direction. This is a small team. You’ll have guidance and close collaboration, but you should be capable of reading papers independently, formulating questions, and pursuing ideas without constant oversight.
Intellectual honesty. Most especially, I’m looking for candidates that are honest about their work, how it’s conducted, and who are able to examine both third-party systems and their own research output critically.

Prior publications are a plus but not required. What matters is that you can think clearly about cryptographic problems and want to produce work that changes what gets deployed.

Details

Duration: Summer 2026 (approximately 3 months, with flexibility on exact dates).
Location: Remote. Candidates in or near the Paris, France time zone are preferred.
Compensation: Paid internship. Details discussed during the application process.
Deadline: April 20, 2026

How to Apply

Send an email to nadim@symbolic.software with:

Your CV or resume.
A brief note (a few paragraphs is fine) on why this internship interests you and what kinds of cryptographic problems you find compelling.
Any relevant prior work: publications, thesis drafts, course projects, or open-source contributions.

No formal cover letter needed. Just be direct about who you are and what you want to work on.

CE Labs' Approach to TLS: A Critical Analysis

Sat, 07 Mar 2026 00:00:00 +0000

This is the fourth installment in our series examining CE Labs’ cryptographic libraries. Over the past month, we have disclosed eleven vulnerabilities spanning post-quantum key encapsulation, digital signatures, hybrid public key encryption, and the formally verified F* specifications underlying them. We now turn to CE Labs’ TLS implementations: rustls-libcrux, a cryptographic provider for rustls; Bertie, a standalone TLS 1.3 implementation that has been the subject of formal verification research; and libcrux-iot, an embedded-targeted fork of libcrux. Across these three projects, we found five more bugs, bringing the total to sixteen: a signature verification function that rejects 75% of valid signatures, encryption that silently drops its authentication tag, a TLS client that performs no certificate validation, remote denial-of-service vectors, and a FIPS 204 parameter that is off by a factor of eight.

How CE Labs Handled our Disclosures

Before presenting our new findings, we document how CE Labs responded to our previous vulnerability disclosures.

In January 2026, we began our audit work and opened our first issue on CE Labs’ GitHub (#1299). It was professional and submitted in good faith. When CE Labs’ team responded, we acknowledged that their perspective was legitimate, closed the issue cooperatively, and moved on.

We then submitted four pull requests with tested fixes for security vulnerabilities, including a critical nonce reuse bug in hpke-rs (PR #117, PR #118) and issues in libcrux (PR #1315, PR #1316). These were submitted in the same professional manner as contributions from other external researchers such as Filippo Valsorda and “GuuJiang,” whom CE Labs had publicly thanked for their reports.

CE Labs’ response to our contributions was markedly different:

They closed all four of our pull requests.
They publicly accused us of “putting the community at risk” and called our disclosures “irresponsible.”
They blocked us from their GitHub organization, preventing us from submitting any further issues or pull requests.
They then copied our fixes and applied them without credit, after blocking us and closing the PRs.
They published security advisories that downplayed severity and obscured impact, classifying our critical nonce reuse vulnerability as “medium severity” and describing fixes with vague labels like “fix context counter” and “avoid panic on AEADError” rather than explaining the vulnerabilities and their impact.
To date, no RustSec advisories exist for their most severe vulnerabilities.

The GitHub block had an immediate practical consequence: we discovered it when attempting to submit our fifth fix, a patch for an AES-GCM denial-of-service crash in libcrux-psq. That fix remains available on our fork but could never be submitted upstream.

We offered to continue disclosing our remaining findings, including those being revealed here today, as GitHub pull requests complete with tested fixes provided on the day of disclosure. CE Labs declined, and then accused us of not giving them time to address vulnerabilities before public disclosure. It was CE Labs who blocked our ability to submit fixes, after we had already disclosed four bugs complete with tested patches, free of charge.

After we submitted our initial four bug disclosures with tested fixes, we were blocked by CE Labs from submitting additional fixes, something we discovered when trying to submit our fifth fix. In spite of this, CE Labs accused us of not giving them time to fix the bugs we were disclosing.

While CE Labs described our disclosures as “irresponsible” and “putting the community at risk”, we posit that it is their active lobbying to get their cryptographic libraries merged in production into Signal, Google and OpenMLS’s stacks, despite their being aware of, and at times openly admitting their immaturity, that constitutes irresponsible behavior. CE Labs has also often acted to downplay the severity of bugs that were found to impact applications such as Signal in production, and to this day has not issued complete or appropriate advisories for their most severe, critical vulnerabilities.

CE Labs’ own Code of Conduct commits to “accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience” and “focusing on what is best not just for us as individuals, but for the overall community.” We leave it to the reader to judge whether CE Labs’ handling of our disclosures lived up to these principles.

Findings

Our eleven earlier findings included bugs in formally verified F* specifications, false proofs accepted by a build system that defaults to not checking them, and unproven axioms that render entire proof infrastructures unsound. The five new ones are:

A signature verification function that rejects approximately 75% of valid ECDSA P-256 signatures.
A TLS 1.2 encryption path that silently drops the authentication tag, eliminating all integrity protection.
A TLS 1.3 client that performs no certificate chain validation or hostname verification.
Remote denial-of-service vectors exploitable with a single malformed handshake message.
A FIPS 204 parameter that is off by a factor of eight.

rustls-libcrux

The rustls-libcrux project provides a CryptoProvider implementation for the rustls TLS library, replacing rustls’s default cryptographic backend with CE Labs’ libcrux. It implements signature verification, AEAD encryption and decryption, key exchange, and RSA signing: the cryptographic foundation that the TLS protocol depends on for authentication, confidentiality, and integrity.

Finding 1: ECDSA P-256 Verification Rejects ~75% of Valid Signatures

File: libcrux-provider/src/verify.rs, lines 57–70.

The ECDSA P-256 signature verification code extracts the r and s components from a DER-encoded signature and converts them to fixed-size 32-byte arrays:

let r: [u8; 32] = sig.r.as_bytes().try_into().map_err(|_| InvalidSignature)?;
let s: [u8; 32] = sig.s.as_bytes().try_into().map_err(|_| InvalidSignature)?;

The sig.r and sig.s values are der::asn1::Int types. The Int::as_bytes() method returns the raw DER value bytes, which include a leading 0x00 sign byte when the most significant bit of the integer is set. This is how DER encodes positive integers: if the MSB would otherwise indicate a negative number, a 0x00 byte is prepended.

For ECDSA P-256, r and s are 32-byte unsigned scalars. When the MSB is set, which happens with roughly 50% probability for each scalar, DER encoding prepends 0x00, making as_bytes() return 33 bytes. The try_into::<[u8; 32]>() conversion then fails with a length mismatch, and the signature is rejected as invalid.

The probability that at least one of r or s has its MSB set is $1 - 0.5 \cdot 0.5 = 75\%$. Three out of every four valid ECDSA P-256 signatures will be rejected by this code.

This is the primary signature scheme for TLS 1.3 server authentication. A rustls client using the libcrux provider will fail to complete TLS handshakes with approximately 75% of servers, because the server’s valid certificate signature will be incorrectly rejected.

Finding 2: TLS 1.2 Encryption Drops Authentication Tag

File: libcrux-provider/src/aead.rs, lines 161–163.

The TLS 1.2 MessageEncrypter implementation discards the AEAD authentication tag:

libcrux::aead::encrypt(&self.0, payload.as_mut(), iv, &aad)
    .map_err(|_| rustls::Error::EncryptError)
    .map(|_| OutboundOpaqueMessage::new(m.typ, m.version, payload))
//       ^^^ tag discarded

The libcrux::aead::encrypt() function returns the authentication tag as a separate value. The TLS 1.3 code path handles this correctly, appending the tag to the ciphertext:

.map(|tag| {
    payload.extend_from_slice(tag.as_ref());
    OutboundOpaqueMessage::new(m.typ, m.version, payload)
})

The TLS 1.2 path captures the tag as _ and drops it. The resulting TLS record contains only ciphertext with no integrity protection. The receiving peer will fail to decrypt because it expects a 16-byte authentication tag appended to the ciphertext, and the connection will fail.

This is not a subtle vulnerability. Authenticated encryption without the authentication tag is just encryption, and the entire integrity guarantee of the TLS record layer is eliminated. The fix is one line: append the tag, exactly as the TLS 1.3 path already does.

Bertie

Bertie is CE Labs’ standalone TLS 1.3 implementation, written in Rust. It is described as a “minimal, low-level TLS 1.3 implementation” and has been the subject of formal verification research. Unlike rustls-libcrux, which delegates protocol logic to rustls, Bertie implements the TLS 1.3 handshake and record layer from scratch.

Finding 3: No Certificate Chain Validation or Hostname Verification

Files: src/tls13cert.rs, lines 356–373; src/tls13handshake.rs, lines 318–331.

Bertie’s TLS 1.3 client accepts any certificate whose public key produces a valid CertificateVerify signature over the handshake transcript. No other validation is performed:

No certificate chain validation (issuer signature verification)
No hostname or SNI matching against Subject CN or Subject Alternative Name
No validity period checking (expiration or not-before dates)
No certificate extension validation (BasicConstraints, KeyUsage)
No revocation checking (CRL or OCSP)
No trust anchor verification (root CA store)

The verification_key_from_cert() function at tls13cert.rs:356 parses a certificate by skipping version, serial number, signature algorithm, issuer, validity, and subject fields, extracting only the SubjectPublicKeyInfo. The server_name stored in ServerPubInfo is populated during the handshake but never compared against any field in the certificate.

The handshake function put_server_signature() at tls13handshake.rs:318 extracts the public key using verification_key_from_cert() and verifies the CertificateVerify signature over the transcript. If the signature is valid, the handshake proceeds. The certificate itself is never examined.

An attacker can present a self-signed certificate for any domain, or a certificate with no domain at all, and Bertie will accept it, provided the CertificateVerify signature is valid with respect to the key in that certificate. This completely defeats server authentication. The attacker does not need to compromise a certificate authority, exploit a parsing vulnerability, or perform any cryptographic attack. They simply generate a key pair, create a self-signed certificate, and present it.

This is not a missing feature in an early prototype. Certificate validation is the mechanism by which TLS clients distinguish legitimate servers from imposters. Without it, the encrypted channel provides confidentiality against passive observers but no authentication whatsoever. The client cannot know who it is talking to.

Finding 4: Remote Denial of Service via `.unwrap()` in KEM Operations

File: src/tls13crypto.rs, lines 710, 750, 752.

Three .unwrap() calls on fallible decode() results will crash the process if given malformed key material:

// Line 710 — server-side, processes client's key_share
let pk = PublicKey::decode(alg.libcrux_kem_algorithm()?, &pk.declassify()).unwrap();

// Line 750 — client-side, processes server's key_share
let sk = PrivateKey::decode(librux_algorithm, &sk.declassify()).unwrap();

// Line 752 — client-side
let ct = Ct::decode(librux_algorithm, &ct).unwrap();

A remote attacker can crash a Bertie server by sending a ClientHello with a malformed key_share extension. The malformed public key bytes reach kem_encap() at tls13handshake.rs:620, where PublicKey::decode().unwrap() panics. Similarly, a malicious server can crash a Bertie client by sending a ServerHello with a malformed key_share, reaching kem_decap() at tls13handshake.rs:243.

This is a single-packet denial of service. No handshake completion is required. No authentication is needed. One malformed message crashes the process.

The fix is mechanical: replace .unwrap() with .map_err(|_| CRYPTO_ERROR)?. The correct error-handling pattern is used elsewhere in the same file.

libcrux-iot

libcrux-iot is CE Labs’ embedded-targeted fork of libcrux, designed for constrained IoT devices. It implements ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SHA-3 (FIPS 202), with C code extracted via the Eurydice toolchain for deployment on bare-metal platforms.

Finding 5: ML-DSA Pre-Hash Uses Wrong Output Length

Files: ml-dsa/src/pre_hash.rs, line 40; ml-dsa/src/ml_dsa_44.rs, line 121; ml-dsa/src/ml_dsa_65.rs, line 134; ml-dsa/src/ml_dsa_87.rs, line 121.

FIPS 204 Table 2 specifies that the SHAKE-128 pre-hash output length for HashML-DSA is 256 bytes (2048 bits). The module docstring correctly states this:

//! pre-hash trait for SHAKE-128, with a digest length of 256 bytes.

But the implementation allocates a 32-byte buffer and asserts this size:

// pre_hash.rs:40
debug_assert_eq!(output.len(), 32);

All call sites allocate 32-byte buffers:

// ml_dsa_44.rs:121, ml_dsa_65.rs:134, ml_dsa_87.rs:121
let mut pre_hash_buffer = [0u8.classify(); 32];

This is not an edge case. The pre-hash output length is a fundamental parameter of the HashML-DSA mode. SHAKE-128 at 32 bytes produces a different digest than SHAKE-128 at 256 bytes. Signatures produced by this implementation using the sign_pre_hashed_shake128 API will not verify against any FIPS 204-compliant implementation that uses the correct 256-byte output, and vice versa.

The bug is present in the upstream celabshq/libcrux as well, indicating it was inherited rather than introduced during the IoT fork. The pre-hashed NIST KAT files were generated by the same codebase, so they cannot detect the discrepancy. ACVP test vectors do not cover the HashML-DSA mode.

Pure ML-DSA signing and verification, the default and most commonly used mode, is unaffected. Only the sign_pre_hashed_shake128 and verify_pre_hashed_shake128 APIs are impacted.

The Scope of the Problem

These five findings bring the total to sixteen bugs across CE Labs’ cryptographic ecosystem in one month. The pattern we have documented extends beyond any single library.

In libcrux, we found wrong F* specifications, false proofs, and unsound axioms. In hpke-rs, we found nonce reuse and broken forward secrecy. In rustls-libcrux, we find that TLS 1.3 connections will fail 75% of the time and TLS 1.2 encryption drops its authentication tag. In Bertie, we find a TLS implementation that does not validate certificates. In libcrux-iot, we find FIPS non-compliance in a post-quantum signature parameter.

The rustls-libcrux findings are particularly instructive. This is a cryptographic provider whose entire purpose is to correctly implement a small set of well-specified cryptographic operations for a well-tested TLS library. The operations are standard: ECDSA verification, AEAD encryption and decryption. The specifications are unambiguous. And yet the implementation rejects 75% of valid ECDSA signatures and drops authentication tags. These are not subtle corner cases. They are the primary code paths.

Bertie’s missing certificate validation is harder to characterize charitably. Certificate chain validation is not an optional feature of TLS. It is the mechanism by which a client determines whether the server is who it claims to be. A TLS 1.3 implementation that omits this check has not implemented TLS in any meaningful sense. It has implemented an encrypted channel to an unknown party.

The fact that Bertie has been the subject of formal verification research makes this omission more concerning, not less. The verification effort focused on the handshake protocol’s cryptographic properties while the most basic authentication mechanism was absent. This is verification theatre in its purest form: proving properties of a protocol that cannot authenticate its peer.

Across sixteen findings in six CE Labs projects, the pattern is consistent. The verified core is surrounded by an unverified periphery where basic engineering discipline is absent. The specifications that the verified code is checked against are themselves wrong. The build system defaults to not checking proofs. And the marketing claims make no distinction between what has been verified and what has not.

Formal verification is a tool. Like any tool, its value depends on how it is applied. When it is applied selectively, communicated imprecisely, and used to justify claims that the evidence does not support, it becomes something worse than useless: it becomes a source of false confidence. Users who trust “formally verified” to mean “safe to deploy” will deploy code that rejects valid signatures, drops authentication tags, and accepts certificates from anyone.

Making Verifpal Easier to Reason About

Sun, 01 Mar 2026 00:00:00 +0000

A couple of weeks after releasing the Rust rewrite, we’ve shipped a deep architectural redesign of Verifpal’s analysis engine in Verifpal version 0.50.0. The observable behavior hasn’t changed, but the engine is now faster (3x on the full test suite), formally cleaner, and significantly easier to reason about. This post explains what changed and why, starting from the basics.

What Verifpal Does, and Why the Engine Matters

Verifpal analyzes cryptographic protocols. You describe a protocol (who talks to whom, what gets encrypted, what gets signed) and Verifpal checks whether an attacker can break its security properties: steal secrets, forge messages, impersonate participants.

The engine that does this analysis has three jobs:

Deduction: figure out everything the attacker can learn from observing (and tampering with) the protocol.
Search: systematically try different attacker strategies, such as replacing values on the wire or injecting forged messages.
Query evaluation: check whether any security property has been violated.

The old engine did all three jobs correctly, but the way it organized its work made it hard to see why it was correct. The redesign doesn’t change what the engine computes. It changes how the computation is structured, so that correctness becomes obvious rather than subtle.

Change 1: One Place for All the Rules

The Problem

A protocol verifier is only as good as its equational theory, the formal rules that define what cryptographic operations do. In Verifpal, these rules say things like:

DEC(k, ENC(k, m)) → m                  [given: k]
AEAD_DEC(k, AEAD_ENC(k, m, ad), ad) → m [given: k, ad]
SIGNVERIF(G^sk, msg, SIGN(sk, msg)) → nil [verification check]
G^a^b = G^b^a                           [DH commutativity]

The first rule says: if you have the key k and you see ENC(k, m), a value encrypted with that key, you can recover the plaintext m. The Diffie-Hellman commutativity rule says: G^a^b and G^b^a are the same value, which is the mathematical property that makes key agreement work.

Before this redesign, these rules were scattered across five files. The declarative specifications lived in primitive/spec.rs. The code that interpreted those specs and checked “can the attacker actually do this?” lived in possible.rs. The code that applied the rules during protocol execution lived in rewrite.rs. DH commutativity was handled in equivalence.rs. And the filtering of constructible values for the attacker lived in inject.rs.

This meant that the answer to “what can the attacker do?” didn’t have a single location in the code. You had to hold all five files in your head simultaneously.

The Solution

A new module, theory.rs, now centralizes every derivation operation. The complete equational theory, all 14 rewrite rules for 21 cryptographic primitives, is listed in a single doc comment at the top of the file:

DEC(k, ENC(k, m)) → m                                    [given: k]
AEAD_DEC(k, AEAD_ENC(k, m, ad), ad) → m                  [given: k, ad]
AEAD_ENC(k, m, ad) → ad                                   [passive]
ENC(k, m) → m                                             [given: k]
BLIND(factor, m) → m                                      [given: factor]
PKE_DEC(sk, PKE_ENC(G^sk, m)) → m                         [given: sk]
PKE_ENC(G^sk, m) → m                                      [given: sk (via G^sk)]
SIGNVERIF(G^sk, msg, SIGN(sk, msg)) → nil                 [rewrite: def check]
RINGSIGNVERIF(G^sk, ..., RINGSIGN(sk, ...)) → nil         [rewrite: def check]
UNBLIND(factor, SIGN(sk, BLIND(factor, m)), m) → SIGN(sk, m) [rewrite]
SHAMIR_SPLIT(s)[i] + SHAMIR_SPLIT(s)[j] → s               [recompose: 2-of-3]
SHAMIR_JOIN(SHAMIR_SPLIT(s)[i], SHAMIR_SPLIT(s)[j]) → s   [rebuild]
CONCAT(a, b, ...) → a, b, ...                             [passive: reveals args]
G^a^b = G^b^a                                              [DH commutativity]

All eight operations the attacker can perform are implemented in this one file: decompose, passive-decompose, recompose, reconstruct (primitive), reconstruct (equation), rewrite, rebuild, and password extraction. The old possible.rs became a one-line re-export shim. No callers needed to change their imports.

The practical benefit: to understand what the attacker can do, read one file. To add a new cryptographic primitive, edit one file (spec.rs). The engine picks up the new rules automatically.

Change 2: The Three-Phase Pipeline

The Problem

When analyzing a protocol, the engine needs to do three things for each principal (participant): resolve all symbolic values, figure out what the attacker learns, and check security queries. The old engine interleaved these steps:

for each principal:
    resolve values
    loop:
        check queries        ← interleaved!
        try one deduction step
        if no progress: stop
    check queries again

The query check inside the deduction loop meant that the engine could exit early: if all queries happened to resolve mid-deduction, why keep going? This was a performance optimization, and it worked. But it had a subtle cost. The deduction loop was no longer a clean mathematical object. Its behavior depended on when queries resolved, which depended on what order values were processed, which was an implementation detail rather than a formal property.

The Solution: Separation of Concerns

The pipeline is now three explicit phases:

pub fn verify_standard_run(ctx, km, principal_states, stage) {
    for ps in principal_states {
        // Phase 1: Trace generation
        let ps_resolved = generate_trace(ctx, km, ps, &attacker)?;

        // Phase 2: Knowledge closure (monotone fixed-point)
        compute_knowledge_closure(ctx, km, &ps_resolved, stage)?;

        // Phase 3: Query evaluation
        verify_resolve_queries(ctx, km, &ps_resolved)?;
    }
}

Phase 1 (generate_trace) does all the mechanical work: resolve symbolic constant references to concrete values, record which slots differ from the original protocol trace, inject structural templates into the attacker’s knowledge, apply cryptographic rewrite rules (like DEC(k, ENC(k, m)) → m), and check that nothing went wrong.

Phase 2 (compute_knowledge_closure) is a pure deduction loop. It runs the attacker’s derivation rules until nothing new can be learned: no query checks, no early exits, no side effects beyond expanding the attacker’s knowledge set. This is now a textbook monotone fixed-point computation, which gives us a clean correctness argument.

Phase 3 (verify_resolve_queries) checks all security queries against the final, complete attacker knowledge.

Why Fixed Points Matter

This might sound like an academic distinction, but it has consequences. A monotone fixed point is a concept from order theory. Informally: if you have a function F that only ever adds to a set (never removes), and the set has a maximum size, then repeatedly applying F will eventually reach a stable state where applying F doesn’t change anything. That stable state is the least fixed point.

The attacker’s deduction rules are monotone: the attacker only ever learns new values, never forgets them. The set of derivable values is finite (bounded by the protocol model). So the deduction loop is computing a least fixed point, and the Knaster-Tarski theorem guarantees it converges. Every value in the result is derivable. No value is missed. These properties hold regardless of evaluation order.

The old interleaved loop approximated this, but the early exits and query checks made the argument indirect. Now it’s immediate: compute_knowledge_closure is a Kleene iteration over a monotone function, and the Knaster-Tarski theorem does the rest.

Change 3: Provenance-Tagged Values

The Problem

Verifpal’s analysis is fundamentally about perspective. When an attacker intercepts and modifies a message on the wire, the sender and receiver see different things. Alice computes k = HASH(secret) and sends it to Bob. The attacker replaces k with HASH(attacker_value). Alice still “sees” her original k. Bob sees the attacker’s version. If the engine gets this wrong, so that Alice somehow “sees” the tampered value in her own subsequent computations, authentication queries produce false positives.

The old engine tracked this with three separate copies of every value:

// Old design
pub struct SlotValues {
    pub assigned: Value,        // current value (after mutation + rewrite)
    pub before_rewrite: Value,  // after mutation, before rewrite
    pub before_mutate: Value,   // original (before attacker tampering)
    pub mutated: bool,
    pub creator: PrincipalId,
    pub sender: PrincipalId,
    pub rewritten: bool,
}

The decision about which copy a principal “sees” was made by a function called should_use_before_mutate:

// Old logic
pub fn should_use_before_mutate(&self, i: usize) -> bool {
    self.values[i].creator == self.id
        || !self.meta[i].known
        || !self.meta[i].wire.contains(&self.id)
        || !self.values[i].mutated
}

This worked, but the meaning was indirect. You had to know that creator == self.id means “I made this myself, so I see my version.” You had to know that !mutated means “the attacker didn’t touch it, so there’s only one version.” The fields creator, sender, and mutated were scattered alongside the value copies, with no explicit connection between them.

The Solution: Provenance

The redesign introduces an explicit Provenance record:

pub struct Provenance {
    pub creator: PrincipalId,
    pub sender: PrincipalId,
    pub attacker_tainted: bool,
}

pub struct SlotValues {
    pub value: Value,           // current canonical value
    pub original: Value,        // the principal's own computation
    pub pre_rewrite: Value,     // forensic snapshot (for error messages)
    pub rewritten: bool,
    pub provenance: Provenance,
}

The visibility decision is now a direct provenance check:

pub fn should_use_original(&self, i: usize) -> bool {
    !self.values[i].provenance.attacker_tainted
        || self.values[i].provenance.creator == self.id
        || !self.meta[i].known
        || !self.meta[i].wire.contains(&self.id)
}

The semantic difference is subtle but important. The old code asked: “was this value mutated, and who created it?” The new code asks: “is this value tainted by the attacker?” The answer is the same, since the conditions haven’t changed, but the question now asks what happened to the value rather than what fields happen to be set.

This also cleaned up the naming throughout the codebase: assigned → value, before_mutate → original, before_rewrite → pre_rewrite, mutated → provenance.attacker_tainted, set_assigned() → set_value(). These renamings touched every module, but each change made the code read more naturally.

Change 4: Bounded-Depth Search

The Problem

Verifpal’s active attacker analysis works by trying mutations: replacing wire values with attacker-controlled alternatives, then checking whether the attacker can derive new secrets. The old engine used a ten-stage search controlled by seven empirical constants:

// Old design
const BUDGET: StageBudget = StageBudget {
    exhaustion_threshold: 6,
    max_stage: 10,
    max_subset_weight: 3,
    max_subsets_per_weight: 150,
    max_weight1_mutations: 150,
    max_mutations_per_subset: 50000,
    max_full_product: 50000,
    max_scan_budget: 80000,
};

These numbers worked. Verifpal found attacks in Signal, Scuttlebutt, TLS 1.3, and 94 test models. But several independent dimensions were conflated into a single “stage” counter. The stage number simultaneously controlled:

Which values to mutate: stages 1–3 only offered minimal replacements (nil, G^nil); stage 4+ offered all known values
How deeply to nest injected values: stage 5+ enabled recursive injection
Which primitives to consider: stages 0–1 blocked primitive injection; stage 2 blocked “explosive” primitives (HASH, HKDF, CONCAT)
When to give up: exhaustion after stage 6

This meant you couldn’t answer a simple question: “what class of attacks does Verifpal guarantee to find?” The answer depended on stage progression, budget exhaustion, and the interaction of four separate thresholds.

On top of this, a special-case function called verify_active_equation_bypass ran before the main search. It directly tried replacing Diffie-Hellman public keys with the attacker’s own key, the canonical man-in-the-middle attack. This was necessary because the staged search might not try this specific combination within its budget. But it was a symptom: if the general search needed a hand-coded shortcut for the most common attack class, the general search had blind spots.

The Solution: One Parameter

The new search is controlled by a single depth parameter:

struct SearchConfig {
    depth: usize,                // Default: 3
    max_subsets_per_weight: usize,
    max_weight1_mutations: usize,
    max_mutations_per_subset: usize,
    max_full_product: usize,
    max_scan_budget: u32,
}

At depth d, the engine explores all k-subsets for k ≤ d, with all attacker-known values as potential replacements, and recursive injection nesting bounded by max(0, d − 1). The coverage guarantee is precise:

At depth d, Verifpal explores all attacker strategies involving at most d simultaneous value substitutions, with injected values of nesting depth at most d.

The ten stages collapsed into three depth levels. The STAGE_MUTATION_EXPANSION constant was deleted, since all mutations are now available at every depth. The STAGE_RECURSIVE_INJECTION constant and inject_primitive_stage_restricted function were deleted too, because injection eligibility is controlled solely by the depth parameter.

The equation bypass was deleted entirely. Replacing a received G^sk with G^nil is a natural first-order mutation at depth 1: G^nil is always in the attacker’s knowledge set (it’s the attacker’s own DH public key), and equation-valued slots accept equation replacements. No special case needed. The fact that the old engine required one tells you the staged search was leaving holes that were patched ad hoc.

The Result

	Old (10-stage)	New (depth-3)
Parameters	7 empirical constants	1 depth + 5 budget caps
Stages/depths	10	3
Equation bypass	Special-case function	Natural depth-1 mutation
Test suite time	~11s	~3.5s
Coverage guarantee	Implicit	Explicit (k ≤ d substitutions, nesting ≤ d)
Attacks found	All 147 tests	All 147 tests (identical)

3x faster, clearer coverage semantics, less code. The default depth of 3 finds every attack that the 10-stage system found, in a third of the time.

How It All Fits Together

These four changes are not independent. They build on each other:

The unified theory gives the engine a single, auditable rule set. When the deduction loop asks “what can the attacker derive?”, the answer comes from one module with one doc comment listing every rule.
The three-phase pipeline separates what the attacker learns from what security properties hold. The deduction loop runs to completion as a clean fixed point; query evaluation happens after, on the final knowledge set.
Provenance tagging turns the visibility decision, meaning which value a principal perceives, into an explicit metadata check rather than an indirect inference from scattered boolean fields.
The bounded-depth search eliminates the staged complexity and the equation bypass special case, giving a clear coverage guarantee parameterized by a single number.

Each change made the next one easier. The unified theory simplified the deduction loop. The clean deduction loop enabled the phase separation. The phase separation made the provenance changes straightforward to verify. And the provenance model made the search redesign cleaner because mutation injection has simpler semantics when taint is explicit.

Updated Tooling

The engine redesign was a good occasion to bring the rest of the Verifpal ecosystem up to date.

VSCode extension. The VSCode extension has been updated to work with the Rust rewrite, restoring hover documentation, document formatting, attacker analysis with inline result decorations, and protocol diagram rendering. The interface between the extension and the Rust binary is simpler than the original: pre-formatted display strings replace the old JSON round-trip, cutting two subcommands and eliminating the need for JSON deserialization on the Rust side.

Neovim extension. There’s a new Neovim extension with syntax highlighting, inline diagnostics that mark passing and failing queries directly in the sign column, document formatting via verifpal pretty, and hover documentation for all 21 primitives, all query types, and all keywords. It uses Neovim’s native diagnostic API, so no LSP server is required, and it installs with a single line in lazy.nvim or packer.

Verifpal Manual. Print 18 of the Verifpal Manual covers all of the changes described in this post, meaning the unified theory, the three-phase pipeline, provenance tagging, and the bounded-depth search, alongside the existing reference material.

Verifpal Workbench. The browser-based Workbench has been updated with the latest WASM build, incorporating the engine redesign and all new primitives.

Verifpal Workbench: Protocol Analysis in Your Browser

Tue, 24 Feb 2026 00:00:00 +0000

Yesterday we announced the Rust rewrite of Verifpal. Today we’re shipping something that the rewrite made possible: Verifpal Workbench, a browser-based environment where you can write, verify, and visualize cryptographic protocol models with nothing to install.

The entire Verifpal verification engine now compiles to a 350 KB WebAssembly binary. Open a browser tab, write a model, click Verify. The analysis runs client-side on your machine. No server, no upload, no account.

Why a Browser Tool?

Verifpal was designed to make formal verification accessible to engineers and students who don’t have a background in formal methods. But “accessible” has always meant “download a binary and learn the command line”, which is still a barrier, especially in a classroom setting.

We’ve wanted to fix this for years. The old Go codebase used cgo indirectly through several dependencies and relied on OS-specific terminal handling, making a clean WASM compilation impractical. The Rust rewrite is pure Rust with no C/FFI and no system calls in the core engine, which made WASM a natural target.

Verification and Analysis

The screenshot below shows the Workbench analyzing a simplified model of the Signal Protocol. The left panel is the editor with syntax highlighting: keywords like principal and attacker in bold, primitives like HASH, HKDF, AEAD_ENC in green, query types in red, and message arrows in amber. The right panel shows the verification results. confidentiality? m1 passes, but authentication? Alice -> Bob: e1 fails, because the active attacker can forge the encrypted message.

Below the failed query, the Workbench displays the full attack trace, the same output you’d see on the command line, showing exactly how the attacker mutates values, which keys they derive, and how they reconstruct the forged ciphertext. This is the Signal model running under a phase[1] key compromise scenario where both Alice and Bob leak their long-term private keys, so the authentication failure is expected: forward secrecy protects message confidentiality after key compromise, but not authentication.

Protocol Diagrams

Click “Diagram” to generate an SVG sequence diagram directly from the model text. The diagram below shows the same Signal model visualized as a message sequence chart: Alice and Bob’s computation blocks appear as annotation boxes on their lifelines, message arrows show the transmitted constants, and phase boundaries are marked with dashed red lines.

The diagrams are generated entirely client-side by parsing the Verifpal model text in JavaScript: no server round-trip, no external library. They render as inline SVG, so they scale cleanly and can be right-clicked and saved for use in papers or presentations.

Built-in Examples

The dropdown menu includes twelve example models covering a range of protocol patterns:

Simple DH Exchange — basic Diffie-Hellman with AEAD
Challenge-Response — nonce-based authentication with signatures
Signal Protocol — simplified X3DH + Double Ratchet with forward secrecy
Needham-Schroeder — classic symmetric-key protocol with known attacks
Blind Signature — BLIND/UNBLIND protocol
Double Ratchet — DH ratchet with symmetric chain keys
Salt Channel — ephemeral DH + signed key exchange
And five more covering PKE, Shamir secret sharing, digital signatures, and AEAD variants

Each example can be verified in the browser in under a second for simple models, or a few seconds for complex ones like Signal.

How It Works

The Workbench is a single HTML page that loads the Verifpal WASM module. The architecture is straightforward:

Rust side. The crate exposes two #[wasm_bindgen] entry points: wasm_verify(input) and wasm_pretty(input). Each call resets all global state (principal names, value IDs, attacker knowledge, analysis counters), parses the model from source text, runs the full verification pipeline, and returns a JSON response with results and captured analysis messages.

#[wasm_bindgen]
pub fn wasm_verify(input: &str) -> String {
    wasm_reset_all_state();
    let m = match parser::parse_string("workbench.vp", input) {
        Ok(m) => m,
        Err(e) => return json_error(&e),
    };
    // ... sanity check, init results, run verification ...
    json_results(&results, &code, &messages)
}

Feature gating. The cli feature (clap, colored, rayon) and the wasm feature (wasm-bindgen) are mutually exclusive. Rayon parallelism is replaced with sequential execution in the WASM build. The TUI, terminal color output, and OS-dependent code (tput, open, thread::sleep) are compiled out. Analysis progress messages are captured into a buffer instead of printed to stdout.

JavaScript side. The page includes a syntax-highlighted code editor (custom tokenizer, no external library), a results panel showing pass/fail for each query with attack traces, and an SVG protocol diagram generator that parses the model text client-side.

Try It

Open verifpal.com/workbench, pick an example from the dropdown, and click Verify. Or write your own model from scratch: the Verifpal User Manual documents the full language.

The Workbench is open source as part of the Verifpal project, licensed under GPLv3. The source is available on GitHub.

Verifpal, Rewritten in Rust

Mon, 23 Feb 2026 00:00:00 +0000

Today we’re releasing a complete rewrite of Verifpal in Rust. Every line of Go has been replaced. The result is a faster, more correct, and more capable protocol verifier, with a new analysis technique, a rich terminal interface, 147 tests (up from 67), and a binary that ships with zero runtime dependencies.

Verifpal 0.40.1 is a ground-up rearchitecture. It fixes longstanding design limitations and introduces features that weren’t possible in the old codebase.

Your browser does not support the video tag. Download the demo.

Why Rewrite?

Verifpal was first released in 2019, written in Go. Go served the project well for its first seven years: fast compilation, easy cross-platform builds, and a straightforward concurrency model. But as the analysis engine grew more sophisticated, Go’s limitations started to compound.

Parallel slices instead of structured data. The core PrincipalState type in Go maintained 18 separate parallel slices (Constants, Assigned, Creator, BeforeMutate, BeforeRewrite, KnownBy, DeclaredAt, Phase, and more), all correlated by index. Adding a new field meant updating every function that iterated over principal state. An off-by-one in any slice silently corrupted the analysis.

Interface boxing and runtime casts. Go’s Value type used an interface (ValueData) with three implementing types. Every operation required a type switch and cast: v.Data.(*Constant). The compiler couldn’t help you if you forgot a case or cast to the wrong type. The value.go file alone was 935 lines, much of it repetitive dispatch logic.

Global mutable state. The attacker’s knowledge base was a package-level global behind a sync.RWMutex. Every test run had to reinitialize it. Defensive snapshot copies on every read added allocation pressure in the hottest code paths.

No unit tests. The Go codebase had a single TestMain function that ran 67 integration tests. There were no unit tests for value equivalence, equation flattening, primitive rewriting, or any of the core symbolic operations. Bugs in these low-level functions only surfaced as incorrect results on full protocol models.

None of these were insurmountable, and plenty of good software is written in Go. But for a symbolic verification engine where correctness is paramount and the core data structures are recursive algebraic types, Rust is a natural fit.

What Changed

Algebraic Types All the Way Down

The new Value type is a Rust enum:

pub enum Value {
    Constant(Constant),
    Primitive(Arc<Primitive>),
    Equation(Arc<Equation>),
}

Pattern matching is exhaustive, so the compiler rejects any function that forgets a variant. Accessor methods like try_as_constant() return Result<&Constant> instead of panicking, and errors propagate with ?. The 935-line value.go has been split into five focused modules: value.rs, equivalence.rs, hashing.rs, resolution.rs, and rewrite.rs.

Structured Principal State

The 18 parallel slices are gone. Each protocol constant is now a single SlotValues struct:

pub struct SlotValues {
    pub assigned: Value,
    pub before_rewrite: Value,
    pub before_mutate: Value,
    pub mutated: bool,
    pub rewritten: bool,
    pub creator: PrincipalId,
    pub sender: PrincipalId,
}

Immutable metadata (guard status, wire participation, phase membership) lives in a separate SlotMeta struct shared via Arc:

pub struct PrincipalState {
    pub meta: Arc<Vec<SlotMeta>>,       // shared, immutable
    pub values: Vec<SlotValues>,        // deep-cloned per attack stage
    pub index: Arc<HashMap<ValueId, usize>>,
}

When cloning state for a new attack stage, only values is deep-copied. The metadata and index increment an atomic reference count, which is O(1). This pattern eliminates an entire class of parallel-slice indexing bugs while reducing clone overhead.

Three-Valued Lifecycle

Every protocol constant tracks three snapshots of its value: before_mutate (original), before_rewrite (after attacker mutation but before primitive rewriting), and assigned (final). The resolution system uses a simple rule to decide which value a principal actually sees:

pub fn should_use_before_mutate(&self, i: usize) -> bool {
    self.values[i].creator == self.id
        || !self.meta[i].known
        || !self.meta[i].wire.contains(&self.id)
        || !self.values[i].mutated
}

When a principal created a value themselves, or when it wasn’t sent over the wire, or when the attacker hasn’t mutated it, the principal sees the original. This prevents the false-positive authentication failures that plagued earlier versions, a subtle correctness issue that the structured data model makes explicit and verifiable.

Hand-Written Parser

The Go version used a PEG grammar (libpeg.peg) that generated parser code. The Rust version replaces it with a hand-written recursive descent parser operating directly on byte slices: zero allocations during lexing, better error messages with position context, and no build-time code generation dependency. The parser is 841 lines, self-contained, and easy to maintain.

Trait-Based Primitive Dispatch

The 21 built-in cryptographic primitives (AEAD_ENC, AEAD_DEC, SIGN, SIGNVERIF, HASH, HKDF, DH operations, PKE, blind signatures, Shamir secret sharing, and more) are defined as structured specs with function pointer dispatch:

pub struct PrimitiveSpec {
    pub name: &'static str,
    pub decompose: DecomposeRule,
    pub recompose: RecomposeRule,
    pub rewrite: RewriteRule,
    pub rebuild: RebuildRule,
    pub definition_check: bool,
    pub explosive: bool,
    pub password_hashing: Vec<usize>,
}

Each rule encodes the primitive’s cryptographic semantics declaratively. For example, AEAD_ENC’s decompose rule says: “given the key (argument 0), reveal the plaintext (argument 1); associated data (argument 2) is always publicly extractable.” The Go version encoded the same logic through scattered switch statements across multiple files.

The rewrite also cleanly separates two concepts that were previously conflated: definition check (an inherent property of the primitive: AEAD_DEC always requires the correct key) and instance check (set by the ? suffix in model syntax, marking one specific decryption operation as verified by the principal). This distinction is critical for correctly modeling protocols where some cryptographic operations are checked and others are blindly accepted.

No Globals, Explicit Context

All mutable verification state lives in a VerifyContext struct passed explicitly through the call stack. The only global mutable state in the entire codebase is a single AtomicU32 analysis counter used by the TUI, a pragmatic exception for a progress indicator that must be readable from a rendering thread without holding a reference to the verification context.

RwLock poison recovery (unwrap_or_else(|e| e.into_inner())) prevents cascading failures when a thread panics during testing, ensuring that one failing test doesn’t poison the lock for all subsequent tests running in parallel.

Equation Bypass: A New Attack Strategy

The biggest new feature has nothing to do with language or architecture. It’s a new analysis technique called Equation Bypass, and it finds attacks the Go version sometimes missed.

The Problem

Verifpal’s active attacker analysis works by systematically replacing wire values with attacker-controlled alternatives, then checking whether the attacker can derive secrets or forge messages. The search is staged: stage 1 tries single-value replacements, stage 2 tries pairs, and so on. For simple protocols, this works well.

But for protocols like Scuttlebutt, the brute-force search never terminates. The combinatorial space is too large, and the canonical attack, replacing an ephemeral DH public key with the attacker’s own, is buried in a haystack of useless mutations. The old Go verifier would run indefinitely on Scuttlebutt without ever finding the attack that any cryptographer would spot in minutes.

The Solution

Equation Bypass is a targeted analysis pass that runs before the general mutation loop. It directly models the most common class of active attack: replacing unguarded Diffie-Hellman public keys with the attacker’s own public key (G^nil, where nil is the attacker’s known private key).

The mechanism has four phases:

Replace. For each principal, collect all equation-valued wire inputs that are received from another principal and not guarded (not sent in [brackets]). Try replacing each one individually with G^nil, and also try replacing all of them simultaneously.

Identify bypassable guards. After replacement, resolve all values and attempt primitive rewrites. Guarded primitives (AEAD_DEC?, SIGNVERIF?) whose rewrite fails are collected. For each failed guard, extract the “bypass key”, the value the attacker would need to forge a valid input. For AEAD_DEC, that’s the decryption key. For SIGNVERIF with a public key G^sk, that’s the private key sk. If the attacker can obtain the bypass key, either because it’s already known or because it’s reconstructible from known values, the guard is bypassable.

Inject. For each bypassable guard, inject G^nil into the guard’s output slot. This injection must update all three state vectors (assigned, before_rewrite, and before_mutate) to ensure correct propagation through downstream computations. The injection iterates up to 5 times to handle cascading guards: bypassing one guard may change downstream keys enough to make a later guard bypassable.

Decompose. With the fully-resolved bypass state, attempt to decompose all wire-carried primitive values. For example, AEAD_ENC(key, plaintext, nil) where the attacker now knows the key yields the plaintext.

The Scuttlebutt Result

For Bob’s state in the Scuttlebutt protocol, replacing ephemeralAPub with G^nil causes a cascade:

Every shared secret Bob derives from Alice’s ephemeral key now uses G^nil, which the attacker knows.
The master secret derived from these shared secrets is reconstructible by the attacker.
The first AEAD_DEC guard fails, but the attacker knows the key, so G^nil is injected.
This propagates through the second AEAD_DEC guard, which also becomes bypassable.
The attacker decomposes both encrypted messages, learning m1 and m2.

All 9 security queries fail. The attack is found in seconds. The Go version would have run forever.

A Rich Terminal Interface

The Rust rewrite introduces a full-screen terminal user interface for live analysis visualization. When running with the --tui flag, Verifpal renders:

A protocol overview showing principals, their private/generated/computed values, and message flows
Live query status with pass/fail indicators updating in real time
Attacker activity tracking: current scan target, mutation weight, budget consumption, and last worthwhile mutations
Knowledge gain feed: newly deduced values color-coded by derivation method (decomposition, reconstruction, recomposition, equivalence, password guessing)
Contextual narrative text describing the attacker’s actions in natural language

The TUI uses an alternate screen buffer, hides the cursor, detects terminal width, and throttles redraws to 20fps to avoid flooding the terminal. All rendering uses 1-cell-wide Unicode characters (box drawing, block elements) for correct alignment across terminal emulators.

Character Modes

Because formal verification should be fun: the --character flag lets you switch the attacker’s narrative voice. The default is a clinical security analyst. But you can also run analysis as Jevil or Spamton from Deltarune, complete with character-appropriate commentary on every phase of the attack:

Jevil (on deduction): “UEE HEE HEE! A SECRET FALLS INTO MY TINY HANDS!”

Spamton (on mutation): “HEY Alice!! WANT SOME [[Slightly Used]] REPLACEMENT VALUES?? ONLY 3 [[Kromer]]!!”

Spamton (on query failure): “[[DEAL OF A LIFETIME]]!! YOUR PROTOCOL IS [[Bankrupt]]!!”

Expanded Test Suite

The Go version had 67 integration tests and no unit tests. The Rust version has 147 tests: 70 unit tests covering value equivalence, equation flattening, primitive handling, and other core operations, plus 77 integration tests running full protocol models.

Fifteen new protocol models were added, covering scenarios the old test suite never touched:

Double Ratchet (double_ratchet.vp): Signal-style DH ratcheting with alternating rounds and HKDF chain key derivation
Triple DH (triple_dh.vp): X3DH-style key agreement combining identity, signed, and ephemeral DH computations
Four-Party Relay (four_party.vp): Multi-hop message relay with cross-principal authentication and re-encryption
Phase Forward Secrecy (phase_forward_secrecy.vp): Ephemeral DH ensuring confidentiality survives long-term key compromise
PSK + DH (psk_with_dh.vp): TLS PSK+DHE-style hybrid key agreement with forward secrecy under PSK compromise
Key Ratchet (key_ratchet.vp): Symmetric HKDF chain key ratcheting across multiple messages
Shamir Reconstruction (shamir_reconstruction.vp): 2-of-3 threshold secret sharing with partial share leakage
Blind Signature (blind_signature.vp): Message blinding, blind signing, and signature unblinding
Deep Nesting (deep_nesting.vp): Five layers of nested encryption testing value resolution depth
Concat Bomb variants: Maximum-arity concatenation testing decomposition, equivalence, key leakage, and unchecked assertions
Many Principals (many_principals.vp): Broadcast signature verification across six recipients
Passive DH Chain (passive_dh_chain.vp): Three-hop relay testing chain-of-custody under passive attackers

These models test the protocol patterns that make up most real design work: ratcheting, multi-party flows, threshold cryptography, hybrid key agreement.

By the Numbers

	Go (v0.31.2)	Rust
Language	Go 1.22	Rust (2024 edition)
Source files	22	26
Lines of code	~7,100	~9,600
Dependencies	14 (go.sum: 562 lines)	3 (colored, clap, rayon)
Test count	67 integration	70 unit + 77 integration
Parser	Generated PEG	Hand-written recursive descent
Largest file	value.go (935 lines)	tui.rs (TUI, new feature)
Global mutable state	AttackerState + mutex	1 AtomicU32 (TUI counter)
Build	`go build`	`cargo build --release` (LTO, single codegen unit)

The Rust binary ships with fat link-time optimization, a single codegen unit, symbol stripping, and panic=abort, which together produce a compact, fully static binary with no runtime dependencies.

Getting Verifpal

Verifpal is available now:

Homebrew (Linux/macOS): brew install verifpal
Scoop (Windows): scoop install verifpal
Source: cargo build --release from the GitHub repository
Releases: Pre-built binaries for Windows, Linux, macOS, and FreeBSD on GitHub Releases

The Verifpal User Manual and the VS Code extension (syntax highlighting, live analysis, diagram visualizations) remain fully compatible with the Rust version.

This rewrite took weeks of careful work. Every test passes. Every protocol model produces identical results to the Go version, plus the new ones the Go version couldn’t handle. The codebase is smaller in spirit if not in line count: structured, typed, and tested in ways that weren’t possible before.

Security Announcement: Bugs in Noise Explorer's Rust/WASM Code Generation

Sun, 22 Feb 2026 00:00:00 +0000

Update (February 23, 2026): A second security advisory has been published: GHSA-q6mw-qh5x-m2p8. This advisory addresses four additional bugs across Go, Rust and WebAssembly code generation templates, including a truncated forbidden Curve25519 point value in Go, a panic-on-validation crash reachable by remote attackers in Go, a fixed-size buffer overflow enabling denial of service in Rust and WebAssembly, and a public key validation bypass in Rust and WebAssembly key generation. These issues are fixed in Noise Explorer v1.0.6. Users who have generated Go, Rust or WebAssembly implementations should regenerate their code using version 1.0.6 or later.

Noise Explorer is Symbolic Software’s online engine for reasoning about Noise Protocol Framework Handshake Patterns. It allows users to design Noise Handshake Patterns, generate formal verification models, explore pre-computed formal verification results, and generate secure software implementations in Go, Rust and WebAssembly.

We’ve updated Noise Explorer to address two bugs in its Rust and WebAssembly code generation templates. These bugs affected all Noise protocol implementations generated by Noise Explorer versions 1.0.4 and earlier. Users who have generated Rust or WebAssembly implementations using Noise Explorer should regenerate their code using version 1.0.5 or later.

A security advisory has been published: GHSA-6pc6-w328-gw8x.

Bug 1: Public Key Validation Bypass (Rust Only)

The first bug was located in the Rust code generation template (src/rs/1types.rs). The PublicKey::from_str() function bypassed small-order Curve25519 point validation, allowing an attacker to supply a low-order public key. A Diffie-Hellman operation with a small-order point produces a predictable all-zero shared secret, which could lead to a loss of message confidentiality.

This bug affected generated Rust implementations only. Go and WebAssembly implementations were not affected.

Bug 2: Incorrect Cipherstate Rekeying (Rust and WASM)

The second bug was located in the Rust and WebAssembly code generation templates (src/rs/6processes.rs and src/wasm/6processes.rs). The rekey_remote_cipherstate function incorrectly operated on the local cipherstate instead of the remote one. This caused desynchronization between peers: after a rekey operation, subsequent sent messages would use a doubly-rekeyed key, causing decryption failures on the receiving side.

This bug affected both generated Rust and WebAssembly implementations. Go implementations were not affected.

Unaffected Components

All Go implementations generated by Noise Explorer.
All ProVerif formal verification models generated by Noise Explorer.
WebAssembly implementations (for the public key validation bug only).

Impact

The public key validation bypass could allow an attacker to force a predictable shared secret, undermining the confidentiality of messages encrypted under the resulting session keys. The cipherstate rekeying bug would cause communication failures between peers after a rekey operation. Neither bug affected the correctness of Noise Explorer’s formal verification models.

Resolution

Both bugs have been fixed in Noise Explorer v1.0.5. The Rust code generation templates have also been upgraded to the Rust 2024 edition with updated dependencies.

Users who have previously generated Rust or WebAssembly Noise protocol implementations using Noise Explorer should regenerate their implementations using version 1.0.5 or later.

Acknowledgements

We thank Elichai Turkel for identifying both issues through code review of a generated Noise-KK Rust implementation.

Even More Bugs in CE Labs' libcrux: ML-DSA

Tue, 17 Feb 2026 00:00:00 +0000

Over the past two weeks, we have published eight vulnerabilities across CE Labs’ cryptographic libraries, including three bugs in formally verified code that CE Labs’ own documentation claims is correct.

We now report three additional findings in libcrux’s ML-DSA implementation, the post-quantum digital signature algorithm standardized as FIPS 204. The first two are FIPS 204 specification violations in runtime code. The third is a wrong specification in the F* formal verification infrastructure that renders AVX2 proofs unsound.

Update (Feb 19): Finding 3 added, an error in the ML-DSA AVX2 proof specification that makes the formally verified intrinsics axioms logically false.

Update (Mar 6): CE Labs has fixed Findings 1 and 2. Finding 1 (verifier norm check) was fixed in PR #1347, merged March 4, 2026. Finding 2 (hint deserialization) was fixed in PR #1348, merged March 4, 2026. Both PRs credit the discoverer.

Finding 1: ML-DSA Verifier Norm Check Is Dead Code

Location: libcrux-ml-dsa/src/ml_dsa_generic.rs, line 404.

The ML-DSA verifier checks whether the signer response vector $\mathbf{z}$ has an infinity norm below a certain bound. This is a critical security check: it ensures that $\mathbf{z}$ does not leak information about the secret key. FIPS 204, Algorithm 8 (ML-DSA.Verify_internal), step 13 specifies:

$$\text{return } \lVert\mathbf{z}\rVert_\infty < \gamma_1 - \beta \text{ and } \tilde{c} = \tilde{c}'$$

And Algorithm 7 (ML-DSA.Sign_internal), step 23 specifies:

$$\text{if } \lVert\mathbf{z}\rVert_\infty \geq \gamma_1 - \beta \text{ or } \lVert r_0\rVert_\infty \geq \gamma_2 - \beta \text{, then } (\mathbf{z}, \mathbf{h}) \leftarrow \bot$$

Both use $\gamma_1 - \beta$. The libcrux verifier uses the wrong bound:

// Line 402-405 (verifier, BUG):
if vector_infinity_norm_exceeds::<SIMDUnit>(
    &deserialized_signer_response,
    (2 << GAMMA1_EXPONENT) - BETA,
//   ^^^^^^^^^^^^^^^^^^^^^^^^ = 2·γ₁ - β
) {
    return Err(VerificationError::SignerResponseExceedsBoundError);
}

The expression 2 << GAMMA1_EXPONENT computes $2 \cdot 2^{\gamma_1\text{exp}} = 2\gamma_1$, not $\gamma_1$. Compare with the signer, which correctly uses 1 << GAMMA1_EXPONENT:

// Line 284 (signer, correct):
if vector_infinity_norm_exceeds::<SIMDUnit>(&mask, (1 << GAMMA1_EXPONENT) - BETA) {
//                                                  ^^^^^^^^^^^^^^^^^^^^^^^^ = γ₁ - β

The signer checks $\gamma_1 - \beta$. The verifier checks $2\gamma_1 - \beta$. One constant was doubled.

The Check Can Never Trigger

The signer response $\mathbf{z}$ is deserialized from a $\gamma_1$-encoded representation: each coefficient is encoded as a value in $[-\gamma_1, \gamma_1]$. This means that for any deserialized $\mathbf{z}$, $\lVert\mathbf{z}\rVert_\infty \leq \gamma_1$. The buggy bound is $2\gamma_1 - \beta$. Since $\beta > 0$:

$$\gamma_1 < 2\gamma_1 - \beta$$

The check vector_infinity_norm_exceeds(&deserialized_signer_response, (2 << GAMMA1_EXPONENT) - BETA) can never return true. The verifier’s norm check is dead code. For each ML-DSA parameter set:

Parameter Set	$\gamma_1$	$\beta$	Max $\lVert\mathbf{z}\rVert_\infty$	Buggy bound ($2\gamma_1 - \beta$)	Correct bound ($\gamma_1 - \beta$)
ML-DSA-44	$2^{17} = 131072$	78	131072	262066	130994
ML-DSA-65	$2^{19} = 524288$	196	524288	1048380	524092
ML-DSA-87	$2^{19} = 524288$	120	524288	1048456	524168

In every case, the maximum possible infinity norm ($\gamma_1$) is less than the buggy bound ($2\gamma_1 - \beta$). The check is vacuously true. The verifier unconditionally passes any deserialized signer response, regardless of whether it satisfies the FIPS 204 requirement $\lVert\mathbf{z}\rVert_\infty < \gamma_1 - \beta$.

Concrete Impact

A conforming signer will never produce a signature with $\lVert\mathbf{z}\rVert_\infty \geq \gamma_1 - \beta$, because the signing algorithm rejects such candidates and retries. But a malicious signer could produce signatures with $\gamma_1 - \beta \leq \lVert\mathbf{z}\rVert_\infty \leq \gamma_1$ that pass libcrux’s verifier but would be correctly rejected by any FIPS 204-conforming implementation.

This creates an interoperability hazard. A system using libcrux for verification would accept signatures that every other conforming implementation rejects:

Post-quantum certificate chains. A certificate authority or TLS implementation using libcrux to verify ML-DSA signatures on certificates would accept certificates that conforming verifiers reject. An attacker could issue a certificate that appears valid to libcrux-based systems but is rejected everywhere else, creating a split view of the PKI.
Firmware signing. A secure boot chain using libcrux for signature verification would accept firmware images signed with out-of-bound $\mathbf{z}$ vectors. A malicious firmware image could pass libcrux’s verification while being correctly rejected by any other FIPS 204-conforming verifier on the same device or in audit tooling.
Consensus protocols. In a distributed system where nodes verify ML-DSA signatures to reach agreement, libcrux nodes would accept messages that non-libcrux nodes reject. An adversary could exploit this to partition the network: libcrux nodes see a valid message, conforming nodes do not.

Provenance

Introduced in commit 326c837a33 on January 7, 2025, by Jonas Schneider-Bensch, with the message “Further macro monomorphization of parameter sets.” The signer’s correct bound was already present in the codebase. The verifier’s bound was written incorrectly in the same refactoring pass.

Finding 2: Hint Deserialization Missing Final Bound Check

Location: libcrux-ml-dsa/src/encoding/signature.rs, lines 91–120.

ML-DSA signatures contain a hint vector $\mathbf{h}$ that encodes which coefficients of the high-order bits need adjustment. The hint is serialized as a list of indices followed by cumulative counts, with a maximum of $\omega$ total true hints across all polynomials. FIPS 204, Algorithm 21 (HintBitUnpack), step 4 specifies, for every row $i$ from 0 to $k - 1$:

$$\text{if } y[\omega + i] < \text{Index} \text{ or } y[\omega + i] > \omega \text{ then return } \bot$$

This checks the current cumulative count $y[\omega + i]$ against $\omega$ on every iteration. It ensures that no row’s cumulative count exceeds the allowed maximum.

The libcrux implementation checks the wrong variable:

for i in 0..rows_in_a {
    let current_true_hints_seen = hint_serialized[max_ones_in_hint + i] as usize;

    if (current_true_hints_seen < previous_true_hints_seen)
        || (previous_true_hints_seen > max_ones_in_hint)
    //      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    //      Checks PREVIOUS iteration's count, not current.
    //      FIPS 204 checks: y[ω + i] > ω (i.e., current > max)
    {
        malformed_hint = true;
        break;
    }

    for j in previous_true_hints_seen..current_true_hints_seen {
        // ... process hint indices ...
        set_hint(out_hint, i, hint_serialized[j] as usize);
    }

    // ...
    previous_true_hints_seen = current_true_hints_seen;
}

The check uses previous_true_hints_seen > max_ones_in_hint instead of current_true_hints_seen > max_ones_in_hint. It validates the count from the previous iteration rather than the current one. For the last row (i = rows_in_a - 1), the current count is read, the hint indices are processed and applied via set_hint, and previous_true_hints_seen is updated, but the overflow check will not fire until the next iteration, which never comes.

The subsequent padding check (line 122) is supposed to verify that all remaining bytes in the hint section are zero:

for j in previous_true_hints_seen..max_ones_in_hint {
    if hint_serialized[j] != 0 {
        malformed_hint = true;
        break;
    }
}

But if previous_true_hints_seen equals or exceeds max_ones_in_hint after the last row, this range is empty and the loop body never executes. The padding check is silently skipped.

Concrete Impact

A crafted signature can set the last row’s cumulative count to a value greater than $\omega$ (max_ones_in_hint). The inner loop will then iterate over bytes in the trailer region of the hint encoding, interpreting arbitrary byte values as hint indices and setting corresponding positions via set_hint. For each parameter set:

Parameter Set	$\omega$ (`max_ones_in_hint`)	Rows ($k$)	Trailer bytes
ML-DSA-44	80	4	`hint_serialized[80..84]`
ML-DSA-65	55	6	`hint_serialized[55..61]`
ML-DSA-87	75	8	`hint_serialized[75..83]`

The trailer bytes are the cumulative count bytes for each row. An attacker controls these values as part of the signature. By setting the last row’s count to max_ones_in_hint + rows_in_a (or any value up to 255), the inner loop reads the trailer bytes as hint indices, setting arbitrary hint positions in the last polynomial. This produces a hint vector that a FIPS 204-conforming implementation would reject.

As with the verifier norm bound, this creates a divergence between libcrux and conforming implementations. A signature accepted by libcrux may be rejected elsewhere, or worse, the corrupted hint vector may cause the verification to produce a different result than intended:

Signature forgery assistance. The hint vector directly affects which high-order bits are adjusted during verification. By injecting arbitrary hint positions through the overflow, an attacker gains additional degrees of freedom in crafting signatures that pass verification. This weakens the effective security of the scheme by relaxing constraints that the signer is supposed to satisfy.
Cross-implementation disagreement. A signature with an overflowed hint count would verify successfully under libcrux but fail under any conforming implementation. In a system where multiple parties independently verify the same signature, such as a transparency log or a multi-verifier protocol, this produces contradictory verification results with no indication of which is correct.
Strong unforgeability violation. FIPS 204 mandates a unique hint encoding precisely to ensure strong unforgeability: each valid signature has exactly one valid serialization. The missing bound check allows multiple distinct serializations to decode to the same logical signature, breaking this property. An attacker can produce a second valid encoding of an existing signature without access to the signing key.

Provenance

The hint deserialization logic has been touched by multiple authors across several commits. The current loop structure was established by Jonas Schneider-Bensch in commit 83ffae727d on January 2, 2025, and further modified by Franziskus Kiefer (CE Labs’ CEO) in commit 404115bc08 on January 13, 2025. The early-return logic was later replaced with flag-and-break by Jonas Schneider-Bensch in commit d979b001f9 on November 17, 2025, as a workaround for a bug in Eurydice, with the comment: “We would like to use early returns below, but doing so triggers a bug in Eurydice.”

The workaround for Eurydice’s inability to handle early returns inside loops restructured the control flow in a way that obscured the missing final bound check. The original early-return code may or may not have had the same bug, but the flag-and-break rewrite made it harder to spot.

Finding 3: Wrong Multiplication Specification in ML-DSA AVX2 Proofs

Location: libcrux-ml-dsa/proofs/fstar/spec/Spec.Intrinsics.fsti, line 97.

The F* specification file Spec.Intrinsics.fsti defines the semantics of low-level AVX2 intrinsics used in the ML-DSA proof infrastructure. The function i16_mul_32extended specifies 16-to-32-bit widening multiplication, the primitive underlying Intel’s VPMADDWD and VPMULLW instructions. It takes two parameters x and y:

[@@ "opaque_to_smt"]
let i16_mul_32extended (x y: i16): i32 =
  (cast x <: i32) *! (cast x <: i32)
(*               ^^^ should be: cast y *)

The body uses x for both operands. The parameter y is completely ignored. The function computes $x^2$ instead of $x \cdot y$. This is likely a copy-paste error: cast x was duplicated instead of writing cast y for the second operand.

Why Formal Verification Cannot Catch This

Three mechanisms conspire to make this bug invisible to the F* proof system:

1. The definition is hidden from the solver. The [@@ "opaque_to_smt"] attribute on line 96 prevents Z3 from unfolding the function body. The solver never sees the x * x computation.

2. All lemmas are unproven axioms. The file contains approximately five val declarations that characterize i16_mul_32extended’s behavior: that multiplying by a power of two equals a left shift, for instance, or that multiplying by zero yields zero. These are stated as F* val declarations without bodies. No corresponding Spec.Intrinsics.fst implementation file exists. In F*, a val without a corresponding let in an implementation file is an axiom: the solver accepts it without proof. Every lemma about i16_mul_32extended is an article of faith.

3. The axioms claim correct $x \cdot y$ behavior. The axioms describe what the function should do (multiply x by y), not what it actually does (square x). Since the solver reasons from the axioms and never sees the definition, the contradiction is invisible. The axioms are logically false, but the solver has no way to discover this.

Impact Chain

The buggy function propagates through the specification:

i16_mul_32extended_i16 (line 99) calls i16_mul_32extended x y, inheriting the $x^2$ behavior.
mm256_madd_epi16_lemma (line 377) specifies AVX2’s VPMADDWD instruction using i16_mul_32extended. The claimed semantics are $a_{2k} \cdot b_{2k} + a_{2k+1} \cdot b_{2k+1}$; the actual definition computes $a_{2k}^2 + a_{2k+1}^2$, ignoring the second vector entirely.
mm256_mullo_epi16_bv_lemma (line 511) specifies AVX2’s VPMULLW via i16_mul_32extended_i16. Same issue: claims $a_i \cdot b_i$, computes $a_i^2$.

The ML-DSA build system’s Makefile lists nine AVX2 modules in VERIFIED_MODULES, including Simd.Avx2.Encoding.Error.fst, Simd.Avx2.Encoding.Commitment.fst, Simd.Avx2.Ntt.fst, and Simd.Avx2.Arithmetic.fst. These modules are designated for full verification against the axioms in Spec.Intrinsics.fsti. Any proofs built on these axioms inherit the unsoundness: the solver would accept incorrect code as correct, because it reasons from false premises.

Put plainly: every ML-DSA proof CE Labs will ever produce for their AVX2 backend, the backend that runs on every modern x86 server and desktop, rests on roughly forty axioms that are provably false. No amount of future verification effort fixes that until someone finds and corrects the wrong definition, which has been sitting in the file since the day it was committed.

What This Does Not Affect

The runtime Rust code is unaffected. The actual ML-DSA implementation uses real Intel AVX2 intrinsics (_mm256_madd_epi16, _mm256_mullo_epi16) that perform correct $x \cdot y$ multiplication in hardware. The F* specification is never compiled into runtime code. This bug cannot cause incorrect signatures or verification failures in deployed software.

The impact is on verification trustworthiness: the formal proofs that are supposed to guarantee correctness of the AVX2 code path are built on a false foundation. The proofs would say “this code is correct” regardless of whether it actually is, because the axioms they reason from do not match the operations they claim to model.

Structural Comparison

Findings 1 and 2 are runtime bugs in admitted (unverified) modules, which the verification system never looks at. Finding 3 is different: the bug is inside the verification infrastructure itself. The wrong specification was committed before the dependent proofs were written, establishing a false axiomatic foundation. Even running every proof with full solver dispatch would not catch it, because val declarations without implementations are accepted by F* as axioms unconditionally.

This is the same copy-paste pattern we have seen repeatedly: the ML-KEM decompression bug duplicated 1664 instead of writing pow2 (d-1), and the false serialization proof duplicated bound 1 instead of writing bound 12. Here, cast x was duplicated instead of writing cast y.

Provenance

Introduced in commit cb165295de on May 21, 2025, by Lucas Franceschino, with the message “F*: mldsa: avx2: encoding: commitment.” The function was added as part of the ML-DSA AVX2 proof infrastructure. The bug has been present since the function’s introduction.

The Pattern Continues

These three findings bring the total to eleven vulnerabilities across CE Labs’ cryptographic libraries in two weeks. The pattern we identified in our original post and paper remains consistent: bugs cluster in code that is unverified or lax-verified, while the marketing claims make no such distinction.

Findings 1 and 2 are in ML-DSA’s core verification path, the code that determines whether a digital signature is valid. Both are straightforward deviations from FIPS 204 that a careful comparison against the specification would catch. Both reside in modules that are admitted by default in the build system, meaning that even if someone wrote formal specifications for them, the proofs would not be checked.

Finding 3 reveals a different failure mode: the bug is not in admitted code but in the verification specification itself. The axiomatic foundation for AVX2 proofs contains a wrong definition hidden behind an opacity barrier, with unproven lemmas that claim correct behavior. That is not a gap in verification coverage. It is a corruption of the verification infrastructure.

The ML-DSA Makefile makes the verification boundary explicit. Twenty-seven modules are in VERIFIED_MODULES: SIMD arithmetic, NTT, encoding primitives, and type definitions. Everything else is in ADMIT_MODULES, including the top-level signing and verification logic, signature encoding, and key generation. The verified modules are the leaves. The roots are unverified. And as Finding 3 shows, even the verified leaves rest on unproven axioms.

CE Labs’ response to our previous findings was to claim that “no bugs have been found in the verified code.” We showed that this was false. Finding 3 reinforces this: the specification that the verified code is checked against is itself wrong. When the axioms are false, “verified” is an empty word.

Formal verification is supposed to provide assurance that goes beyond testing. But assurance requires that the verification boundary be communicated honestly. When a library is marketed as “formally verified” and “high assurance,” users reasonably expect that the core cryptographic operations, meaning signing, verification and key generation, are within that boundary. In libcrux’s ML-DSA, they are not. And even within that boundary, the axiomatic foundations have not been proved. Anyone who cited CE Labs’ verification claims to justify deploying libcrux ML-DSA where signature correctness carries legal or contractual weight was relying on a foundation whose specification for multiplication computes the wrong operation.

We Found Bugs in CE Labs' Verified Code

Thu, 12 Feb 2026 00:00:00 +0000

On February 5, we published five new vulnerabilities in CE Labs’ libcrux, hpke-rs, and libcrux-psq cryptographic libraries, along with a paper analyzing the structural pattern behind them. CE Labs’ response was to block our GitHub account, close our pull requests containing working fixes, and accuse us of acting in bad faith.

One week later, on February 12, CE Labs published a 1,570-word response titled “The strengths and limits of formal verification.” In it, they write:

So far, no bugs have been found in the verified code, although we would be very interested to know if any of our code generation tools inadvertently introduced a bug, and even more interested if the bug should have been caught by formal verification.

We are happy to oblige. We forked libcrux and found three bugs in the verified code: two in the ML-KEM mathematical specification itself, and one in a correctness proof that CE Labs’ documentation claims is complete.

What CE Labs’ Response Left Out

Before we get to the bugs, look at what CE Labs chose to address and what they chose to ignore. Their 1,570-word response acknowledged, obliquely, two of six vulnerabilities (one reported not by us, in November 2025):

V1 (platform-dependent cryptographic output failure): described as “a fallback implementation for a platform-specific intrinsic.”
V5 (Ed25519 double clamping): described as “one in an unverified wrapper around HACL* code.”

What they did not mention, in 1,570 words ostensibly about the strengths and limits of their verification methodology:

V3: Nonce reuse via integer overflow. A u32 sequence counter in hpke-rs that silently wraps to zero in release builds, reusing AEAD nonces. For AES-GCM, nonce reuse leaks the GHASH authentication key, enabling universal forgeries. For ChaCha20-Poly1305, it enables direct plaintext recovery. Not one word.
V6: Denial of service via .unwrap(). A single malformed ciphertext crashes the process in the PSQ protocol’s AES-GCM decryption path. Breaks IND-CCA security for 9 of 18 supported PSQ ciphersuites. The correct error handling code was present but commented out. Not one word.
V2: Missing X25519 all-zero validation. An attacker can supply a low-order public key and force the HPKE shared secret to zero, making session keys deterministic and predictable. Forward secrecy completely broken. Not one word.
V4: ECDSA signature malleability. The ECDSA P-256 implementation lacks low-S normalization, a standard requirement for over a decade. Not one word.

The word “hpke-rs” does not appear anywhere in CE Labs’ response. This is the library that implements RFC 9180, the one depended upon by Signal’s signal-crypto crate and by OpenMLS. Its two most severe vulnerabilities, nonce reuse and broken forward secrecy, were simply not mentioned.

CE Labs wrote 1,570 words about “the strengths and limits of formal verification” without acknowledging four of the six vulnerabilities, including the two most dangerous ones.

Four days after blocking our account and closing our pull requests, CE Labs’ CEO manually copied our fixes and merged them under his own name. The fixes that were characterized as “not a good-faith attempt to improve the project’s security posture” were adopted verbatim.

Bugs in the Verified Code

With that context, let us return to CE Labs’ invitation. They said they would be “very interested” if someone found a bug that should have been caught by formal verification. We forked libcrux and looked.

We found three.

Bug 1: Wrong Specification for ML-KEM Decompression

The F* specification function decompress_d in Spec.MLKEM.Math.fst (line 238) uses the wrong rounding constant. This is not a proof-level issue. This is the mathematical specification itself, the correctness target for the entire ML-KEM decompression pipeline, computing the wrong function.

let decompress_d (d: dT {d <> 12}) (x: field_element_d d): field_element
  = let r = (x * v v_FIELD_MODULUS + 1664) / pow2 d in
    r                            -- ^^^^ should be: pow2 (d - 1)

When rounding integer division by $N$, the correct procedure is to add $N/2$ before dividing. For decompress_d, the denominator is $2^d$, so the rounding constant should be $2^{d-1}$. The value $1664 = (q-1)/2$ is the correct rounding constant for the compress_d function directly above it, which divides by $q = 3329$. The author used 1664 for both functions.

Compare with compress_d (line 225), where 1664 is correct:

let compress_d (d: dT {d <> 12}) (x: field_element): field_element_d d
  = let r = (pow2 d * x + 1664) / v v_FIELD_MODULUS in
    ...                  -- ^^^^ correct here: dividing by q, so add q/2 = 1664

The pattern is clear. For compress_d, $N = q = 3329$, so $N/2 = 1664$. For decompress_d, $N = 2^d$, so $N/2 = 2^{d-1}$. One constant was copied to both.

Concrete Counterexamples

FIPS 203 defines $\text{Decompress}_d(y) = \text{round}\!\left(\frac{q}{2^d} \cdot y\right)$, implemented as $\left\lfloor\frac{q \cdot y + 2^{d-1}}{2^d}\right\rfloor$.

d	x	Spec (wrong: 1664)	Correct ($2^{d-1}$)	FIPS 203
1	0	832	0	0
1	1	2496	1665	1665
4	0	104	0	0
4	1	312	208	208
10	0	1	0	0
10	1	4	3	3

The spec gives decompress_d(d, 0) != 0 for $d < 12$. Decompressing zero should always yield zero. The spec and FIPS 203 disagree on every input for $d \in \{1, 4, 5, 10, 11\}$.

The Implementation Is Correct; the Spec Is Wrong

Libcrux’s own Rust implementation (libcrux-ml-kem/src/vector/portable/compress.rs, line 317) uses the correct formula:

let mut decompressed = a.elements[i].as_i32() * FIELD_MODULUS.classify().as_i32();
decompressed = (decompressed << 1) + (1i32 << COEFFICIENT_BITS);
decompressed = decompressed >> (COEFFICIENT_BITS + 1);

This computes $(x \cdot q + 2^{d-1}) / 2^d$, the correct rounding. The CRYSTALS-Kyber reference implementation in C uses the same correct formula. The implementation is right. The specification is wrong. They disagree.

Why It Goes Undetected

The spec function decompress_d is the correctness target for the entire decompression pipeline. It is called via byte_decode_then_decompress (line 270), which feeds into decode_then_decompress_message ($d=1$), decode_then_decompress_u ($d=d_u$), and decode_then_decompress_v ($d=d_v$), which together cover every decompression path in ML-KEM encryption and decryption.

The implementation’s ensures clauses in ind_cpa.rs reference these spec functions. But Libcrux_ml_kem.Ind_cpa.fst is in ADMIT_MODULES (line 4 of the extraction Makefile), so the proof that the implementation matches the spec is admitted and the mismatch is never checked. Meanwhile, verification_status.md claims ind_cpa is yes/yes/yes.

Provenance and Impact

Introduced in commit c1935b9cf8 on August 12, 2024, by Karthikeyan Bhargavan (CE Labs’ Chief Research Scientist and corresponding author of their response post), with the commit message “spec”. This was the very first version of the ML-KEM specification file. The bug has been present since inception.

This is a specification-level bug. The formal specification, the mathematical reference that correctness proofs are verified against, computes a different function than FIPS 203. Even if all proofs were completed and fully verified, they would prove the implementation correct against the wrong mathematical definition. The overall claim “ML-KEM implementation is correct with respect to FIPS 203” is undermined at the foundation.

The fix is to change 1664 to pow2 (d - 1) on line 238:

 let decompress_d (d: dT {d <> 12}) (x: field_element_d d): field_element
-  = let r = (x * v v_FIELD_MODULUS + 1664) / pow2 d in
+  = let r = (x * v v_FIELD_MODULUS + pow2 (d - 1)) / pow2 d in
     r

Bug 2: Missing Inverse NTT in ML-KEM Encryption Specification

The F* specification function ind_cpa_encrypt_unpacked in Spec.MLKEM.fst (line 277) computes the ciphertext component v by adding an NTT-domain polynomial directly to coefficient-domain polynomials, without first applying the inverse NTT. This is a domain mismatch, the mathematical equivalent of adding a frequency-domain signal to a time-domain signal. The Rust implementation correctly applies invert_ntt_montgomery before the addition.

FIPS 203, Algorithm 14 (K-PKE.Encrypt), specifies two structurally identical computations:

$$\text{Step 19:} \quad \mathbf{u} \leftarrow \text{NTT}^{-1}(\hat{\mathbf{A}}^T \circ \hat{\mathbf{y}}) + \mathbf{e}_1$$$$\text{Step 21:} \quad \mathbf{v} \leftarrow \text{NTT}^{-1}(\hat{\mathbf{t}}^T \circ \hat{\mathbf{y}}) + \mathbf{e}_2 + \mu$$

Both require $\text{NTT}^{-1}$ on the NTT-domain product before adding coefficient-domain error terms. The specification implements step 19 correctly but omits $\text{NTT}^{-1}$ from step 21:

-- Line 275 (u, correct):
let u = vector_add (vector_inv_ntt (matrix_vector_mul_ntt ...)) error_1
                     ^^^^^^^^^^^^^^
                     NTT⁻¹ applied

-- Line 277 (v, BUG):
let v = poly_add (poly_add (vector_dot_product_ntt t_as_ntt r_as_ntt) error_2) mu
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                             Returns NTT-domain. Missing: poly_inv_ntt

The operand domains confirm the mismatch. vector_dot_product_ntt computes $\hat{\mathbf{t}}^T \circ \hat{\mathbf{y}}$ via pointwise NTT-domain multiplication and summation (vector_sum (vector_mul_ntt a b), line 185), returning an NTT-domain polynomial. Meanwhile, error_2 (from sample_poly_cbd2, line 165, which is CBD sampling with no NTT) and mu (from decode_then_decompress_message, line 212, byte decode and decompress) are both in the coefficient domain. The spec adds them directly.

The decryption specification, thirty lines below, performs the same operation correctly:

-- Line 307 (decryption, correct):
let w = poly_sub v (poly_inv_ntt (vector_dot_product_ntt secret_as_ntt (vector_ntt u)))
                     ^^^^^^^^^^^^^^
                     NTT⁻¹ applied

The Implementation Is Correct; the Spec Is Wrong

The Rust implementation in libcrux-ml-kem/src/matrix.rs (line 77) has a correct English comment:

/// Compute InverseNTT(tᵀ ◦ r̂) + e₂ + message

And the code (lines 99–105) correctly applies the inverse NTT before the addition:

for i in 0..K {
    let product = t_as_ntt[i].ntt_multiply(&r_as_ntt[i]);
    result.add_to_ring_element::<K>(&product);
}
invert_ntt_montgomery::<K, Vector>(&mut result);    // NTT⁻¹ applied correctly
result = error_2.add_message_error_reduce(message, result);

But its F* postcondition (line 88) matches the buggy spec, not the correct implementation:

res_spec == Spec.MLKEM.(poly_add (poly_add (vector_dot_product_ntt ...) e2_spec) m_spec)
--                                          ^^^ Missing poly_inv_ntt

The programmer knew what the code should do. The English is right, the implementation is right, but the formal annotation is wrong.

Why It Goes Undetected

The function compute_ring_element_v is marked verification_status(lax) (line 79 of matrix.rs), so its postcondition is only lax-checked, not proven. And Libcrux_ml_kem.Ind_cpa.fst is in ADMIT_MODULES, so the linking proof between the implementation and the specification is fully admitted.

Provenance and Impact

This bug was introduced in the same commit as Bug 1: c1935b9cf8 on August 12, 2024, the initial creation of the ML-KEM specification file by Karthikeyan Bhargavan.

This is a specification-level bug in ML-KEM encryption. The NTT representation of a polynomial is a completely different sequence of 256 field elements than its coefficient representation. Adding them directly produces a result that is neither the correct NTT-domain nor coefficient-domain value, so the spec computes a ciphertext v that differs from what FIPS 203 prescribes for virtually all inputs. Both the u computation (line 275) and the decryption (line 307) correctly apply the inverse NTT, making this an inconsistency within the specification itself.

The fix is to add poly_inv_ntt on line 277:

-    let v = poly_add (poly_add (vector_dot_product_ntt t_as_ntt r_as_ntt) error_2) mu in
+    let v = poly_add (poly_add (poly_inv_ntt (vector_dot_product_ntt t_as_ntt r_as_ntt)) error_2) mu in

Bug 3: False Proof in ML-KEM Serialization

The F* lemma deserialize_12_bit_vec_lemma_bounded in libcrux-ml-kem/src/vector/portable/serialize.rs (line 691) claims that all elements produced by deserialize_12 are bounded by 1, meaning they fit in a single bit. This is mathematically false. The deserialize_12 function extracts 12-bit values from a byte array; its outputs range from 0 to 4095. The bound should be 12.

let deserialize_12_bit_vec_lemma_bounded (v: t_Array u8 (sz 24))
  : squash (
    let result = ${deserialize_12} v in
    (forall (i: nat {i < 16}).
      Rust_primitives.bounded (Seq.index result.f_elements i) 1)
                                                               ^
  ) =                                      should be 12, not 1
 _ by (Tactics.GetBit.prove_bit_vector_equality' ())

This is not a subtle semantic question. The lemma asserts that a function producing 12-bit values only ever produces values that fit in 1 bit. It is a false mathematical statement embedded in a proof that CE Labs’ own documentation claims is complete.

The interface-level lemma deserialize_12_lemma (line 706) correctly states the bound as 12. But it calls deserialize_12_bit_vec_lemma_bounded to discharge its proof obligation, so the entire correctness proof for deserialize_12 rests on a false statement:

let deserialize_12_lemma inputs =
  deserialize_12_bit_vec_lemma inputs;
  deserialize_12_bit_vec_lemma_bounded inputs;   <-- false lemma
  BitVecEq.bit_vec_equal_intro ...

A Copy-Paste Bug

Every other deserializer in the same file has the correct bound. The 1 was copied from deserialize_1 and never updated:

Lemma	Bound	Correct?
`deserialize_1_bit_vec_lemma` (line 108)	1	Yes
`deserialize_4_bit_vec_lemma_bounded` (line 274)	4	Yes
`deserialize_10_bit_vec_lemma_bounded` (line 478)	10	Yes
`deserialize_12_bit_vec_lemma_bounded` (line 691)	1	No

The bug was introduced in commit 5f6e3c2083 on March 25, 2025, by a CE Labs developer, with the commit message: “fix(ml-kem): deserialize_10/12: remove admit.” The commit replaced admit() calls with dedicated bounded lemmas. The deserialize_10 version was added correctly with bound 10. The deserialize_12 version was copy-pasted from deserialize_1 with the bound left as 1. The irony of a commit titled “remove admit” introducing a false proof should not be lost.

Three Layers of Silent Failure

The false lemma goes undetected because three independent mechanisms conspire to prevent it from ever being checked:

1. “Slow modules” are admitted by default. In fstar-helpers/Makefile.base:

VERIFY_SLOW_MODULES ?= no
ifeq (${VERIFY_SLOW_MODULES},no)
    ADMIT_MODULES += ${SLOW_MODULES}

The portable serialize module is listed in SLOW_MODULES. When VERIFY_SLOW_MODULES is no, which is the default, the module is added to ADMIT_MODULES and verified with --admit_smt_queries true, which accepts all SMT proofs without checking them.

2. The proof tactic has a lax-mode escape hatch. In fstar-helpers/fstar-bitvec/Tactics.GetBit.fst:

let prove_bit_vector_equality' (): Tac unit =
  if lax_on ()
  then iterAll tadmit
  else prove_bit_vector_equality'' ()

When the module is lax-checked, the tactic calls tadmit on all goals unconditionally, bypassing the actual bit-vector equality prover entirely. The false lemma is never subjected to any mathematical scrutiny.

3. Full verification is never triggered. A search of the entire libcrux repository finds that VERIFY_SLOW_MODULES=yes is never set in any CI configuration, Makefile target, or script. The proof is never actually checked in any automated pipeline.

The Documentation Says “Yes”

Meanwhile, CE Labs’ own verification_status.md claims the portable serialize module is fully verified:

Category	File	Lax Checking	Runtime Safety	Correctness
Portable	serialize	yes	yes	yes

Three “yes” entries. Full verification claimed for lax checking, runtime safety, and correctness.

But the file’s own header comment says:

//! Verification status: Lax

And the build system admits the module by default. So we have three sources that contradict each other:

Source	Claimed status
`verification_status.md`	Fully verified (yes / yes / yes)
File header comment	Lax
Actual build configuration	Admitted by default

The code that CE Labs documents as formally verified for correctness contains a false mathematical statement that is silently accepted because the proof is never actually checked.

The fix is to change 1 to 12 on line 691:

 let deserialize_12_bit_vec_lemma_bounded (v: t_Array u8 (sz 24))
   : squash (
     let result = ${deserialize_12} v in
-    (forall (i: nat {i < 16}). Rust_primitives.bounded (Seq.index result.f_elements i) 1)
+    (forall (i: nat {i < 16}). Rust_primitives.bounded (Seq.index result.f_elements i) 12)
   ) =
  _ by (Tactics.GetBit.prove_bit_vector_equality' ())

What This Means

CE Labs invited scrutiny of their verified code. We accepted the invitation, and it took one fork and a careful read to find:

A wrong mathematical specification for ML-KEM decompression, the correctness target the entire verification effort is built on top of. It disagrees with FIPS 203 on every input and has been wrong since the spec file was first created, authored by CE Labs’ Chief Research Scientist himself.
A missing inverse NTT in the ML-KEM encryption specification, which adds an NTT-domain polynomial to coefficient-domain polynomials. This is mathematically nonsensical, and it was introduced in the same commit by the same author.
A false proof annotation in ML-KEM’s portable serialization that claims 12-bit values fit in 1 bit, silently accepted by a build system that defaults to not checking proofs.

All three bugs survive for the same structural reason: the modules that would expose them are admitted by default. The proofs are never checked. The documentation says “yes” when the answer is “no.”

CE Labs’ response to our original findings was to block us, close our fixes, and then quietly adopt them. Their public response acknowledged two of six vulnerabilities and ignored the four most severe. Their verification status documentation claims that code is verified when it is not. Their proof infrastructure silently admits false mathematical statements rather than checking them. And their mathematical specification, the foundation on which every correctness claim rests, computes a different function than the standard it claims to formalize, in two independent places.

The formal verification methodology that CE Labs markets as providing “the highest level of assurance” contains a build system that defaults to not checking proofs, a tactic library that silently accepts all claims in lax mode, specifications that disagree with the standards they model, and documentation that says “yes” when the answer is “no.” The result is a formally verified cryptographic library where wrong specifications and false proofs survive indefinitely because nobody, and no automated system, ever actually verifies them.

We continue to believe that formal verification is a valuable technique when applied honestly and communicated precisely. What we object to is the gap between what is claimed and what is delivered. That gap is not a limitation of formal methods. It is a choice.

Verifpal Verifies Signal Across Three Messages

Tue, 10 Feb 2026 00:00:00 +0000

Today we’re releasing Verifpal 0.31.2, the biggest upgrade to Verifpal’s analysis engine we’ve ever shipped. The headline result: Verifpal can now fully verify a model of Signal’s X3DH key agreement and Double Ratchet protocol across three messages, under an active attacker, and it terminates in minutes. No earlier version of Verifpal could complete this analysis.

The verified models are published on VerifHub:

This isn’t a novel research result: I myself analyzed a similar Signal model using ProVerif back in 2016, a full decade ago. Tools like ProVerif and Tamarin have been able to handle models of this complexity for years.

But Verifpal was never built to compete with ProVerif or Tamarin. It was built as a learning tool, accessible to undergraduates and first-year graduate students who are encountering protocol verification for the first time. What matters is that Verifpal can now handle models complex enough to be pedagogically interesting, and Signal is the canonical example.

What the Models Show

The Signal model captures the full three-message flow: X3DH key agreement followed by two rounds of Double Ratchet.

Message 1 (Bob → Alice): Pre-key bundle. Bob publishes his long-term identity key, a signed semi-static pre-key, and a one-time pre-key. Alice verifies the signature and computes a master secret from the four Diffie-Hellman computations at the core of X3DH.

Message 2 (Alice → Bob): Initial ciphertext. Alice derives chain and message keys via HKDF, then encrypts her first message using AEAD with associated data binding both parties’ identity keys and her current ephemeral key.

Message 3 (Bob → Alice) and Message 4 (Alice → Bob): Double Ratchet. Each subsequent message introduces a new ephemeral key, performs a DH ratchet step, and derives fresh encryption keys through the HKDF-MAC chain.

After all messages are exchanged, the model enters a post-compromise phase where both Alice’s and Bob’s long-term private keys are leaked, testing forward secrecy.

Guarded Model Results

In the guarded model, long-term identity keys are distributed over an authenticated channel (denoted by [brackets] in Verifpal syntax, meaning the active attacker cannot substitute them):

Query	Result
`confidentiality? m1`	Pass
`authentication? Alice -> Bob: e1`	Fail
`confidentiality? m2`	Pass
`authentication? Bob -> Alice: e2`	Pass
`confidentiality? m3`	Pass
`authentication? Alice -> Bob: e3`	Pass

Five of six queries pass. The single failure, authentication of Alice’s first message to Bob, is a well-known property of the X3DH handshake. Because X3DH is designed for asynchronous messaging (Bob may be offline when Alice initiates), Alice’s first message cannot be fully authenticated until Bob responds and the ratchet completes a full round-trip. This is documented in the Signal specification and is not a vulnerability; it’s an inherent tradeoff of the asynchronous design.

All three confidentiality queries pass even after long-term key compromise, confirming that the protocol provides forward secrecy.

Unguarded Model Results

In the unguarded model, long-term identity keys are sent over an unauthenticated channel, allowing the active attacker to substitute them:

Query	Result
`confidentiality? m1`	Fail
`authentication? Alice -> Bob: e1`	Fail
`confidentiality? m2`	Fail
`authentication? Bob -> Alice: e2`	Fail
`confidentiality? m3`	Fail
`authentication? Alice -> Bob: e3`	Fail

All six queries fail. When an active attacker can man-in-the-middle both parties’ long-term identity keys, every security property collapses, confidentiality and authentication alike, across all three messages. This is the expected and correct result: without an authenticated channel for identity key distribution, no amount of cryptographic ratcheting can save you.

Why Verifpal Couldn’t Do This Before

Verifpal’s active attacker analysis works by systematically mutating protocol values to candidate replacements drawn from the attacker’s knowledge. For each mutation combination, the engine checks whether the attacker can derive secrets, forge messages, or break authentication. The problem is combinatorial: as models grow in complexity, the number of mutation combinations explodes.

Two sources of explosion were responsible for non-termination on the Signal model:

Mutation Map Cartesian Product Explosion

The mutation map associates each mutable constant with a list of candidate replacement values. Previously, the verifier enumerated the full cartesian product of all mutation lists simultaneously. For a model where four constants have mutation lists of sizes [2, 7, 7, 527], the full product is 51,646 combinations, each spawning a goroutine. At higher analysis stages, where injection expands these lists further, the product grows into the hundreds of thousands.

Injection Cartesian Product Explosion

The injection engine constructs candidate primitive values by combining known values into each argument slot. For a three-argument primitive like AEAD_ENC where the attacker knows 20+ values per slot, the cartesian product can exceed 8,000 injected values, per primitive, per stage, per principal.

Together, these two explosions caused the verifier to spawn millions of goroutines on the Signal model, leading to memory exhaustion, goroutine stack overflow, or effective non-termination.

The Fixes

Weight-Ordered Mutation Scanning

The core architectural change replaces brute-force cartesian product enumeration with a weight-ordered scanning strategy that explores mutations in layers of increasing complexity.

Injection cap: a hard limit of 500 injected values per primitive (maxInjectionsPerPrimitive). The injection loop now pre-computes the total product size with overflow-safe arithmetic and breaks early once the cap is reached. This prevents memory exhaustion from a single inject() call while preserving enough injection diversity for attack discovery.

Mutation map subsetting: two new functions, mutationMapSubset and mutationMapSubsetCapped, let the scanner extract and budget-constrain subsets of the full mutation map. When a subset’s product exceeds the cap, each dimension is truncated to the nth root of the limit (computed via binary search), distributing the budget evenly across dimensions.

Weight-ordered scanning: the new verifyActiveScanWeighted function replaces direct cartesian product enumeration.

Weight 1: Each mutable variable is tested alone, capped to 50 mutations per variable. This catches attacks that require substituting only a single value.
Weight 2: Each pair of variables is tested simultaneously. Pairs whose product exceeds 20,000 are skipped entirely (not truncated), preserving the combinatorial structure of pairs that fit.
Weight 3: Each triple of variables, same skip logic.
Full product: Only attempted if the total product across all variables is within 50,000.

A per-principal-per-stage scan budget of 20,000 (tracked via atomic counter) prevents any single stage from consuming unbounded work. At most 50 subsets are scanned per weight level, preventing combinatorial blowup in C(n, k) when the number of mutable variables is large.

The maximum stage limit was also reduced from 64 to 8, ensuring the verifier declares exhaustion sooner when higher stages stop discovering new knowledge. That matters for multi-phase models, where phase 0 must exhaust before phase 1 analysis can begin.

Lock-Free Concurrency and Hash-Based Lookups

The second fix targeted performance bottlenecks in the multithreaded analysis engine.

Lock-free attacker state snapshots. The attacker state, the central data structure tracking everything the attacker knows, was previously guarded by a read-write mutex that became a bottleneck under high concurrency. The new implementation uses atomic.Pointer[AttackerState] to publish immutable snapshots on every write. Read-side operations (attackerStateGetRead, attackerStateGetExhausted, attackerStateGetKnownCount) now try the snapshot first, avoiding the read lock entirely. Write-side operations use optimistic double-checked locking: check under read lock, then acquire write lock only if necessary.

Hash-based O(1) value lookups. The valueEquivalentValueInValues function, which checks whether a value already exists in the attacker’s known set, was a linear scan called in every hot path. It’s now replaced by valueEquivalentValueInValuesMap, backed by an FNV-like hash map (map[uint64][]int). Dedicated hashers handle primitives, equations, and constants, with special handling for the commutativity of three-element DH equations. The attacker state’s KnownMap is maintained alongside the known values list and included in atomic snapshots.

Principal state clone optimization. constructPrincipalStateClone previously deep-copied every slice in the principal state. Since several slices (Constants, Guard, Known, Wire, KnownBy, DeclaredAt, MutatableTo, Phase) are immutable after initialization, they’re now shared by reference.

Parallel stage execution. Analysis stages now run two at a time when possible, improving throughput on multi-core machines.

AEAD Check Semantics and the Final Bug

The last release fixed a subtle bug in how checked AEAD primitives were interpreted. In Verifpal, AEAD_DEC(k, c, ad)? (with the ? suffix) means the decryption is checked: the principal verifies that decryption succeeded and aborts if it doesn’t. Without the ?, the principal blindly accepts whatever comes out.

The authentication and freshness query handlers were not correctly distinguishing between checked and unchecked AEAD decryptions, causing incorrect pass/fail indices. The fix adds an early-continue path for non-checked primitives in queryAuthenticationGetPassIndices and queryFreshness.

The Signal model itself was also corrected: three AEAD_DEC calls that should have been checked (with ?) were missing the suffix, masking authentication failures that the analysis should have detected.

This was the fix that made the Signal model terminate with correct results.

What This Means for Verifpal

Once more, before academics try to strangle me (again): verifying Signal is not new. ProVerif could do this in 2016. Tamarin can do it. CryptoVerif can do it. Verifpal reaching this milestone in 2026 is not a claim of parity with these tools.

What it is, is a claim of relevance. Verifpal is used in university classrooms to teach protocol verification to students who have never seen a formal method before. When a student asks “can we model Signal?”, the answer is no longer “not in Verifpal.” That matters.

The performance improvements also benefit every other Verifpal model. Analysis that previously timed out or exhausted memory will now terminate. Models with multi-argument primitives and complex key derivation chains, the bread and butter of real-world protocols, are now within reach.

Verifpal 0.31.2 is available now. You can install it via Homebrew, Scoop, or download it directly from verifpal.com.

On the Promises of 'High-Assurance' Cryptography

Thu, 05 Feb 2026 00:00:00 +0000

Update (March 7, 2026): A fifth finding has been added to this post: a denial-of-service vulnerability in libcrux-psq’s AES-GCM decryption path (Finding 5), discovered after the original publication.

CE Labs is a company that markets itself as providing “services and software for high assurance software in order to establish trust into your critical systems.” Their flagship product, libcrux, is billed as a cryptographic library that “has been formally verified” and offers “the highest level of assurance”, translating into that it is safe to use and free of bugs.

In the past two days, we at Symbolic Software have submitted four pull requests to CE Labs’ repositories addressing security vulnerabilities and implementation defects. These findings follow an incident from late 2025 in which libcrux produced silently incorrect cryptographic outputs on certain platforms: a bug that CE Labs addressed quietly, without any public disclosure, and which only received a security advisory because third parties took it upon themselves to file one.

Taken together, these events raise the question of what “high assurance cryptography” actually means, and whether the formal verification community has developed a habit of overpromising and underdelivering.

The Original Incident: Platform-Dependent Cryptographic Failures

In November 2025, Filippo Valsorda reported that libcrux-ml-dsa v0.0.3 produced different outputs depending on the execution environment. The same seed input generated different public keys and signatures on Alpine Linux with Ampere Altra ARM64 hardware compared to macOS on Apple Silicon. This was not an edge case in error handling or a performance regression. This was the core cryptographic functionality producing incorrect results.

The bug resided in an unverified fallback implementation for the vxarq_u64 intrinsic. On platforms lacking native SHA-3 instruction support, the fallback passed incorrect arguments, corrupting SHA-3 digests and causing downstream cryptographic operations to fail silently. Any system relying on this code for ML-DSA signatures or ML-KEM key exchange would have experienced authentication failures or key agreement mismatches, depending on which platform generated the cryptographic material.

CE Labs fixed the bug. What they did not do was issue any public disclosure, security advisory, or acknowledgment that their “formally verified” library had shipped with a defect that caused silent cryptographic failures in production environments.

The Burial

The only security advisory that exists for this vulnerability was not initiated by CE Labs. It was filed by Joe Birr-Pixton (ctz) in the RustSec advisory database, a third-party effort to document the vulnerability for the Rust ecosystem. The advisory was merged on December 4, 2025.

When CE Labs’ maintainer engaged with the advisory process, they requested that the advisory target libcrux-intrinsics, an internal dependency, rather than the user-facing libcrux-ml-kem or libcrux-ml-dsa crates. While technically accurate (the bug originated in the intrinsics crate), this framing minimizes the user-visible impact. Most developers who depend on libcrux-ml-kem do not monitor advisories for transitive dependencies; targeting the advisory at the internal crate reduces the likelihood that affected users will learn of it through automated tools like cargo audit.

This framing is technically accurate and practically misleading. The intrinsics crate is an internal dependency of libcrux-ml-kem and libcrux-ml-dsa. Users of those libraries experienced corrupted cryptographic operations. The distinction between “the intrinsic layer had a bug” and “the cryptographic library produced wrong outputs” matters to CE Labs’ marketing narrative but not to anyone whose systems were affected.

CE Labs themselves made absolutely no announcement anywhere regarding the bug. There was no blog post. No security bulletin. No announcement on any CE Labs communication channel. No email to known users of the library. The RustSec advisory, which most developers will never see unless they actively run cargo audit, represents the entirety of CE Labs’ disclosure posture for a bug that caused their formally verified cryptographic library to produce incorrect outputs.

Compare this to how other cryptographic library maintainers handle similar situations. When the Kyber reference implementation contained a variable timing vulnerability in late 2023, it was the subject of extensive public discussion, a dedicated tracking website (KyberSlash), and advisories from affected downstream implementations. When we discovered the same vulnerability in our own Kyber-K2SO implementation, we issued a public security announcement within 24 hours; we were among the first to do so.

CE Labs’ approach was to fix the bug, avoid any public acknowledgment, and wait for someone else to file an advisory in an obscure database.

Five New Findings

Between February 3 and February 4, 2026, we identified four additional issues in CE Labs’ cryptographic libraries, with a fifth discovered subsequently. These range from specification non-compliance to entropy reduction to potential nonce reuse to denial of service.

1. Missing X25519 All-Zero Validation (hpke-rs)

Pull request #117 addresses a missing validation required by RFC 9180, the HPKE specification. Section 7.1.4 of the RFC mandates that implementations “MUST check whether the Diffie-Hellman shared secret is the all-zero value and abort if so.”

The X25519 function, when given certain low-order points as input (such as the identity element or points of small order), produces an all-zero output. If an attacker can supply a malicious public key, they can force the shared secret to be zero, making the subsequent key derivation deterministic and predictable.

This vulnerability concerns an explicit requirement in the specification that the implementation claimed to follow. The fix is trivial: a single comparison after the DH computation. Its absence indicates that either the specification was not read carefully or the requirement was deprioritized.

2. Nonce Reuse via Sequence Number Overflow (hpke-rs)

Pull request #118 addresses a flaw in how HPKE sequence numbers are managed. The library stores the sequence number as a u32, which has a maximum value of approximately 4.3 billion. RFC 9180 specifies that the sequence number must be checked against 2^96 - 1 for standard 12-byte nonces.

The overflow check in the original code compared a u32 against a value that a u32 can never reach. In debug builds, Rust’s overflow checking would cause a panic when the counter wrapped. In release builds, which are the builds that actually run in production, the counter would silently wrap to zero, reusing nonces.

Nonce reuse in authenticated encryption is catastrophic. For AES-GCM, it enables recovery of the authentication key and XOR of plaintexts. For ChaCha20-Poly1305, it directly enables plaintext recovery through XOR attacks. Any application encrypting more than 4.3 billion messages with the same HPKE context would be vulnerable.

The fix is one line: replace + with checked_add(). The fact that this was not already the implementation suggests that the security implications of integer overflow in cryptographic contexts were not adequately considered.

3. ECDSA Signature Malleability (libcrux)

Pull request #1315 addresses signature malleability in the ECDSA P-256 implementation. For any valid ECDSA signature (r, s), there exists an alternative valid signature (r, n - s), where n is the curve order. Without low-S normalization, which constrains s to be at most n/2, signatures are malleable: an attacker can produce alternative valid signatures without knowing the private key.

This matters in practice. Bitcoin’s BIP 62 and BIP 146 mandate low-S normalization because signature malleability can alter transaction identifiers, potentially enabling theft and breaking transaction chains. More generally, any system that uses signatures for deduplication, audit trails, or caching can be confused by malleable signatures.

The libcrux implementation validates that r and s are nonzero but does not compare s against n/2 or apply normalization. This is a well-known requirement that has been standard practice in ECDSA implementations for over a decade.

4. Ed25519 Double Clamping (libcrux)

Pull request #1316 addresses an unnecessary entropy reduction in Ed25519 key generation. The generate_key_pair function was applying scalar clamping operations to the raw seed before hashing:

sk[0] &= 248u8;
sk[31] &= 127u8;
sk[31] |= 64u8;

According to RFC 8032, clamping should occur after SHA-512 hashing of the seed, not before. Applying these operations to the raw seed removes 5 bits of entropy (3 from the first byte, 2 from the last), reducing the effective key space from 256 bits to 251 bits.

While 251 bits remains computationally secure against brute force, there is no benefit to this reduction. The SHA-512 hash produces a uniformly distributed output regardless of input patterns; clamping the input serves no cryptographic purpose. It only reduces entropy without providing any compensating advantage.

This is not a subtle issue. The Ed25519 specification is explicit about when clamping occurs. Implementing it incorrectly suggests either that the specification was not consulted or that its requirements were misunderstood.

5. Denial of Service via AES-GCM Decryption Panic (libcrux-psq)

The libcrux-psq crate implements a post-quantum pre-shared-key protocol. In the decrypt_out method, the AES-GCM 128 decryption path calls .unwrap() on the decryption result instead of propagating the error. A single malformed ciphertext crashes the process.

AEADKey::AesGcm128(key) => {
    libcrux_aesgcm::AesGcm128::decrypt(
        plaintext, key, &self.nonce,
        aad, ciphertext, tag,
    )
    .unwrap();
    // .map_err(|_| AEADError::CryptoError)?;
}

The correct error handling is commented out directly below the .unwrap() call. Beyond the denial-of-service impact, this defect renders the PSQ implementation not IND-CCA secure: the IND-CCA security game requires a decryption oracle that returns ⊥ on invalid ciphertexts, but a panicking implementation terminates execution instead, making the decryption oracle unavailable after the first invalid query.

The verified AES-GCM primitive correctly returns an error on authentication failure. The unverified wrapper discards it. The fix is a one-line change: replace .unwrap() with the error propagation that was already written and commented out.

What Does This Tell Us About “High Assurance Cryptography”?

The formal verification community has developed a vocabulary for marketing that systematically overstates what verification actually accomplishes. When CE Labs claims their library is “formally verified” and “free of bugs,” they are making statements that their own bug history contradicts.

The November 2025 incident is instructive. The bug was in an ARM SIMD intrinsic fallback, precisely the kind of low-level, platform-specific code that formal verification tools cannot reason about. Formal verification in practice means verifying an abstract model, then trusting that the compiler, the intrinsics, the runtime, and the hardware all faithfully implement that model.

This is not verification in the sense that users understand the term. It is verification of a Rust model, plus hope that LLVM generates correct code, plus hope that the ARM instruction set behaves as documented, plus hope that every CPU implementation thereof is free of errata, plus hope that the operating system, memory allocator, and runtime environment introduce no observable differences.

The honest description would be: “We have verified portions of our Rust code against certain properties using the hax toolchain. The actual security of deployed systems depends on your compiler version, target architecture, CPU microcode, operating system, and numerous other components we cannot verify.” But that does not sell. It does not win grants. It does not attract customers.

Instead, we get “formally verified” as a marketing term, a way to claim superiority over libraries that rely on extensive testing, fuzzing, cross-platform validation, and code review. Those are the engineering practices that might have caught the platform-dependent output bug before it shipped.

The five new findings reinforce this pattern. None of them involve subtle interactions between verified and unverified code. They are straightforward implementation defects:

A specification requirement that was ignored (X25519 zero check).
An integer type that was too small for its purpose (sequence number overflow).
A normalization step that was omitted (ECDSA low-S).
A clamping operation that was applied at the wrong point (Ed25519 double clamping).
A verified primitive’s error discarded by an unverified wrapper (AES-GCM decryption panic).

These are not the kinds of bugs that formal verification is designed to catch. They are the kinds of bugs that careful code review, thorough testing, and attention to specifications would catch. They suggest that the development process prioritized the verifiable core over the engineering fundamentals that surround it.

The Verification Theater Problem

There is a pattern in the formal methods community that might be called “verification theater”: the deployment of formal methods in ways that create the appearance of rigor without delivering its substance.

A cryptographic library that is “formally verified” but ships with platform-dependent incorrect outputs has not achieved high assurance. It has achieved a verified core surrounded by an unverified periphery that can fail in ways that make the verification meaningless.

A company that fixes critical bugs without disclosure has not demonstrated trustworthiness. It has demonstrated that marketing concerns outweigh transparency obligations.

A codebase that lacks basic specification compliance, such as checking for all-zero DH outputs, preventing integer overflow, and normalizing signatures, has not been developed with the care that “highest level of assurance” implies.

The formal verification community needs to develop more honest communication practices. Verification is valuable. It catches certain classes of bugs that testing cannot. But it is not a substitute for engineering discipline, and claiming otherwise undermines both the credibility of formal methods and the security of users who trust those claims.

When a formally verified cryptographic library produces platform-dependent incorrect outputs for its core primitive, and that library’s maintainers bury the disclosure while continuing to market the library as “free of bugs,” we must ask: free of which bugs, verified against which properties, and trustworthy to whom?

The answers, in CE Labs’ case, appear to be: not the bugs that matter, not the properties users care about, and not to anyone paying close attention.

Announcing Cedarcrypt: Applied Cryptography in the Mediterranean

Tue, 03 Feb 2026 00:00:00 +0000

Come be part of Cedarcrypt, our new initiative to grow cryptography research, development and representation in the Levant region.

Cryptography’s major conferences meet in a handful of the same cities every year, and researchers from the Levant are rarely in the room. We want to fix that.

What is Cedarcrypt?

This July 13-16, 2026, we’re bringing together researchers, practitioners, and students at the American University of Beirut’s Mediterraneo campus in Paphos, Cyprus, for four days of lectures, workshops and talks. Secure messaging, post-quantum cryptography, zero-knowledge proofs, formal verification: if it counts as applied cryptography, it belongs at Cedarcrypt.

Cedarcrypt exists to show that cryptography work comes out of our region too. We want a place where the next generation of cryptographers from the Levant and beyond can learn from established experts, present their own research, and meet the people they will be working with for the rest of their careers.

Call for Submissions

We need you to make this happen. We’re seeking:

Workshop leaders to teach hands-on skills.
Lecturers to cover both the foundations and the newest work.
Researchers to present their latest results.

Senior professors and first-year PhD students are equally welcome to submit.

We’re particularly interested in work on secure messaging protocols and the problems of running private communication systems at scale, and in post-quantum cryptography as the community works through the migration. Zero-knowledge proofs and their applications in privacy-preserving systems are another focus.

We also want submissions on formal verification of cryptographic implementations, on secure implementation practices, and on privacy technologies more broadly. If your work touches on how cryptography is built, deployed, or analyzed in practice, we want to hear from you.

Submit your proposal!

The Venue

Paphos is a UNESCO World Heritage city on the southwest coast of Cyprus, with beaches and a good deal of archaeology. The AUB Mediterraneo campus is in the city itself, and most major European cities have direct flights.

Get Involved

This is the first edition, and we intend to run it every year. Come help us get it right.

Visit cedarcrypt.org to learn more and submit your proposal.

Kyber-K2SO 1.0: Now Implementing ML-KEM

Sun, 21 Dec 2025 00:00:00 +0000

Kyber-K2SO is Symbolic Software’s clean Go implementation of the post-quantum key encapsulation mechanism that won the NIST post-quantum cryptography competition. Today, we’re releasing version 1.0, which upgrades the implementation from Kyber v3 to ML-KEM (FIPS 203), the official NIST standard finalized in August 2024.

Why ML-KEM?

While Kyber was the competition submission, ML-KEM is the standardized version. The two are closely related but not identical. ML-KEM incorporates refinements based on years of cryptanalysis and implementation feedback. Most importantly, ML-KEM is the version that will be widely deployed in protocols like TLS 1.3 and other security-critical applications.

By upgrading to ML-KEM, Kyber-K2SO ensures interoperability with other conforming implementations and alignment with the official NIST standard.

What’s New in Version 1.0

ML-KEM (FIPS 203) Compliance

The core implementation now follows the FIPS 203 specification. We’ve replaced the old Kyber v3 test vectors with the official ML-KEM test vectors from C2SP/CCTV, which are the reference intermediate test vectors for FIPS 203 compliance testing:

func TestMLKEM768Vector(t *testing.T) {
	dkBytes, err := hex.DecodeString(mlkem768TestVector.dk)
	if err != nil {
		t.Fatal(err)
	}
	cBytes, err := hex.DecodeString(mlkem768TestVector.c)
	if err != nil {
		t.Fatal(err)
	}
	expectedK, err := hex.DecodeString(mlkem768TestVector.K)
	if err != nil {
		t.Fatal(err)
	}

	var dk [Kyber768SKBytes]byte
	var c [Kyber768CTBytes]byte
	copy(dk[:], dkBytes)
	copy(c[:], cBytes)

	K, err := KemDecrypt768(c, dk)
	if err != nil {
		t.Fatal(err)
	}

	if subtle.ConstantTimeCompare(K[:], expectedK) == 0 {
		t.Errorf("ML-KEM-768 test vector failed\nExpected: %x\nGot: %x", expectedK, K[:])
	}
}

All three security levels pass their respective test vectors: ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

Best-Effort Secret Zeroization

Cryptographic implementations should clear sensitive data from memory as soon as it’s no longer needed. Version 1.0 introduces systematic zeroization of secrets and intermediate values throughout the KEM operations:

// byteopsZeroBytes zeroes a byte slice to clear sensitive data from memory.
func byteopsZeroBytes(b []byte) {
	for i := range b {
		b[i] = 0
	}
}

This function is now called after encryption and decryption operations to clear intermediate values like the message hash, key derivation inputs, and the implicit rejection key:

func KemEncrypt768(publicKey [Kyber768PKBytes]byte) (
	[Kyber768CTBytes]byte, [KyberSSBytes]byte, error,
) {
	// ... encryption logic ...

	byteopsZeroBytes(d[:])
	byteopsZeroBytes(m[:])
	byteopsZeroBytes(krInput[:])
	byteopsZeroBytes(kr[:])
	return ciphertextFixedLength, sharedSecretFixedLength, err
}

Additionally, if random number generation fails during key generation, the partially-constructed private key is now explicitly zeroed before returning an error:

_, err = rand.Read(privateKeyFixedLength[skStart:])
if err != nil {
	for i := range privateKeyFixedLength {
		privateKeyFixedLength[i] = 0
	}
	return privateKeyFixedLength, publicKeyFixedLength, err
}

We call this “best-effort” because Go’s garbage collector and compiler optimizations may still leave copies of sensitive data in memory. However, explicit zeroization remains a valuable defense-in-depth measure.

Defense in Depth: Bounded Rejection Sampling

The matrix generation routine uses rejection sampling to uniformly sample polynomial coefficients. While the probability of needing more than one iteration is astronomically low (approximately 10^-82), version 1.0 adds an explicit iteration bound as a safety measure:

r[i][j], ctr = indcpaRejUniform(buf[:504], 504, paramsN)
// Retry with remaining buffer bytes if needed
// Bound iterations as a safety measure (probability of needing >1 iteration is ~10^-82)
for iterations := 0; ctr < paramsN && iterations < 100; iterations++ {
	missing, ctrn := indcpaRejUniform(buf[504:], 168, paramsN-ctr)
	for k := ctr; k < paramsN; k++ {
		r[i][j][k] = missing[k-ctr]
	}
	ctr += ctrn
}

This prevents any theoretical infinite loop scenario, even though such a scenario is practically impossible with a correctly functioning random number generator.

Performance Improvements

Version 1.0 includes several performance optimizations that reduce heap allocations and improve efficiency:

Fixed-size arrays instead of slices: Internal buffers are now declared as fixed-size arrays where possible, reducing pressure on the garbage collector:

// Before
buf := make([]byte, 672)

// After
var buf [672]byte

Pre-computed Barrett reduction constant: The Barrett reduction now uses a pre-computed constant rather than computing it at runtime:

// Before
var v int16 = int16(((uint32(1) << 26) + uint32(paramsQ/2)) / uint32(paramsQ))
t = int16(int32(v) * int32(a) >> 26)

// After
t := int16((int32(paramsBarrettV) * int32(a)) >> 26)

Streamlined key construction: Private key assembly now uses direct copy operations into the fixed-length output array, eliminating intermediate slice allocations:

// Before
privateKey := append(indcpaPrivateKey, indcpaPublicKey...)
privateKey = append(privateKey, pkh[:]...)
privateKey = append(privateKey, rnd...)
copy(privateKeyFixedLength[:], privateKey)

// After
skStart := copy(privateKeyFixedLength[:], indcpaPrivateKey)
skStart += copy(privateKeyFixedLength[skStart:], indcpaPublicKey)
skStart += copy(privateKeyFixedLength[skStart:], pkh[:])
_, err = rand.Read(privateKeyFixedLength[skStart:])

These changes result in measurably faster operations across all security levels.

Code Quality Improvements

The polynomial type definition has been corrected to use the semantically appropriate constant:

// Before
type poly [paramsPolyBytes]int16

// After
type poly [paramsN]int16

Since paramsN (256) represents the polynomial degree and is the actual dimension of coefficient arrays, this change makes the code more self-documenting without affecting functionality.

Upgrading

To upgrade to version 1.0:

go get -u github.com/symbolicsoft/kyber-k2so

The API remains unchanged. If you were previously using Kyber-K2SO with Kyber v3, your code will continue to work without modification. However, the key material and ciphertexts are now ML-KEM format, which means they are not interoperable with Kyber v3 implementations.

Acknowledgements

We thank the C2SP project for maintaining the official test vectors that made compliance testing straightforward.

2PC-MPC in Rust: Audit Report

Tue, 04 Jun 2024 00:00:00 +0000

→ Download Full Report (PDF)

At Symbolic Software, we recently concluded, in close collaboration with 3MI Labs, an extensive audit of the 2PC-MPC Rust crate developed by dWallet Labs. We’re excited to share our findings and offer our perspectives on the strengths and areas for improvement of this innovative protocol implementation.

dWallet Labs’ 2PC-MPC crate represents a practical software implementation of the “2PC-MPC: Emulating Two Party ECDSA in Large-Scale MPC” protocol. This novel cryptographic structure enables a non-collusive and UC-secure two-party ECDSA scheme, allowing one party to be fully centralized while abstracting away the decentralization of the second party, enabling it to scale to an arbitrary number of virtual parties.

Audit Methodology and Focus Areas

Our audit covered the following aspects:

Functional Correctness Assessment: We verified that the implementation of the protocol in the 2PC-MPC crate aligns with the specifications outlined in the accompanying paper. This included ensuring that the cryptographic operations are correctly implemented and that the protocol’s security properties are maintained.
Security Assessment: We evaluated the security of the 2PC-MPC crate and its underlying crates, examining them for potential vulnerabilities that could compromise the security of the protocol. This included assessing the crates for common cryptographic vulnerabilities and ensuring their adherence to secure implementation best practices.

Key Findings and Recommendations

Functional Correctness: The implementation generally aligns with the protocol specifications, with the cryptographic operations and protocol steps being correctly realized in the Rust code. However, due to the high complexity of the target, further analysis is recommended to ensure complete functional correctness.
Security: We identified three main security findings of varying severity levels, including one critical issue of nonce reuse in the decentralized party presigning step.
Code Complexity: The high complexity of the Rust implementation can make the codebase challenging to understand, maintain, and audit. We recommend strategies such as code simplification, comprehensive documentation, rigorous testing, and regular security audits to address this issue.

In addition, Symbolic Software provided a roadmap for future work that proposes several avenues for further exploration and development to enhance the protocol’s security, efficiency, and usability. These include an in-depth cryptographic review, cryptographic optimizations, protocol API correctness and usability analysis, state machine transition analysis, understanding the decentralized party in a protocol setting, performance and scalability testing, integration with existing systems and frameworks, and real-world applications and case studies.

Read the Report

→ Download Full Report (PDF)

Symbolic Software would like to thank Erik Takke and Tomer Ashur from 3MI Labs for their collaboration and support throughout the assessment process. We appreciate their expertise, insights, and dedication to advancing the field of secure multi-party computation. We would also like to extend our sincere thanks to Yehonathan Cohen Scaly and Dolev Mutzari of dWallet Labs for their valuable contributions and feedback on the assessment findings. Their expertise and feedback have been instrumental in enhancing the quality and accuracy of the assessment results.

Security Announcement: Variable Timing Issue in Kyber Code

Tue, 19 Dec 2023 00:00:00 +0000

Update (December 30, 2023): Additional potential variable timing issues were found and subsequently fixed.

Kyber-K2SO is Symbolic Software’s clean implementation of the Kyber IND-CCA2-secure key encapsulation mechanism (KEM), whose security is based on the hardness of solving the learning-with-errors (LWE) problem over module lattices. Kyber was recently chosen as the winning candidate algorithm of those submitted to the NIST post-quantum cryptography project.

We’ve updated Kyber-K2SO to address a variable timing logic vulnerability. This vulnerability also existed in the original Kyber reference implementation and continues to exist in many third-party implementations.

We’re proud to be among the first third-party implementations to patch the issue, and the first vendor to issue an actual security advisory. Our implemented fix is available for review on the Kyber-K2SO GitHub repository.

Background

The vulnerability was discovered by the CE Labs team two weeks ago and reported directly to the Kyber team, whereupon it was patched in the official Kyber reference implementation.

Despite fixing the issue, the Kyber team chose not to release an advisory. This lack of an advisory from the Kyber team meant that third-party implementations such as ours were not made aware of the vulnerability’s existence.

On December 16, roughly two weeks later, we were made aware of the vulnerability’s existence through a GitHub issue opened in the Kyber-K2SO repository by the CE Labs team. On December 17, we additionally received an independent email notification from Prof. Daniel J. Bernstein (who had later independently rediscovered the issue) notifying us of the vulnerability.

We then issued an update containing a software patch within 24 hours. Users are asked to update to Kyber-K2SO version 0.2.2 (or higher) to benefit from our fix for this issue.

The Vulnerability

The variable timing logic arises from how the original implementation divides by Q in the decapsulation function, as seen below in Kyber-K2SO’s original code:

// polyToMsg converts a polynomial to a 32-byte message
// and represents the inverse of polyFromMsg.
func polyToMsg(a poly) []byte {
  msg := make([]byte, paramsSymBytes)
  var t uint16
  a = polyCSubQ(a)
  for i := 0; i < paramsN/8; i++ {
    msg[i] = 0
    for j := 0; j < 8; j++ {
      // NOTE: the following assignment is responsible
      // for the variable timing issue, through the
      // division by paramsQ.
      t = (
        ((uint16(a[8*i+j]) << 1) + uint16(paramsQ/2))
        / uint16(paramsQ)
      ) & 1
      msg[i] |= byte(t << j)
    }
  }
  return msg
}

As seen below, this vulnerability was also present in the reference C Kyber code:

for(i=0;i<KYBER_N/8;i++) {
  msg[i] = 0;
  for(j=0;j<8;j++) {
    t  = a->coeffs[8*i+j];
    t += ((int16_t)t >> 15) & KYBER_Q;
    t  = (((t << 1) + KYBER_Q/2)/KYBER_Q) & 1;
    // Irrelevant code snipped
  }

It is unclear whether this division will be compiled into a multiplication instruction, depending on compiler optimizations. As noted by Goutam Tamvada, we can see that the output of some C compilers indeed produces a division instruction even when strong optimizations are specified:

Should a division instruction be emitted, its execution time would likely be variable and leak information about its secret input.

Most Implementations Affected

Even if you do not use Kyber-K2SO, there is a strong chance that your chosen Kyber implementation suffers from the same variable timing vulnerability. The KyberSlash website is currently tracking which libraries are vulnerable and which have issued patches or security advisories.

Impact

As far as we can tell, the impact of this vulnerability is the same as any standard variable timing vulnerability in low-level asymmetric cryptographic primitives: real-world impact can vary dramatically depending on practical use cases. However, in the worst case scenario, secret key information leakage could be possible. Therefore, we encourage everyone to examine their chosen Kyber implementations to ensure that they are protected from this issue.

Acknowledgements

We thank Goutam Tamvada, Karthikeyan Bhargavan, Franziskus Kiefer, Prof. Daniel J. Bernstein and Prof. Peter Schwabe for their valuable feedback regarding this issue.

Supporting Real World Crypto 2024

Wed, 01 Nov 2023 00:00:00 +0000

We are pleased to announce that Symbolic Software is once again sponsoring the IACR Real World Cryptography symposium for its 2024 edition. This marks the sixth consecutive year of our association with this esteemed event, and we couldn’t be prouder.

The IACR Real World Cryptography symposium is a significant event in the cryptography community. It brings together researchers, practitioners, and industry experts to discuss the latest advancements, challenges, and practical applications of cryptographic techniques in the real world. Over the years, the symposium has been a platform for groundbreaking research, fostering collaborations, and promoting the importance of cryptography in ensuring a safer digital world.

Through supporting the IACR Real World Cryptography symposium, we hope to concretely demonstrate Symbolic Software’s commitment to advancing the field of cryptography. We believe in the power of collaboration and the importance of bridging the gap between theory and practice. By supporting this symposium, we aim to contribute to the growth of the cryptographic community and the broader goal of enhancing digital security.

We would like to extend our gratitude to the organizers of the IACR Real World Cryptography symposium for their tireless efforts in making this event a success year after year. We also want to acknowledge the participants, speakers, and attendees who bring their expertise, insights, and enthusiasm, making the symposium a vibrant and enriching experience.

As we look forward to the 2024 edition, we invite everyone to join us in celebrating the advancements in real-world cryptography. Let’s continue to work together, share knowledge, and drive innovation in this crucial field.

Thank you for your continued support and trust in Symbolic Software. We hope to see you at the IACR Real World Cryptography symposium in 2024!

Address to French Law Enforcement Officials

Fri, 29 Sep 2023 00:00:00 +0000

In a recent address to top French law enforcement officials, directors, ambassadors, and foreign dignitaries, Nadim Kobeissi, the director of Symbolic Software, a French cryptography expertise company, delved deep into the pressing topic of Internet surveillance law in France. The speech, which we are pleased to share in its entirety below, critically examines the current trajectory of French legislative proposals concerning digital privacy, encryption, and cybersecurity.

The speech aimed to use technical expertise in order to challenge the prevailing narratives and highlight the potential pitfalls of certain regulatory approaches. From the fundamental right to encryption to the potential dangers of turning smartphones into surveillance tools, the speech offers a comprehensive overview of the challenges and opportunities presented by the digital age.

As you read, we invite you to reflect on the balance between security and individual rights, the importance of informed legislation, and the broader implications of the choices we make today for the future of the digital world in France.

The speech is available below in its original French:

Au cours des dernières années, nous avons assisté à une évolution majeure de l’approche réglementaire de l’Union européenne concernant l’Internet et les technologies personnelles. De nombreuses propositions ont vu le jour, certaines d’entre elles suscitant de vives inquiétudes quant à leur applicabilité, leur efficacité et leur respect des droits fondamentaux.

Je suis ici pour souligner qu’une grande partie de l’élan qui sous-tend cette législation est mal informée. Ce n’est pas parce que je veux moins de réglementation, parce que je déteste les règles, ou quoi que ce soit de ce genre. C’est simplement parce que, du point de vue d’un expert technique en sécurité numérique et en cryptographie, la France essaie de réglementer l’ère numérique d’une manière qui me fait penser qu’elle réglementerait également les voitures en excès de vitesse en exigeant que toutes les roues soient dorénavant en béton.

Mais plus que tout, je tiens à souligner l’importance cruciale d’élargir le débat : je ne suis pas ici pour critiquer juste pour critiquer. Je ne suis pas là pour faire un récital de poésie sur les “droits de l’homme” sans tenir compte des situations graves et souvent très laides auxquelles des professionnels comme par exemple monsieur le général de la gendarmerie doivent faire face en permanence. Je suis ici parce que l’establishment français aborde parfois certains sujets profondément importants avec ce que l’on peut, en toute justice, décrire comme des réactions de panique ou une simple paresse intellectuelle, et qui, par conséquent, ne font qu’affaiblir la confiance du public dans les institutions de l’État, tout en ne contribuant guère à résoudre les questions de sécurité et d’ordre public.

Droit au chiffrement

Le chiffrement est aujourd’hui un droit fondamental. Il est essentiel pour garantir la confidentialité des communications et protéger les citoyens contre la surveillance de masse. Chiffrer ses communications est une pratique courante qui garantit que nos échanges ne soient lus que par leurs destinataires légitimes. C’est une extension de notre droit à la vie privée, protégé par l’article 8 de la Convention européenne des droits de l’homme. Cette pratique est adoptée par diverses professions, des militants aux journalistes, en passant par les avocats et les médecins, et est popularisée par des applications comme WhatsApp ou Signal.

Cependant, dans une affaire récente dans laquelle 7 personnes ont été mises en examen pour « association de malfaiteurs terroristes » en décembre 2020, La DGSI a publié un communiqué dans lequel elle attribue l’utilisation de Tor, une technologie de navigation privée sur Internet, comme étant un signe de “comportements clandestins”. Un juge chargé de l’affaire a en outre déclaré que l’utilisation de l’application de messagerie populaire Signal, ainsi que l’utilisation d’ordinateurs portables ou de téléphones chiffrés, constituaient des motifs de comportement suspect et potentiellement criminel.

Après leurs arrestations, les mis en examen sont, comme noté par La Quadrature du Net, systématiquement questionnés sur leur utilisation des outils de chiffrement et sommés de se justifier : « Utilisez-vous des messageries cryptées comme WhatsApp, Signal, Telegram, ou ProtonMail? », « Pour vos données personnelles, utilisez-vous un système de chiffrement ? », « Pourquoi utilisez-vous ce genre d’applications de chiffrement et d’anonymisation sur internet ? ». Le lien supposé entre chiffrement et criminalité est clair: au total, on dénombre plus de 150 questions liées aux pratiques numériques.

Il est extrêmement important de noter ce qui suit :

Signal est une application de messagerie qui compte des millions d’utilisateurs dans le monde et qui a été largement financée par les fondateurs de WhatsApp. La technologie de chiffrement de Signal est exactement la même que celle utilisée par WhatsApp. Des milliards de personnes utilisent quotidiennement Signal et WhatsApp.
Tous les iPhone, téléphones Samsung et téléphones Google chiffrent par défaut toutes les données stockées localement. Tous les ordinateurs portables Mac sont livrés avec une fonction de chiffrement prête à l’emploi, appelée FileVault, et tous les ordinateurs portables Windows de qualité professionnelle sont livrés avec une fonction de chiffrement de disque équivalente, appelée BitLocker.

Il est très important que tout le monde ici se rende compte que ce genre de réflexion, de la part des législateurs, ne fait que signaler aux citoyens français que les institutions gouvernementales sont incompétentes et qu’elles ne sont pas dignes de confiance. Aucun criminel n’est arrêté de cette manière, aucune sécurité n’est appliquée de cette manière. C’est un spectacle qui réduit la confiance du public dans les institutions que beaucoup d’entre vous représentent ici, et qui ne présente aucun avantage. Ces actions semblent suggérer que la protection de la vie privée est synonyme de comportement suspect ou clandestin. Cette perspective est non seulement erronée, mais elle est également dangereuse, car elle risque de dissuader les citoyens d’utiliser des outils essentiels pour protéger leurs données personnelles.

Le plus ironique (et le plus drôle), c’est que la plupart des cybercriminels n’ont pas vraiment besoin de se préoccuper d’utiliser le chiffrement pour commencer ! Une grande partie de la cybercriminalité en France aujourd’hui est en fait réalisée par le biais de choses comme ces faux SMS que tout le monde ici a sûrement reçus, qui vous demandent de payer une fausse amende ou de suivre un faux colis Amazon. Beaucoup de ces SMS proviennent de centres de données en Moldavie, et certains pourraient en fait faire partie d’initiatives parrainées par des États étrangers pour saper la cybersécurité civile française à grande échelle.

Projet de loi SREN

Le Projet de loi visant à sécuriser et réguler l’espace numérique (dit SREN) est un autre exemple frappant des défis auxquels nous sommes confrontés en matière de réglementation de l’Internet. Ce projet de loi, qui vise à réguler les contenus en ligne, semble ignorer la réalité complexe et nuancée de l’espace numérique. Par exemple, il est proposé d’obliger les plateformes à conserver les messages éphémères échangés, une mesure qui pourrait avoir des implications profondes pour la vie privée des utilisateurs.

De plus, la proposition du projet de loi SREN d’intégrer un code de censure directement dans les navigateurs web est particulièrement alarmante. Mandater l’intégration d’un code spécifique dans tous les principaux navigateurs web est une idée qui, à première vue, peut sembler séduisante pour certains régulateurs souhaitant exercer un contrôle sur l’espace numérique. Cependant, une telle proposition est non seulement techniquement irréalisable, mais elle est aussi profondément problématique sur le plan éthique et pratique. Les navigateurs web, en tant que portails d’accès à l’Internet, sont conçus pour être neutres, offrant aux utilisateurs la liberté de naviguer et d’accéder à l’information sans entrave. Imposer un code gouvernemental dans ces navigateurs reviendrait à compromettre cette neutralité fondamentale, transformant des outils d’accès libre en instruments de surveillance ou de censure.

De plus, l’idée de mandater un code dans tous les navigateurs majeurs sous-estime la diversité et la complexité de l’écosystème des navigateurs. Avec une multitude de navigateurs disponibles, allant des géants comme Google Chrome, Mozilla Firefox, Microsoft Edge ou Apple Safari à des alternatives plus spécialisées et open-source, l’application uniforme d’un tel mandat serait un cauchemar logistique. Sans parler des implications en matière de sécurité : introduire un code gouvernemental pourrait créer des vulnérabilités, exposant potentiellement des millions d’utilisateurs à des risques.

De plus, l’histoire nous a montré qu’il est très difficile pour une autorité centrale et établie de décider avec autorité de ce qui est une menace et de ce qui ne l’est pas. Nous avons vu ce même type d’autorité, tout récemment encore, déclarer que Signal et WhatsApp étaient des indicateurs de menace. Qui décide quel type d’expression est si menaçant que nous devons modifier tous les navigateurs web pour l’interdire purement et simplement ?

L’approche actuelle du gouvernement en matière de réglementation semble être axée sur la censure et l’autoritarisme. Sur le plan éthique, une telle initiative ouvrirait la porte à un glissement dangereux. Aujourd’hui, il pourrait s’agir d’un code pour des raisons de sécurité ou de réglementation, mais demain, qu’est-ce qui empêcherait l’extension de ces mandats à des fins plus autoritaires ou restrictives ? Les responsables des institutions ici présentes me paraissent largement érudits et raisonnables ; mais le citoyen n’a aucune garantie que vos successeurs partageront le même état d’esprit. Une fois que le précédent est établi, il devient plus facile d’étendre et d’abuser de ce pouvoir, menant potentiellement à une censure accrue, à une surveillance de masse et à une érosion de la confiance des utilisateurs dans les outils numériques qu’ils utilisent au quotidien.

Aucun pays, jusqu’à présent, n’a tenté d’imposer l’intégration d’un code de censure ou de surveillance contrôlé par le gouvernement dans tous les principaux navigateurs web. C’est une démarche sans précédent qui soulève des questions fondamentales sur la liberté d’expression, la vie privée et la confiance dans l’espace numérique. La France doit se demander si elle souhaite véritablement être le premier pays de l’Union européenne, voire le premier au monde, à emprunter cette voie.

Il est essentiel de se rappeler que la censure, sous quelque forme que ce soit, est une atteinte à la liberté d’expression. Permettez-moi de préciser ici que je comprends la priorité que beaucoup peuvent raisonnablement accorder aux questions d’ordre social, de cohésion sociale. Ma riposte serait que les discours violents sont probablement le symptôme d’un manque d’ordre social, et non la cause. Si nous admettons que c’est le cas, c’est à la cause qu’il faut s’attaquer, et non au symptôme.

Surveillance des smartphones

L’article 3 du projet de loi dite “d’orientation et de programmation du ministère de la Justice”, récemment discuté en France, vise à légitimiser la transformation des smartphones en outils de surveillance, Il s’agit d’un pouvoir dont les forces de l’ordre disposent déjà en France, mais cette loi le légitime davantage, en permettant aux forces de l’ordre de transformer à distance n’importe quel smartphone en dispositif d’espionnage en prenant le contrôle de sa géolocalisation, de son appareil photo et de son microphone grâce à l’exploitation de bogues logiciels et en piratant essentiellement le téléphone.

Je ne sais pas si monsieur le général de la gendarmerie est encore dans l’assistance, mais si c’est le cas, il est probablement agacé que je n’aie pas mentionné que cette capacité existe déjà (même si sous une forme moins juridiquement encadrée), à quel point elle sera contrôlée et restreinte par les juges, ou le fait qu’elle ne sera utilisée que dans des cas de sécurité extrêmement graves, qu’elle serait autorisée seulement pour les infractions punies d’au moins cinq ans d’emprisonnement, ou encore qu’elle nécessite un mandat valable pendant 15 jours et renouvelable une seule fois. Voilà, tout est sur la table.

Le problème, c’est qu’à chaque fois que nous parlons des risques de mesures comme celle-ci, nous parlons de la question d’un nouveau précédent judiciaire. Personnellement, je peux dire sincèrement que j’ai eu l’impression ce matin que mon général semble être un chef mesuré et responsable. Mais ce n’est pas lui qui me préoccupe : ce qui m’inquiète, c’est les personnes qui pourrait lui succéder dans les années à venir. Ces personnes, mesurée ou carrément autoritaire, seraient armés des nouveaux précédents judiciaires qui sont accordés grâce à ces lois. C’est, simplement, trop de pouvoir à donner à l’état en perpétuité.

De plus, cette mesure pourrait avoir des conséquences imprévues en matière de sécurité. Si notre gouvernement peut activer à distance les appareils électroniques, cela signifie qu’il existe une porte dérobée ou une vulnérabilité qui permet cette action. Ces vulnérabilités pourraient être exploitées par des acteurs malveillants, tels que des pirates informatiques, pour accéder aux informations des utilisateurs ou pour commettre d’autres actes malveillants. Au lieu de renforcer la sécurité, une telle mesure pourrait la compromettre davantage. Et je suis désolé de dire que je ne crois tout simplement pas que la France dispose d’un avantage en matière de cybersécurité qui puisse empêcher, par exemple, la Chine d’exploiter ces scénarios pour espionner les citoyens français. En clair, si la France découvre une vulnérabilité de type “zero-day”, la Chine l’a probablement déjà stockée pour une semaine. Il est donc préférable de corriger autant de failles que possible, en les rendant impuissantes pour toutes les parties, plutôt que de les stocker comme des armes.

Aujourd’hui, posséder un smartphone n’est plus un simple luxe ou un gadget technologique ; c’est devenu une nécessité absolue pour la survie dans notre société moderne. Ces appareils sont bien plus que de simples téléphones. Ils sont essentiels pour travailler, étudier, gérer nos finances, accéder à des services de santé, et même pour des tâches aussi basiques que faire ses courses ou utiliser les transports en commun. Dans de nombreux cas, ne pas avoir de smartphone équivaut à être coupé du monde moderne, à être désavantagé socialement, économiquement et même culturellement.

Transformer les smartphones, qui sont devenus des extensions de nous-mêmes, en outils de surveillance omniprésents, c’est forcer les citoyens à choisir entre participer à la société moderne et protéger leurs droits les plus élémentaires.

Conclusion

Il est apparent que la France semble aujourd’hui s’égarer dans un labyrinthe de propositions législatives malavisées et potentiellement liberticides. L’élément le plus stupéfiant dans cette situation est qu’il existe des preuves accablantes de compétences réelles à des postes d’autorité. Puisque c’est le cas, pourquoi nous retrouvons-nous continuellement avec des propositions législatives qui semblent fondamentalement mal interpréter l’approche de la cybersécurité ? Pourquoi l’approche est-elle si inévitablement maladroite et directement contraire à la façon dont la technologie fonctionne de nos jours ?

Ma position est que ces mesures ne contribuent que très peu à l’ordre social, tout en contribuant fortement à l’érosion de la confiance dans nos institutions et dans la manière dont elles choisissent de relever les défis de l’ère numérique. Il est urgent que la France change de cap. Il est temps d’ouvrir le débat, d’écouter les experts, de construire une législation efficace, respectueuse des droits fondamentaux et à la hauteur des enjeux du XXIe siècle. Si nous ne le faisons pas, nous risquons de laisser en héritage une France affaiblie, divisée et en décalage avec son temps. Et cela, aucun citoyen français ne devrait l’accepter.

Native Labs: Audit Report

Wed, 30 Aug 2023 00:00:00 +0000

At Symbolic Software, we recently concluded an extensive audit of the Native Labs smart contracts. We’re excited to share our findings and offer our perspectives on the strengths and areas for improvement.

Native Labs offers a decentralized exchange system that focuses on operational efficiency, code quality, interoperability, on-chain and off-chain transactions, liquidity models, and user experience. Our evaluations aimed to present a holistic view of the smart contracts’ functionality, efficiency, and usability.

Audit Methodology and Focus Areas

Our audit covered the following aspects:

Performance Evaluation: We assessed the operational efficiency, with emphasis on gas usage, scalability, and transaction speed.
Code Quality Inspection: This centered around code readability, maintainability, and best practices.
Interoperability Review: We examined the integration capabilities with both internal and third-party entities.
On-chain and Off-chain Analysis: We investigated the handling of transactions, ensuring their accuracy, security, and effectiveness.
Evaluation of Liquidity Models: We delved into the liquidity models provided by Native.
User Experience Audit: We gauged how the smart contracts impact the overall user experience.

Key Findings and Recommendations

Performance: The smart contracts showcased sufficient efficiency, with optimized gas consumption leading to reduced transaction costs. However, given the evolving Ethereum gas landscape, continuous monitoring and optimization are suggested.
Code Quality: Despite some inconsistencies in coding style, the comprehensive documentation provided by the Native team played a pivotal role in our understanding of the codebase. We recommend the adoption of a consistent coding style and possibly leveraging a linter.
Interoperability: The smart contracts demonstrated impressive interoperability capabilities, especially with significant platforms like PancakeSwap, Uniswap v3, and 1inch.
On-chain and Off-chain Operations: The system effectively handles both transaction types. We advise the team to consistently review these operations, particularly in light of potential changes in the blockchain environment.
Liquidity Models: Native’s models proved efficient and user-centric, although we emphasize the need to educate users on potential risks like impermanent loss.
User Experience: The contracts excel in accessibility, transparency, and ease of use. Regular user feedback will be invaluable to further enhance the user experience.

Read the Report

Our comprehensive audit reveals that the Native Labs smart contracts are developed meticulously with a clear focus on user experience, performance, and security. While there are areas for improvement, the overarching impression is positive. These insights should provide users and stakeholders with a more profound understanding of the platform’s integrity and reliability.

To dive deeper into our analysis and findings, you can download the full audit report.

One Year of Verifpal

Wed, 02 Sep 2020 00:00:00 +0000

Last week, Verifpal, our cryptographic protocol modeling and analysis framework, celebrated its one-year anniversary. In its first year, Verifpal has made some significant achievements.

Improvements to Usability, Features, and Reliability

First, Verifpal has improved its relationship with users. Verifpal was part of Zoom’s effort to modernize its cryptography. Verifpal for Visual Studio Code and VerifHub allowed engineers to model and collaborate on cryptographic protocols more easily than ever. And better attack traces allowed for easier to understand analysis results.

Verifpal for Visual Studio Code allows visualizing and analyzing Verifpal models straight inside Visual Studio Code, with easy access to documentation for primitives and other functionality by hovering with the cursor.

Second, Verifpal obtained new features that allow it to capture more of a protocol’s workings. Verifpal gained the ability to model protocols where users can potentially input weak or strong passwords. This is very useful for modeling protocols that include user-provided passwords at points, and is a great way to separate guessable passwords from material that can actually securely be used as an encryption key of some kind. New primitives were introduced, allowing the usage of ring signatures, public key encryption, Shamir secret sharing and blind signatures. The leaks keyword now exists, allowing principals to leak constants to the attacker without necessarily sending them to another principal. Phases are an exciting new feature that allows Verifpal to reliably model post-compromise security properties such as forward secrecy or future secrecy. Query preconditions allow for illustrating relationships between different Verifpal queries on a protocol. And dozens of small improvements and changes were made to Verifpal across its application stack.

Finally, and most importantly, Verifpal improved its analysis strength and reliability. As documented in a previous post, Verifpal’s formal semantics and passive attacker analysis are now fully modeled in the Coq theorem prover. While this does not include active attacker analysis methodology, it does indicate that we can capture Verifpal’s semantics elegantly in existing formalism methods as well as a basic component of its analysis methodology. Our revised Verifpal paper goes into further detail on the Verifpal active attacker analysis methodology and describes formally how primitives are defined, deconstructed and analyzed in Verifpal. Furthermore, valuable feedback was received from over a dozen Verifpal community members that allowed detecting and fixing analysis errors, misleading analysis results and that pushed us to more concretely define the meaning and function of Verifpal queries such as freshness and authentication. These discussions occurred on the Verifpal Mailing List, the Verifpal Discord as well as via private feedback.

Verifpal’s paper was revised to go into further detail regarding the analysis methodology, formal semantics and the limits of Verifpal analysis. PrimitiveSpecs were introduced in order to standardize how primitives are defined and how their semantics operate within Verifpal analysis, i.e. via the following operations:
• Decompose. Given a primitive’s output and a defined subset of its inputs, reveal one of its inputs. (Given ENC(k, m) and k, reveal m).
• Recompose. Given a subset of a primitive’s outputs, reveal one of its inputs. (Given a, b, reveal x if a ,b,_ = SHAMIR_SPLIT(x)).
• Rewrite. Given a matching defined pattern within a primitive’s inputs, rewrite the primitive expression itself into a logical subset of its inputs. (Given DEC(k, ENC(k, m)), rewrite the entire expression DEC(k, ENC(k, m)) to m).
• Rebuild. Given a primitive whose inputs are all the outputs of some same other primitive, rewrite the primitive expression itself into a logical subset of its inputs. (Given SHAMIR_JOIN(a, b) where a, b, c = SHAMIR_SPLIT(x), rewrite the entire expression SHAMIR_JOIN(a, b) to x).

Understanding Verifpal’s Purpose in the Protocol Security Space

Given Verifpal’s progress over its first year, it becomes ever more important to clearly answer the question: “Where is Verifpal positioned within the protocol security space in comparison to other tools?” What is Verifpal able to do for me, the protocol analyst, engineer or applied cryptography practitioner?

Verifpal appears to be evolving towards being software best suited for designing, modeling, analyzing and testing cryptographic protocols. Notably, this means that Verifpal is not likely to progress in the direction where it functions as a producer of protocol security proofs, nor does our experience lead us to believe that this is a space where more contributions are likely to be useful or impactful. This latter functionality will likely remain the jurisdiction of tools such as Tamarin.

Verifpal’s goal is to focus on the real-world priority of exceeding these tools in terms of how much time and effort it will take for the engineer or practitioner to obtain a meaningful model of their protocol that gives them meaningful analysis answers. However, the compromises to ease of use and modeling/analysis rapidity required for Verifpal to offer full proving capabilities are deemed too great given Verifpal’s design and functionality goals, and therefore will likely never be adopted fully into its functionality.

For example, Verifpal’s strategy for dealing with state space explosion imposes limitations on the completeness of its analysis, but this appears to only affect protocols that are unlikely to ever appear in real-world scenarios, while also granting Verifpal greater analysis speed and likelihood for analysis termination than other tools.

In deciding Verifpal’s priorities, we slam the brakes at the moment where the learning curve, effort and analysis cost begin to have strongly diminishing returns for the user. Our bet is that this path forward for Verifpal will lead to a hugely more substantial impact for engineers and practitioners than traditional automated proof modeling tools. In the example above, we can see how Verifpal makes compromises in analysis completeness that preclude its ability to output full proofs but that greatly increase the likelihood of analysis termination (a significant problem for tools such as ProVerif) without having an apparently significant impact on the analysis of real-world, non-Ivory-Tower protocols.

Ergo, Verifpal’s main responsibility is to straddle a balance between soundness/reliability and ease of use/relevance to real-world practitioners. The way we approach this responsibility is by making sure that Verifpal’s semantics are formally specified, that its analysis methodology is amply documented, and that its code is easy to understand. Verifpal’s formal semantics in Coq, the analysis methodology details in the Verifpal paper documented and easy-to-understand Go codebase aim to fulfill this purpose.

Simultaneously, Verifpal utilizes this formally specified base in order to maintain the development of a language and framework that is idiomatic to the extreme. The Verifpal language is meant to illustrate protocols close to how one may describe them in an informal conversation, while still being precise and expressive enough for formal modeling. Verifpal avoids user error by not allowing users to define their own cryptographic primitives. Instead, it comes with built-in cryptographic functions which nevertheless are defined and which operate according to a formally specified standard with concrete semantics. All of this is coupled with a high standard for documentation, accessibility and support in popular workflows and code editors (via Verifpal for Visual Studio Code and VerifHub).

So far, Verifpal’s chosen path has allowed it to provide value in the quick modeling and correct analysis of the DP-3T pandemic contact tracing protocol as it was being specified, and has helped Zoom, Monocypher and others achieve quick protocol modeling and prototyping insight as they developed their protocols, by offering a methodology and framework that allowed results to be obtained in hours (sometimes minutes!) instead of weeks. We hope to continue making exciting developments in Verifpal well into 2021, and can’t wait to see how the community makes use of it.

Better Queries for Verifpal

Tue, 14 Apr 2020 00:00:00 +0000

For the past few weeks, repeated requests have appeared for Verifpal to provide more analysis features in the way of detecting replay attacks and also in supporting the analysis of the unlinkability of values in protocols.

Friedrich Wiemer pointed out that Verifpal was not flexible enough to detect replay attacks in Needham-Schroeder, while Anders N. also requested replay attack detection recently in relation to other protocols. Others have also made such a request. Unlinkability became a pertinent feature especially after our attempts to sketch a model of the DP-3T pandemic-tracing protocol in Verifpal last week.

Furthermore, there have been many requests since Verifpal’s inception to allow for more in-depth analysis of Verifpal models using tools that have existed for decades longer, such as ProVerif, CryptoVerif, Tamarin and Coq.

As such, Verifpal 0.12.0 will introduce many new features that will allow it to expand and mature in ways meant to address the above:

Freshness Queries in Verifpal

Freshness queries are useful for detecting replay attacks. In passive attacker mode, a freshness query will check whether a value is “fresh” between sessions (i.e. if it has at least one composing element that is generated, non-static). In active attacker mode, it will check whether a value can be rendered “non-fresh” (i.e. static between sessions) and subsequently successfully used between sessions. An example of freshness queries is available in examples/test/freshness.vp.

Freshness queries are currently fairly well-defined in themselves, but it is unclear still whether they are flexible enough to detect the kinds of replay attacks that are envisioned by our users. As such, further discussion is welcome on the Verifpal Mailing List in order to understand how replay attack detection in Verifpal can be further improved.

Unlinkability Queries in Verifpal

Protocols such as DP-3T, voting protocols and RFID-based protocols posit an “unlinkability” security property on some of their components or processes. Definitions for unlinkability vary wildly despite the best efforts of researchers. Complicating matters further, the actually-formalized definitions for unlinkability tend to pertain to processes and not to values like the definition used by, for example, DP-3T.

In DP-3T, definitions for unlinkability are suggested to go along these lines: “for two observed ephIDs, the adversary cannot distinguish between a game in which they belong to the same user and a game in which they belong to two different users.” (definition elucidated with Benjamin Lipp; the DP-3T whitepaper itself does not currently have one).

Hirschi, Delaune et al have a couple of papers exploring the formalization of unlinkability: A Method for Unbounded Verification of Privacy-type Properties, followed by A Method for Proving Unlinkability of Stateful Protocols. In these papers, the unlinkability of processes is defined as the satisfaction of two properties: “frame opacity” and “well-authentication”:

Frame opacity: “Intuitively, this condition aims to prevent attacks in which, for some possible behaviour of the attacker, there exists a relation between messages that leaks information about the involved agents. Practically speaking, this condition requires that any reachable frame must be statically equivalent to an idealised frame that does not depend on identity parameters. A very simple way to obtain an idealisation of a frame is to replace each output message by a fresh nonce. In that case, if the real frame and the idealised frame are statically equivalent, it is obvious that the attacker cannot learn anything by analysing the relations between the messages, since there is no relation between disctinct fresh nonces. Nevertheless, it is not satisfying because too restrictive as e.g. a pair is distinguishable from a nonce.”
Well-authentication: “The idea behind this second condition is to avoid that the outcome of conditionals leaks information about identities to the attacker. To do so, we require that whenever a conditional (let or lookup) is positively evaluated, the corresponding agent is having an honest interaction with another participant. In practice, protocols often have some conditionals for which the attacker already knows the outcome: these safe conditionals can (and must) be excluded from our condition.”

Frame opacity seems clear enough, and well-authentication seems to be the combination of the traditional notion of “strong authentication” or “mutual authentication”, combined with an assumption of honest protocol-following on behalf of the other party (i.e. the protocol “executing correctly”).

Based on the above, Verifpal 0.12.0 will introduce experimental support for a notion of unlinkability in Verifpal that centers more on values than on processes. For example, one could write unlinkability? a, b as a query to test whether a and b are unlinkable from one another. Unlinkability checks for the following:

First, Verifpal checks to see if a and b satisfy freshness. If they do not, the query fails. Similarly to regular freshness queries, if an attacker can coerce a value to be non-fresh across sessions, then it is non-fresh and the query fails.
If a and b both satisfy freshness, Verifpal then checks to see if the attacker can determine them as being the output of the same primitive (for example, the first and second output of the same HKDF construction with the same inputs.) Of course, a and b can indeed be the outputs of that HKDF and be unlinkable; unless the attacker is able to reconstruct that same HKDF primitive and thereby use it to determine that both values are the outputs of it.

Further testing of this definition of unlinkability in Verifpal is strongly welcome, as it is very much expected that it will be further elucidated since it is highly doubtful that it covers all cases on unlinkability. Again, Verifpal Mailing List.

Formalizing Verifpal in Coq, and Experimental ProVerif/Coq Model Generation

Work has been ongoing on allowing for the automated translation of Verifpal models to the languages of other tools for those interested in carrying out further analysis:

ProVerif: ProVerif is the verification software that inspired Verifpal and which was written by my former thesis co-advisor Bruno Blanchet. ProVerif has existed for around 20 years and can perform a more diverse set of analyses than Verifpal despite both softwares belonging to the same category of verifiers (symbolic model protocol verifiers).
Coq: Coq is a full-fat theorem prover that can do way more than handle the description of protocols. Georgio Nicolas has been handling Coq translations, with Mukesh Tiwari recently joining our effort and lending a hand (welcome, Mukesh!). Currently, we have fully formalized the semantics of Verifpal in Coq, and we are working on also formalizing the attacker and verification logic in Coq as well for both active and passive attackers. At that point, we will have fully implemented Verifpal in Coq.

Experimental ProVerif and Coq model generation will be available for testing in Verifpal 0.12.0. Type verifpal help to find out more on how to use Verifpal to generate these models.

Once support for ProVerif and Coq in Verifpal has matured, and especially once attacker and verification logic is captured in Coq on top of the current semantics, another more detailed blog post will follow.

Looking Towards a Bright 2020

Finally, Verifpal 0.12.0 will also support phases in passive attacker mode, and not just in active attacker mode as before.

These developments in Verifpal are incredibly exciting. They come hot on the heels of many other new features and improvements that have been introduced so far in 2020:

New primitives, such as public-key encryption, Shamir secret sharing and ring signatures.
Multi-threaded, concurrent analysis using Go’s excellent multithreading support. Put that gaming PC to work!
Password-hashing modeling, which allows for models to capture when a weak/guessable/bruteforceable password is used as, for example, an encryption or signing key.
leaks expression, which allows simulating the leaking of a value on the network without sending it as a message.
Queries as preconditions for messages.

All of this is in line with our announced Verifpal 2020 plans, and the progress on these plans so far has been highly encouraging.

The list of projects using Verifpal continues to grow, and none of this would have been possible without the help of our supporters:

NLNet Foundation: Verifpal is sponsored by the NLNet Foundation. Funding was provided through the NGI0 Privacy Enhancing Technologies Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet program, under the aegis of DG Communications Networks, Content and Technology under grant agreement №825310.
Cure53: Verifpal is also supported by Cure53, a Berlin-based security auditing firm which provides penetration testing for online services, security analysis and architectural advice for security and cryptographic applications, training, consulting, incident management and malware analysis.

And, of course, users like you. Thank you!

Get involved in Verifpal discussions today, either through:

Verifpal Mailing List, for more long-form and serious discussions, or,
Verifpal Discord, where you can chat with Verifpal contributors, users and enthusiasts!

Modeling DP-3T With Verifpal

Sun, 05 Apr 2020 00:00:00 +0000

Last week, numerous researchers published the timely fruits of their recent collaboration to provide a proximity-tracking solution that can help during pandemics while still being privacy-preserving: the result, Decentralized Privacy-Preserving Proximity Tracing (DP-3T), provides a promising first step in bringing real-world cryptography into the effort to combat the COVID-19 pandemic. As mentioned in Troncoso et al.’s whitepaper, the goal of DP-3T is:

"…to simplify and accelerate the process of identifying people who have been in contact with an infected person, thus providing a technological foundation to help slow the spread of the SARS-CoV-2 virus. The system aims to minimise privacy and security risks for individuals and communities and guarantee the highest level of data protection."

Troncoso et al, Decentralized Privacy-Preserving Proximity Tracing

In support of this project, we at Symbolic Software decided to test out Verifpal, our open source protocol verification framework, to see how well its promises of easier and more accessible protocol modeling and verification can hold up in the face of a new and ambitious protocol that targets a novel use case.

In this post, we will go through DP-3T while modeling it using the Verifpal Language, and conclude by comparing our results to the designers’ security goals.

Modeling DP-3T

To demonstrate DP-3T, we will assume that the principals participating in this simulation are the following:

A population of 3 individuals: Alice, Bob, and Charlie, each of them possessing a smartphone: SmartphoneA, SmartphoneB, and SmartphoneC respectively;
A Healthcare Authority serving this population;
A Backend Server, that individuals can communicate with to obtain daily information.

After installing Verifpal, we can start by creating a new model called “dp-3t.vp” in which we begin by defining an attacker which matches with our security model. In this case we will be using an active attacker (i.e. one that can not only monitor but also intercept and overwrite unprotected messages on the network):

attacker[active]

We then proceed to illustrate our model as a sequence of days in which DP-3T is in operation within the lifecycle of a pandemic.

Day 0 (setup phase)

We assume that no new individuals were diagnosed with the disease on Day 0 of using DP-3T. This means that the Healthcare Authority and the Backend Server will not act at this stage and we can simply ignore them for now.

The DP-3T specification states that every principal, when first joining the system, should generate a random secret key (SK) to be used for one day only. For every SK value, and the knowledge of a public “broadcast key” value, principals should compute multiple Unique Ephemeral ID values (EphID) using a combination of a PRG and a PRF. The method of generating EphID is analogous with the HKDF function from Verifpal. We could add the following lines of code to our file in order to model Alice’s SmartphoneA:

// All lines that start with "//" are treated as comments and ignored by Verifpal
// A principal block looks like the following
principal SmartphoneA[
    // In the line below we state that Alice knows the public BroadcastKey
    
    knows public BroadcastKey
    
    // SK is going to be a secret random value
    // To define it we use the "generates" keyword
    // We will use the following template for SK variable names
    // SK[day number][principal initial]
    
    generates SK0A
    
    // We will use the following template for EphID variable names
    // EphID[day number][value number][principal initial]
    
    EphID00A, EphID01A, EphID02A = HKDF(nil, SK0A, BroadcastKey)
]

The same thing goes for Bob, and Charlie:

principal SmartphoneB[
    knows public BroadcastKey
    generates SK0B
    EphID00B, EphID01B, EphID02B = HKDF(nil, SK0B, BroadcastKey)
]

principal SmartphoneC[
    knows public BroadcastKey
    generates SK0C
    EphID00C, EphID01C, EphID02C = HKDF(nil, SK0C, BroadcastKey)
]

Whenever two principals would come into physical proximity of each other, they would automatically exchange EphIDs. Once a principal uses an EphID value, they discard it and use another one when performing an exchange with another principal.

Let’s imagine that Alice and Bob came into contact. It would mean that Alice sent EphID00A in a message to Bob and that Bob sent EphID00B to Alice:

Here is how the above message exchange is modeled in Verifpal:

// Sender -> Recipient : Name of Value

SmartphoneA -> SmartphoneB: EphID00A
SmartphoneB -> SmartphoneA: EphID00B

Now, let’s say that in the conclusion of Day 0, Bob sits behind Charlie in the bus:

Modeling this is equally simple:

SmartphoneC -> SmartphoneB: EphID01C
SmartphoneB -> SmartphoneC: EphID01B

Day 1

On Day 1, the Backend Server will automatically publish the SK values of people who were infected to the members of the general population. These values were previously unpublished and thus were private and only known by their generators and the server.

// A server is just like any other principal

principal BackendServer[
    // Let's assume that infectedPatients0 is the list of infected patients on day 0
    knows private infectedPatients0
]

BackendServer -> SmartphoneA: infectedPatients0
BackendServer -> SmartphoneB: infectedPatients0
BackendServer -> SmartphoneC: infectedPatients0

We should not forget that every day starting from Day 1, DP-3T mandates that principals will generate new SK values. The new value will be equal to the hash of the SK value from the day before. Principals will also generate EphIDs just like before.

principal SmartphoneA[
    SK1A = HASH(SK0A)
    EphID10A, EphID11A, EphID12A = HKDF(nil, SK1A, BroadcastKey)
]

principal SmartphoneB[
    SK1B = HASH(SK0B)
    EphID10B, EphID11B, EphID12B = HKDF(nil, SK1B, BroadcastKey)
]

principal SmartphoneC[
    SK1C = HASH(SK0C)
    EphID10C, EphID11C, EphID12C = HKDF(nil, SK1C, BroadcastKey)
]

Thankfully, Alice, Bob and Charlie are committed to self-confinement and have stayed at home, so they did not exchange EphIDs with anyone.

Day 2

On Day 2, a similar sequence of events takes place. Since it is sufficient to define the values that we will need later on in our model, we will just define a block for Alice.

principal SmartphoneA[
    SK2A = HASH(SK1A)
    EphID20A, EphID21A, EphID22A = HKDF(nil, SK2A, BroadcastKey)
]

Fast-Forward to Day 15

Unfortunately, Alice tests positive for COVID-19. Since this breaks the routine that happened between Day 1 and Day 15, we will announce a new phase in our protocol model:

phase[1]

Alice decides to announce her infection anonymously using DP-3T. This means that she will have to securely communicate SK1A (her SK value from 14 days ago) to the Backend Server, using a unique trigger token provided by the healthcare authority. Assuming that the Backend Server and the Healthcare Authority share a secure connection, and that a private key encryption key ephemeral_sk has been exchanged off the wire by the Healthcare Authority, Alice, and the Backend Server, the Healthcare Authority will encrypt a freshly generated triggerToken using ephemeral_sk and send it to both Alice and the Backend Server.

principal HealthCareAuthority[
    generates triggerToken
    knows private ephemeral_sk
    m1 = ENC(ephemeral_sk, triggerToken)
]

// The brackets around m1 here mean that the value is guarded
// ie: an active attacker cannot inject a value in its place

HealthCareAuthority -> BackendServer : [m1]
HealthCareAuthority -> SmartphoneA : m1

Then, Alice would have to use an AEAD cipher to encrypt SK1A using ephemeral_sk as the key and triggerToken as additional data and send the output to the Backend Server. Note that Alice can only obtain triggerToken after decrypting m1 using ephemeral_sk.

principal SmartphoneA[
    knows private ephemeral_sk
    m1_dec = DEC(ephemeral_sk, m1)
    m2 = AEAD_ENC(ephemeral_sk, SK1A, m1_dec)
]

SmartphoneA -> BackendServer: m2

The Backend Server will now have to decrypt m1 to receive the triggerToken in the same way that Alice did, then attempt to decrypt m2. If that decryption was successful, the server would obtain SK1A and would be sure that the value came from Alice because it is only Alice who knows both triggerToken and SK1A at the same time as defined in the protocol.

Finally, the Backend Server will add SK1A to the list of infected patients previously defined, and then send this list to all of the individuals in this community.

principal BackendServer [
    knows private ephemeral_sk
    m2_dec = AEAD_DEC(ephemeral_sk, m2, DEC(ephemeral_sk, m1))?
    infectedPatients1 = CONCAT(infectedPatients0, m2_dec)
]

BackendServer -> SmartphoneA: infectedPatients1
BackendServer -> SmartphoneB: infectedPatients1
BackendServer -> SmartphoneC: infectedPatients1

Everything that happened in Day 15 can be summarized in the following diagram:

Queries

Now, we may finally define the queries block, in which we ask Verifpal about the state of certain security guarantees that we expect from the protocol.

Since SK1A is now shared publicly, the DP-3T software running on anyone’s phone should be able to re-generate all EphID values generated by the owner of SK1A starting from 14 days prior to the day of diagnosis. These values would then be compared with the list of EphIDs they have received. Everyone who came in contact with Alice will therefore be notified that they have exchanged EphIDs with someone who has been diagnosed with the illness without revealing the identity of that person.

queries[
    // Would someone who shared a value 15 days before they got tested get flagged?
    // ie in phase[0], before phase[1]
    confidentiality? EphID02A
    // Will people who came in contact with Alice be able to compute
        // all of Alice's EphIDs starting from Day 1
    confidentiality? EphID10A
    confidentiality? EphID11A
    confidentiality? EphID12A
    confidentiality? EphID20A
    confidentiality? EphID21A
    confidentiality? EphID22A
    // Is the server able to Authenticate Alice as the sender of m2
    authentication? SmartphoneA -> BackendServer: m2
]

The results of our initial modeling in Verifpal suggest to us the following:

No EphIDs generated by Alice are known by any parties before Alice announces her illness.
EphID02A remains confidential even after Alice declaring her illness. Note that it was generated 15 Days before Alice got tested.
All of the following values EphID10A, EphID11A, EphID12A, EphID20A, EphID21A, EphID22A have been recoverable by an attacker in phase[1] after Alice announces her illness.

These results come in line with what is expected from the protocol. We note that the security of communication channels between Healthcare Authorities, Backend Servers, and Individuals have not been defined, and we have placed our own hypothetical security conditions in order to focus on quickly sketching the DP-3T protocol. Further analysis will be required in order to better elucidate the extent of the obtained security guarantees.

Generating Models for Further Analysis in ProVerif and Coq

Verifpal generating ProVerif models live from the Verifpal model, through the Verifpal Visual Studio Code extension.

We’re very excited to be working on automatically generating ProVerif and Coq models directly from Verifpal models. The resulting ProVerif and Coq models will be human-readable and thus easily extensible, allowing for more profound protocol analysis and supplementing Verifpal’s insight with that of tools that have existed for more than two decades.

In working on DP-3T, we were able to generate baseline ProVerif and Coq models after less than an hour of work on the Verifpal model itself. This is an immeasurably huge leap forward in terms of obtaining working material for the formal modeling and analysis of a novel protocol, and we are very excited to post further updates as this new feature matures in Verifpal.

ProVerif and Coq model generation is currently under development, and we expect a beta release to be ready by the end of April.

Coming soon!

Symbolic Software

Verifpal Reaches 1.0: A Toy Becomes an Instrument

What the language can now say

Diffie-Hellman stopped being special

Post-quantum and hybrid key exchange

Assumptions you can declare, verdicts that carry them

Unlinkability, decided by finding a witness

Soundness, assuming the solver is broken

The model that would not finish

Two sessions of every principal

Measuring whose names are in the trace

What it still cannot do

Why “instrument”

Getting it, and what 1.0 commits to

Verifpal 0.80.0: Nuancing Weak Cryptography Modeling and Witness-Based Unlinkability

Why a model might want imperfect cryptography

A worked example: the hybrid argument, written as an assumption

Assumptions that arrive later

Why weak and forgeable are two separate assumptions

What happens when an assumption does not apply

Unlinkability, decided by finding a witness

Two conditions that keep a witness honest

Getting it, and what to re-check

Verifpal 0.70.0: Post-Quantum Key Exchange, and an Attacker That Works Backwards

An example: one missing character

How the search finds it

Why a reported attack can be trusted

Making the attack readable

Minimizing: dropping everything the attack did not need

Narrating: three kinds of step

Names, not terms

Phases, and when the attacker knows things

Relaying is not forging

Removing equations

KEM_ENCAP and KEM_DECAP

Twelve messages of Signal

Getting it, and moving your models over

Meet the Symbolic Software Summer 2026 Team

The research interns

Hossein Hafezi

Lorenzo Magliocco

The teaching assistants

Faysal El Estwani

Abd El Kader Kahil

Rabab Salim

Why I Teach Cryptography in Lebanon

Communication in the presence of adversaries

Fifty-five students

Precedents

Four days in Paphos

The decades ahead

How Jevil works

Why would you want a cliff?

The secret is a polynomial

A polynomial becomes a signature

The catch, and the fix

One proof, not seventeen

Why you can’t forge below the cliff

Tuning it, and when to reach for it

The paper and the code

On Our Telegram MTProto Review

The conditions of the engagement

The core technical finding

On “auth_key_id changes regularly”

On what the report concludes about each claim

What the tracking looks like in practice

On editorial independence

On the publication route

What remains

Applied Cryptography Course: Welcome, Class of Summer 2026!

What the course covers

What an opportunity this is

A few fun snapshots of the cohort

Where they study

Gender

What the cohort brings to the room

See you on June 9

hpke-ng: Faster, Smaller, Harder HPKE for Rust

Why we built another HPKE library

The shape change: enum dispatch becomes type-state

Why `weak` and `forgeable` are two separate assumptions

Post-setup hot path · `Context::seal` · X25519+ChaCha20

Post-setup hot path · `Context::open` · X25519+ChaCha20

Checked `ASSERT?` Now Actually Halts the Principal