Home — Symbolic Software

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.

Across 62 head-to-head benchmarks against hpke-rs — currently the most widely deployed Rust HPKE library — hpke-ng wins 43, ties 14, and loses 5, with the wins concentrating on the post-quantum decap path (53–55% on ML-KEM-768 and ML-KEM-1024, the largest deltas in the entire dataset, plus a fresh 38% win on X-Wing decap from the same caching trick), the post-quantum encap path (30–37% on ML-KEM, 14% on X-Wing), the classical KEM decap path (41% on X25519 — caching the recipient’s public-key bytes alongside the secret eliminates a redundant base-point scalar multiplication on every call), the single-shot open path (23–35% across payload sizes), and the post-quantum and ChaCha20 setup paths (45–50% on ML-KEM receivers, 31% on X25519 receivers). Every PQ encap and decap row is a clean win.

cargo bench · comparative

62 head-to-head benchmarks

hpke-ng wins

tied

hpke-rs wins

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

Both libraries call the same RustCrypto primitive crates underneath, so the cryptography itself is identical. Both pass the full RFC 9180 known-answer-test set. Both 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. The 32 ties tell you something too — for the AEAD-bound rows and for KEM operations where both libraries converge to the speed of the underlying primitive (single-key generation, ML-KEM IKM expansion, X-Wing key derivation), hpke-ng matches that ceiling without overhead.

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; for ChaCha20-Poly1305 it leaks plaintext via XOR — and 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.

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

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 320-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. This is the kind of footgun whose damage is invisible until the day it isn’t.

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 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 — 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,
)?;

The visible consequence 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. The X-Wing/seal_auth line is the cleanest example: X-Wing is a KEM, but it isn’t a Diffie-Hellman KEM, so it has no notion of authenticated encapsulation. In hpke-rs, calling seal_auth on an X-Wing-configured Hpke returns Error::UnsupportedKemOperation at runtime. In hpke-ng, the trait bound on seal_auth requires K: AuthKem, and XWingDraft06 does not implement AuthKem — so the call doesn’t compile. The same shape applies to the other rows.

This isn’t theoretical. We’ve seen each of those four shapes in production code reviews — typically 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-rshpke-ng

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

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

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

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

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

RFC 9180 KAT conformance (full vendored vector set)✓ pass✓ pass

Typed HpkeError variants1114

Compile-time-rejected operation classes04

Pluggable crypto provider (RustCrypto / libcrux backends)✓ both— RustCrypto only

hpke-ng supports every ciphersuite hpke-rs’s RustCrypto provider supports — six DH-based KEMs, three post-quantum KEMs, three KDFs, four AEADs (including ExportOnly), all four HPKE modes — and passes the full RFC 9180 KAT vector set against both libraries. There are 14 typed HpkeError variants instead of 11, and four classes of operation that are compile errors instead of runtime errors. On every dimension that affects what your application can express, hpke-ng is a superset.

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. That’s the load-bearing 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 Cryspen’s “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. Cryspen’s 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 size 40–60, 2–3 second measurement window, 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.”

The wins concentrate in four places: the post-quantum KEM path (the largest deltas in the entire dataset, peaking at −55% on ML-KEM decap), the classical KEM encap/decap path, the single-shot open path, and the ChaCha20 setup paths. These are the rows where hpke-rs’s per-call overhead — trait dispatch, allocator pressure, an enum match per primitive, a from-seed key reconstruction on every PQ decap — adds measurable framing cost on top of the underlying crypto. Start with the KEM operations on X25519:

KEM operations · X25519

hpke-rshpke-ng

generate

7.69 µs

8.94 µs

+16%

derive_key

8.79 µs

9.39 µs

+7%

encap

38.00 µs

34.33 µs

−10%

decap

36.73 µs

21.47 µs

−41%

Lower is faster. Bars normalized per-row to max(rs, ng).

The decap row tells the load-bearing story: 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. hpke-rs runs that scalar mult per decap. Encap is 10% faster from the same monomorphization trick — the LabeledExtract + LabeledExpand chain wrapping the raw Diffie-Hellman compiles to direct calls, where hpke-rs routes each through its enum-dispatched provider trait. The generate and derive_key_pair rows go the other way (+16% and +7%) because the public-key bytes are now computed and stored at construction time — a one-time cost paid for the per-call decap savings, on a one-call-per-keypair operation that doesn’t appear on any hot path. The same scalar-mult-saving trick lands much harder on the post-quantum decap rows we’ll see shortly.

Setup is the combined fixed cost paid every time a sender or receiver context is constructed: KEM op + key schedule + Context allocation. The wins here are consistent over ChaCha20:

Setup paths · sender / receiver / PSK

hpke-rshpke-ng

X25519+ChaCha20
sender (Base)

38.62 µs

34.17 µs

−12%

X25519+ChaCha20
receiver (Base)

36.84 µs

25.45 µs

−31%

X25519+ChaCha20
sender (PSK)

38.14 µs

33.86 µs

−11%

X25519+AES-128
sender (Base)

40.29 µs

34.35 µs

−15%

P-256+AES-128
sender (Base)

156.57 µs

145.59 µs

−7%

K256+ChaCha20
sender (Base)

54.32 µs

47.67 µs

−12%

Receiver-side wins are larger than sender-side because both `decap` and the post-decap key schedule benefit from the cached public-key bytes.

The post-quantum KEMs add a structural dimension to the comparison that the classical KEMs don’t have. 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 the load-bearing reason ML-KEM decap shows up at −54% to −55% — the largest single deltas in the dataset. ML-KEM-768 first:

KEM operations · ML-KEM-768

hpke-rshpke-ng

generate

17.18 µs

17.62 µs

+3%

derive_key

14.49 µs

14.17 µs

−2%

encap

23.54 µs

14.84 µs

−37%

decap

38.86 µs

17.53 µs

−55%

decap (−55%) is the largest delta in the suite, encap (−37%) close behind — 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, larger absolute numbers, same architectural delta in the same place:

KEM operations · ML-KEM-1024

hpke-rshpke-ng

generate

27.72 µs

28.00 µs

+1%

derive_key

23.19 µs

24.06 µs

+4%

encap

33.34 µs

23.46 µs

−30%

decap

58.27 µs

27.24 µs

−53%

Same pattern as ML-KEM-768 at higher security level: encap −30%, decap −53%. The +4% on `derive_key` is the cost of cloning the larger ML-KEM-1024 expanded encapsulation key into the public-key wrapper at construction.

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

hpke-rshpke-ng

generate

38.94 µs

38.52 µs

−1%

derive_key

35.81 µs

37.60 µs

+5%

encap

64.94 µs

56.06 µs

−14%

decap

115.56 µs

72.25 µs

−38%

decap −38%: 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 +5% on `derive_key` is the cost of cloning the parsed `EncapsulationKey` into the public-key wrapper at construction.

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:

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

hpke-rshpke-ng

X-Wing
sender (Base)

65.30 µs

60.14 µs

−8%

X-Wing
receiver (Base)

116.79 µs

77.45 µs

−34%

ML-KEM-768
sender (Base)

23.77 µs

18.91 µs

−20%

ML-KEM-768
receiver (Base)

39.80 µs

21.86 µs

−45%

ML-KEM-1024
sender (Base)

33.82 µs

27.85 µs

−18%

ML-KEM-1024
receiver (Base)

62.17 µs

31.33 µs

−50%

18 post-quantum head-to-heads across KEM ops + setup: 12 wins, 4 ties, 2 losses (both on `derive_key_pair`, where caching the expanded keys at construction is paid back on every subsequent encap/decap).

The single-shot open path — setup_receiver + Context::open for one message — is where hpke-ng wins most consistently across payload size. Six rows over four orders of magnitude, every row is hpke-ng:

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

hpke-rshpke-ng

64 B

40.30 µs

26.07 µs

−35%

256 B

38.67 µs

26.32 µs

−32%

1 KiB

39.23 µs

27.77 µs

−29%

4 KiB

44.96 µs

31.88 µs

−29%

16 KiB

65.58 µs

50.61 µs

−23%

64 KiB

137.07 µs

127.55 µs

−7%

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.

The AES-128-GCM seal sweep shows hpke-ng 6–12% ahead from 64 B through 16 KiB — 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 — then converges to tied at 64 KiB as the AEAD primitive’s bulk-encryption cost dominates:

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

hpke-rshpke-ng

64 B

39.73 µs

35.38 µs

−11%

256 B

41.03 µs

36.33 µs

−12%

1 KiB

42.94 µs

38.56 µs

−10%

4 KiB

53.94 µs

49.64 µs

−8%

16 KiB

99.41 µs

93.05 µs

−6%

64 KiB

274.23 µs

280.15 µs

+2%

At 64 KiB the AES-NI bulk encryption cost dominates and the framing delta vanishes.

The X25519+ChaCha20 seal sweep — the same shape but with a different AEAD — now lands 7–18% in hpke-ng’s favour from 16 B through 64 KiB, then converges to tied at 256 KiB where the AEAD primitive both libraries call identically dominates the wall time. The most diagnostic single benchmark in the suite is post-setup Context::seal at the two ends of that spectrum:

Context::seal · 64 B

framing-dominant regime

260 nshpke-rs

221 nshpke-ng

−15% · framing only, same crypto

Context::seal · 16 KiB

primitive-dominant regime

24.60 µshpke-rs

24.46 µshpke-ng

tied · at the primitive's ceiling

This is the chart we kept coming back to during development. At 64 bytes, where framing dominates, hpke-ng is 15% faster: 221 ns versus 260 ns. The framing path inside hpke-ng’s Context::seal is a fixed-size 12-byte stack array for the nonce, an XOR loop, and a direct AEAD call — no allocations, and the AEAD cipher state is built once at key-schedule time and reused. hpke-rs allocates a fresh Vec<u8> per nonce computation and reconstructs cipher state from raw key bytes on every call.

At 16 KiB, where the AEAD primitive dominates, both libraries converge to identical wall time. They share the same primitive crate, so this is the ceiling: the wall-clock cost of ChaCha20Poly1305::encrypt_in_place_detached on this hardware, which neither library can dip below because both are calling the same code. hpke-ng matches it exactly — there’s no overhead left to remove, and the framing is as thin as the standard allows.

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.

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’s the load-bearing reason AES-128 single-shot seal is 6–12% faster across small and mid payloads. 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 — a server with persistent client sessions, a relay, 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 −38% 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 — 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,179

+55%

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. 168 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, +55%. This is the one row that runs against the section’s grain, and it’s deliberate. hpke-ng’s bench harness has grown to 1,179 lines while hpke-rs’s stays at 759 — the extra 420 lines are coverage, not waste. A single cargo bench --features comparative reproduces every head-to-head number in this post, against a real hpke-rs install pulled in as a dev-dependency, including the full post-quantum suite (X-Wing, ML-KEM-768, ML-KEM-1024) that hpke-rs ships only behind an experimental feature flag. hpke-rs distributes its bench code across twelve per-provider files; hpke-ng keeps the comparative numbers in one place, which is what made the 62-row table at the top of this post possible at all.

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 — 128 tests across library unit tests, RFC 9180 KAT, generative roundtrips across every ciphersuite × mode combination, and byte-by-byte differential vs hpke-rs — runs in about 1.9 seconds. 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, length mismatches — 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 and produce a nonce-reuse bug — the kind of bug that’s invisible until it isn’t and unrecoverable when it surfaces. 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 — but we haven’t tested it in this repository, and we’d rather call that out than pretend otherwise.

Migrate today

Both libraries pass the same 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)?;

// 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.

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, not 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, the library landscape, 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 — plus 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 — if you encrypt a password with a known key, the attacker can 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 — 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 — the rule that 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 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—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, 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—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

Here is what our audit practice has taught us: the most common source of cryptographic failure is not a broken primitive. It is the complexity surrounding the primitive—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 resonates with 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—hybrid signatures on top of hybrid KEMs, dual certificate chains, negotiation for four algorithms instead of two—adds friction to migration. 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—long-lived code signing, certificate authorities, scenarios where signature validity must span decades—but they should not be the default, and they should not gate the broader migration.

Conclusion

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 real but less compelling. The distinction is not about confidence in lattices—it is about whether the urgency of the threat model justifies the additional complexity.

We are a team that has audited more post-quantum implementations than most. We built the conformance testing framework that the ecosystem uses to validate them. 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. 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

Over the past two months, we have documented sixteen vulnerabilities across six Cryspen 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, the verification pipeline that underlies Cryspen’s “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. Unlike verification theatre—where verification is claimed but not performed—a facade involves verification that is performed but whose 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—deterministic for loops over bounded ranges, pure arithmetic with explicit bounds, 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, this 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—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—precondition violated, no panic, silently wrong result—that the F* model does not represent. 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—but 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—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—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—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, 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—they 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—because while loops are silently proof-inert, because release-mode arithmetic differs from the model, because assume! can poison the proof context, and because 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 makes genuine contributions to high-assurance cryptography. For pure, bounded-loop functions with precise specifications, it provides real verification. 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 Cryspen has consistently failed to provide.

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 genuinely 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—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 in the broader compilation—the modular inversion, the quantum Fourier transform, 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—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—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—if 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—if the estimates are roughly correct and 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—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. Establishing clear norms now—about what constitutes sufficient evidence for different classes of decisions, about the obligations of provers who withhold details, and about the role of independent verification—will serve the field well beyond the current transition.

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 — primitive selection, hybrid construction, TLS migration mechanics, library landscape, 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, secure messaging (Signal, OTR, MLS), end-to-end encrypted cloud storage, post-quantum cryptography, zero-knowledge proofs, cryptocurrency cryptography, high-assurance implementations, and secure multiparty computation.

The course has 16 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 both delivered live and also pre-recorded and published on YouTube. 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—whether in research, 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 quietly 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
libcrux	Rust	Cryspen’s 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 real-world 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.1.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 — 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. It means 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 Cryspen 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 naming isn’t coincidental — like the ancient Jedi vessel where younglings forge their lightsabers, Crucible is where implementations prove they’re truly sound, or reveal where they’re flawed.

For more on where Crucible fits in a production post-quantum migration — primitive selection, hybrid constructions, library evaluation, 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 today’s state-of-the-art cryptographic applications.

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. Cryptographic applications today—secure messaging, authenticated key exchange, post-quantum migration, end-to-end encrypted media—rely on constructions that were often designed under assumptions that no longer hold, or that leave meaningful security properties on the table. The world is constantly revolving, and from this chaos, chaos, we want to re-resolve the facts into a new understanding of the state of the art.

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 landscape 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 will have genuine curiosity 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 are motivated to produce work that has real impact.

Details

Duration: Summer 2026 (approximately 3 months, with flexibility on exact dates).
Location: Remote. Candidates within anywhere that is around 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. 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.

Cryspen's Approach to TLS: A Critical Analysis

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

This is the fourth installment in our series examining Cryspen’s 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 Cryspen’s 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—including 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 Cryspen Handled our Disclosures

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

In January 2026, we began our audit work and opened our first issue on Cryspen’s GitHub (#1299). It was professional and submitted in good faith. When Cryspen’s 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 Cryspen had publicly thanked for their reports.

Cryspen’s 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 honestly 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. Cryspen declined, and then accused us of not giving them time to address vulnerabilities before public disclosure—despite the fact that it was Cryspen who blocked our ability to submit fixes, after we had already disclosed four bugs complete with tested patches, free of charge.

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

While Cryspen 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 constitute irresponsible behavior. Furthermore, Cryspen has 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.

Cryspen’s 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 Cryspen’s handling of our disclosures lived up to these principles.

Findings

Over the past month, we have published eleven vulnerabilities across Cryspen’s cryptographic libraries, spanning post-quantum key encapsulation, digital signatures, and hybrid public key encryption. Our 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.

We now expand our scope to Cryspen’s TLS implementations. Cryspen maintains two: rustls-libcrux, a cryptographic provider for the rustls TLS library backed by libcrux primitives, and Bertie, a standalone TLS 1.3 implementation. We also examined libcrux-iot, Cryspen’s embedded-targeted fork of libcrux designed for constrained IoT devices.

Across these three projects, we found five new bugs: 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, and 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 Cryspen’s 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 occurs with approximately 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—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 Cryspen’s 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 Cryspen’s 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 cryspen/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 Cryspen’s 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—its 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 Cryspen 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 — replacing values on the wire, 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]

The eight operations the attacker can perform — decompose, passive-decompose, recompose, reconstruct (primitive), reconstruct (equation), rewrite, rebuild, and password extraction — are all implemented in this one file. 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 real 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 genuinely 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 — if 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 — the conditions haven’t changed — but the question is phrased in terms of 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 — all mutations are now available at every depth. The STAGE_RECURSIVE_INJECTION constant and inject_primitive_stage_restricted function were deleted — 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

The numbers speak for themselves:

	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 makes the visibility decision — which value a principal perceives — 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 was redesigned to be 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 — no LSP server required — and 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 — 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 — pure Rust with no C/FFI, no system calls in the core engine — 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 — 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 an almost complete ground-up rearchitecture that fixes longstanding design limitations while introducing features that weren’t possible in the old codebase.

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.

These weren’t insurmountable problems — 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 — 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 — an O(1) operation. 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 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 — this specific decryption operation is 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 most significant new feature isn’t about language or architecture — it’s a new analysis technique called Equation Bypass that 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 — because it’s already known, or 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 real-world protocol patterns — ratcheting, multi-party flows, threshold cryptography, hybrid key agreement — that represent the bread and butter of modern protocol design.

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 — producing 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 represents 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 Cryspen's libcrux: ML-DSA

Tue, 17 Feb 2026 00:00:00 +0000

Over the past two weeks, we have published eight vulnerabilities across Cryspen’s cryptographic libraries, including three bugs in formally verified code that Cryspen’s 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): Cryspen 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$—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 (Cryspen’s 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—for example, that multiplying by a power of two equals a left shift, 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.

To put this plainly: every ML-DSA proof Cryspen will ever produce for their AVX2 backend—the backend that runs on every modern x86 server and desktop—is built on approximately forty axioms that are provably false, and no amount of future verification effort can fix this without first discovering and correcting the wrong definition that has been hiding in plain sight since the file was committed. If a customer, regulator, or certifying body relied on Cryspen’s “formally verified” designation to justify deploying libcrux ML-DSA in a context where digital signature correctness is legally or contractually mandated—government procurement, financial infrastructure, firmware signing—they did so on the basis of a verification foundation that is mathematically unsound, where the specification for multiplication itself computes the wrong operation.

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—the verification system never looks at them. 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 (V10) duplicated 1664 instead of writing pow2 (d-1), and the false serialization proof (V12) 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 Cryspen’s 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. This 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—including the top-level signing and verification logic, signature encoding, and key generation—is in ADMIT_MODULES. The verified modules are the leaves. The roots are unverified. And as Finding 3 shows, even the verified leaves rest on unproven axioms.

Cryspen’s 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—signing, verification, 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 relied on Cryspen’s verification claims to justify deploying libcrux ML-DSA in a context where digital signature correctness carries legal or contractual obligations did so on the basis of a verification foundation where the specification for multiplication itself computes the wrong operation.

We Found Bugs in Cryspen's Verified Code

Thu, 12 Feb 2026 00:00:00 +0000

On February 5, we published five new vulnerabilities in Cryspen’s libcrux, hpke-rs, and libcrux-psq cryptographic libraries, along with a paper analyzing the structural pattern behind them. Cryspen’s 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, Cryspen 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 Cryspen’s documentation claims is complete.

What Cryspen’s Response Left Out

Before we get to the bugs, it is worth noting what Cryspen 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 Cryspen’s 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.

Cryspen 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, Cryspen’s 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 Cryspen’s 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$)—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—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 (Cryspen’s 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—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)—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—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—that is, 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 Cryspen’s 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 Cryspen 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—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, Cryspen’s 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 Cryspen 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

Cryspen 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 that the entire verification effort is built on top of—that disagrees with FIPS 203 on every input and has been wrong since the spec file was first created, authored by Cryspen’s Chief Research Scientist himself.
A missing inverse NTT in the ML-KEM encryption specification that adds an NTT-domain polynomial to coefficient-domain polynomials—mathematically nonsensical—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.”

Cryspen’s 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 Cryspen 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 no one—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 which represents the most significant upgrade to Verifpal’s analysis engine since its inception. The headline result: for the first time, Verifpal can 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.

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 four Diffie-Hellman computations — 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 — allow the scanner to 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 — critical 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.

Cryspen 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 Cryspen’s 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 Cryspen addressed quietly, without any public disclosure, and which only received a security advisory because third parties took it upon themselves to file one.

This pattern of events invites reflection on 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.

Cryspen 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 Cryspen. 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 Cryspen’s 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 Cryspen’s marketing narrative but not to anyone whose systems were affected.

Cryspen themselves made absolutely no announcement anywhere regarding the bug. There was no blog post. No security bulletin. No announcement on any Cryspen 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 Cryspen’s 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.

Cryspen’s 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 Cryspen’s 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—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—constraining 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 Cryspen 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—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, comprehensive 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—checking for all-zero DH outputs, preventing integer overflow, 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 Cryspen’s 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 historic new initiative to grow cryptography research, development and representation in the Levant region.

For too long, the global cryptography community has concentrated its major events in a handful of locations, leaving entire regions underrepresented in the conversations that shape our digital future. Cedarcrypt is here to change 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 intensive learning, knowledge sharing, and community building. From secure messaging protocols to post-quantum cryptography, from zero-knowledge proofs to formal verification, Cedarcrypt aims to cover the full spectrum of applied cryptography.

Cedarcrypt is about planting a flag and telling the world that real cryptography work can and does emerge from our region. We aim to create a space where the next generation of cryptographers from the Levant and beyond can learn from established experts, present their own research, and forge connections that will shape their careers.

Call for Submissions

We need you to make this happen. We’re seeking:

Workshop leaders to teach hands-on skills.
Lecturers to share foundational and cutting-edge knowledge.
Researchers to present their latest work.

Whether you’re a seasoned professor or an early-career researcher with fresh ideas, there’s a place for you at Cedarcrypt.

Cedarcrypt welcomes submissions across the full spectrum of applied cryptography. We’re particularly interested in work on secure messaging protocols and the challenges of building private communication systems at scale, as well as the rapidly evolving field of post-quantum cryptography as the community prepares for a post-quantum world. Zero-knowledge proofs and their applications in privacy-preserving systems are also a key area of focus.

Beyond these core topics, we encourage submissions on formal verification of cryptographic implementations, secure implementation practices that bridge the gap between theoretical security and real-world code, and 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, Cyprus offers a unique setting for Cedarcrypt. This UNESCO World Heritage city combines world-class beaches with a rich cultural heritage dating back thousands of years. The AUB Mediterraneo campus provides modern facilities in the heart of this historic city, with direct flights available from major European cities.

Get Involved

This is the first edition of what we intend to become an annual tradition. Come be part of our history! Help us build something that will inspire and empower cryptographers for years to come.

Visit cedarcrypt.org to learn more and submit your proposal.

Introducing Magicall: Encrypted video calls that actually work

Mon, 05 Jan 2026 00:00:00 +0000

Today, we’re publicly launching Magicall, a project we’ve been building for the past little while. It’s a video calling platform, but not like the ones you’re used to.

Magicall is what happens when cryptographers get frustrated with the state of video calling. Every mainstream option falls into one of two camps: either it’s built by a trillion-dollar surveillance company that treats your conversations as training data, or it’s locked into a single ecosystem that requires everyone to own the same brand of devices.

We built something different.

The Problem with Video Calling in 2026

When you use Google Meet, Microsoft Teams, or most other “free” video calling services, you’re not the customer: you’re the product. Your meeting about sensitive business matters, your therapy session, your conversation with your lawyer: it all flows through infrastructure owned by companies whose primary business model is harvesting data for advertising and AI training.

Even when these services claim to offer encryption, they typically mean transport encryption (SRTP)—your call is encrypted in transit, but the provider can still access the content on their servers. Real end-to-end encryption, where even the service provider cannot access your communications, remains rare in mainstream video calling.

FaceTime is a notable exception with genuine end-to-end encryption, but it requires everyone on the call to own an Apple device. That’s not cross-platform support; that’s vendor lock-in disguised as a feature.

What We Built

Magicall takes a different approach:

End-to-End Encryption with Verifiable Authentication. Your video, audio, and chat messages are encrypted in your browser using AES-256-GCM before they ever leave your device. But we went further: Magicall provides short authentication strings (SAS) that let you verify you’re actually talking to who you think you are, not a man-in-the-middle attacker. This is a security feature you won’t find in Google Meet, Microsoft Teams, or even FaceTime.

Zero Downloads, Zero Guest Accounts. Magicall works entirely in your browser—Chrome, Firefox, Safari, Edge, desktop or mobile. When you share your room link, the recipient clicks it and joins. No app installation. No account creation. No friction.

Permanent Room URLs. Every Magicall user gets a permanent room URL like magicall.online/r/yourname. Put it in your email signature, your social media bio, your business card. It’s always ready. Unlike other platforms that generate random meeting links that expire, your Magicall room is yours for as long as you have an account.

No Ads, No AI Training, No Dark Patterns. We don’t show advertisements. We don’t train AI models on your conversations. We don’t use manipulative UI patterns to trick you into upgrading. Our business model is simple: we offer a genuinely useful free tier and a paid tier for users who need more.

The Technical Architecture

For those who care about the implementation details, here’s how Magicall works under the hood.

WebRTC with Modern Codec Support

Magicall is built on WebRTC, the open standard for real-time communication in browsers. Our Selective Forwarding Unit (SFU) architecture supports the latest video codecs in order of efficiency:

AV1 — The newest and most efficient codec, offering excellent compression with minimal bitrate. Where hardware support exists, this delivers the best quality-to-bandwidth ratio.
VP9 — Excellent compression and widely supported, especially on desktop browsers with hardware acceleration.
H.264 — Universal hardware support across all devices. We use the Constrained Baseline profile for maximum compatibility.
VP8 — Our fallback codec for older browsers that don’t support newer options.

For audio, we use Opus at 48kHz with 2 channels—the gold standard for voice and music transmission over the internet.

End-to-End Encryption with SFrame

WebRTC provides transport encryption (DTLS-SRTP) by default, which does offer true end-to-end encryption in ideal peer-to-peer scenarios where browsers connect directly. However, in the real world, most WebRTC connections can’t establish direct peer-to-peer links due to NATs and firewalls. This means traffic typically flows through TURN relay servers or, in our case, an SFU (Selective Forwarding Unit) for efficient multi-party calls. In these scenarios, DTLS-SRTP only protects data in transit between your browser and the server—the server itself can access the unencrypted media. For true end-to-end encryption—where even our SFU cannot access your media—we implement SFrame (Secure Frame), the IETF standard for encrypting media frames in real-time communications.

Here’s how it works:

Key Exchange. When you join a call, your browser generates ephemeral encryption keys using ECDH (Elliptic Curve Diffie-Hellman) on P-256. We originally meant to go with Curve25519, but were constrained to P-256 since only NIST curves are supported by the Web Crypto API. These keys are exchanged directly between participants, never touching our servers in plaintext.
Frame Encryption. Before each video or audio frame leaves your browser, it’s encrypted using AES-256-GCM with keys derived from the shared secret. The SFU receives only ciphertext—it can route packets between participants but cannot decrypt the content.
Ratcheting. Keys are ratcheted forward regularly and whenever participants join or leave, providing forward secrecy. If a key is somehow compromised, it cannot decrypt past conversations.

This architecture means our servers are cryptographically blind to your call content. We handle the routing, but we can’t see or hear anything.

Short Authentication Strings (SAS) for Verification

End-to-end encryption is only as strong as your confidence that you’re talking to the right person. A sophisticated attacker could potentially intercept the key exchange and perform a man-in-the-middle attack, presenting different keys to each participant while secretly relaying (and reading) all traffic.

Magicall defeats this with Short Authentication Strings (SAS), similar to the approach used in the ZRTP protocol:

Hash Commitment. During the key exchange, both parties commit to their public keys using cryptographic hashes before revealing them, preventing either party from adapting their keys based on the other’s.
SAS Generation. After the encrypted channel is established, both clients independently derive a short authentication string (displayed as a 2-word phrase) from the shared cryptographic state.
Verbal Verification. Participants can read these strings aloud to each other. If the strings match, you have cryptographic proof that no man-in-the-middle attack is occurring—the keys you’re using are the same keys your conversation partner is using.

This is a security feature absent from Google Meet, Microsoft Teams, and even FaceTime. Those platforms ask you to trust their infrastructure implicitly. Magicall lets you verify the security of your call yourself, using mathematics rather than corporate promises.

For high-stakes conversations—legal consultations, medical discussions, business negotiations—this verification step takes ten seconds and provides guarantees that no amount of corporate trust policies can match.

Privacy by Architecture

We don’t record your calls or store call transcripts. Your conversations exist only in the moment, between the participants, and nowhere else.

We don’t analyze your conversations for advertising purposes, and we don’t train AI models on your data. Your words aren’t fuel for someone else’s machine learning pipeline.

We don’t sell or share your data with third parties. Full stop. This isn’t a policy decision that could change with new management or shareholders—it’s an architectural decision. With end-to-end encryption, we can’t access your call content even if we wanted to. The cryptographic keys are generated in your browser and never transmitted to our servers.

Symbolic Software is based in Paris, France. Our servers are hosted in the European Union. We’re fully GDPR compliant—not as a checkbox exercise, but because we believe privacy is a fundamental right.

There are no surprise data transfers to jurisdictions with weaker privacy protections. Your data stays in the EU, processed by an EU company, under EU law.

Why You Should Trust Us

This is a fair question. Why should you trust a video calling service from a company you might not have heard of?

Symbolic Software has spent nearly a decade building our reputation in applied cryptography. We’ve conducted over 250 security audits for organizations including Coinbase, Mozilla, 1Password, Bitwarden, NordVPN, ExpressVPN, Zoom, and Dashlane. Our founder has a PhD in formal verification of cryptographic protocols from Inria Paris, and has published research at IEEE S&P, USENIX Security, and other top academic venues.

We built Verifpal, a widely-used tool for formal verification of cryptographic protocols. We built Noise Explorer, which analyzes implementations of the Noise Protocol Framework. We built Kyber-K2SO, a clean implementation of the post-quantum key encapsulation mechanism that won the NIST competition.

When we say Magicall is built by cryptographers, we mean it. This is what we do.

Pricing

Magicall has two tiers:

Free (Forever)

The free tier gives you everything you need for secure video calling: end-to-end encrypted calls with up to 5 participants, 30-minute meetings that you can restart anytime, and a permanent room URL that’s yours to keep. You also get screen sharing, in-call chat, and waiting room controls to manage who joins your calls. No credit card required.

Pro ($4.99/month)

The Pro tier includes everything in Free, plus expanded capabilities for teams and power users. You can host calls with up to 256 participants and run meetings of unlimited duration. You get 5 room names instead of one, along with priority support. Custom branding and recording features are coming soon.

The free tier isn’t a trial. It’s not a limited-time offer. We believe everyone deserves access to secure, encrypted communication. The free tier has no time limit on the account, no credit card required, no strings attached.

30 minutes is plenty for daily standups, quick syncs, and 1-on-1s. If you need longer meetings or more participants, the Pro tier is there for you. If you don’t, the free tier will serve you indefinitely.

Alpha Launch

We’re calling this an alpha launch because that’s exactly what it is. Magicall works—we’ve been dogfooding it for months—but more users means more edge cases, and we’d rather be honest about that upfront. Found a bug? Tell us. Want a feature? We’re listening.

Try It Today

Claiming your room takes 30 seconds:

Your conversations are yours. They shouldn’t be training data for someone else’s AI. They shouldn’t be analyzed to show you better ads. They shouldn’t require everyone to own the same brand of devices.

We built Magicall because we believe video calling can be both simple and secure. Now it’s time to find out if others agree.

→ Try Magicall at magicall.online

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

Wed, 05 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 Cryspen 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 Cryspen 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 vulnerabilty 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é numerique 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 dorenavant 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 ajourd’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 recente 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 à legitimiser 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 deja (meme si sous une forme moins juridiquement encadrée) , a 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 sincrement que j’ai eu l’impression ce matin que mon général semble etre 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 a l’état en perpetuité.

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

Mon, 28 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 illustration 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 is 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 gene_rate 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 be in 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.

SinceSK1A 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 them 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 hypothetical own security conditions with 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!

Booking confirmed

Mon, 01 Jan 0001 00:00:00 +0000

Speak soon.

Thanks for booking a call. We're looking forward to learning more about what you're building. If there's any context you'd like to send ahead of the call, drop us an email at business@symbolic.software.

01 You'll receive a calendar invite within a few minutes. Check your spam folder if you don't see it.

02 On the call, we'll scope the work together — what you're building, what threat models matter, what your team is comfortable with.

03 If we agree on a fit, we send a written scope and timeline within a week.

← Back to home

Home — Symbolic Software

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

Why we built another HPKE library

The shape change: enum dispatch becomes type-state

Feature parity

Speed

KEM operations · X25519

Setup paths · sender / receiver / PSK

KEM operations · ML-KEM-768

KEM operations · ML-KEM-1024

KEM operations · X-Wing draft-06

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

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

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

Memory

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

KEM private key footprint · stack + heap, in bytes

Smaller

Project surface area

Harder

Interop

Migrate today

Get it

Announcing the Post-Quantum Migration Playbook

The Companion Scorecard

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

Passwords: From Static Tables to Verifiable Guesses

What Was Wrong

The New Model

Checked ASSERT? Now Actually Halts the Principal

AEAD_ENC No Longer Leaks Associated Data

TUI: Multi-Output Primitive Labels

New Models

Getting Verifpal 0.51.0

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

The Asymmetry Between KEMs and Signatures

Lattice Confidence Is Earned, Not Assumed

The Real Risk Is Complexity

Migration Friction Kills

Conclusion

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

How Hax Works

The Gaps and Their Exploits

E1: ML-DSA Rejection Sampling (Facade Gap)

E2: ML-KEM Barrett Overflow (Conditional Gap)

E3: Ed25519 Clamping (Facade Gap)

E4: ML-KEM SampleNTT (Facade Gap)

E5: ChaCha20 Rotations (Scope Gap)

Classification and Verification Results

The Full Picture

Recommending Post-Quantum Native Design Under Epistemic Duress

The Google Quantum AI Result

A Novel Disclosure Model

What the Proof Covers—and What It Doesn’t

The Risk Calculus Behind the Recommendation

The Harder Question: Epistemic Standards Under Pressure

What Should Happen Next

The Recommendation

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

What the Course Covers

How It Works

Who Should Apply

Certificate and Recommendation Letters

Why We’re Doing This

Looking for TAs

Apply

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

The Setup

The Results

Finding 1: Missing Encapsulation Key Modulus Check

Finding 2: Bouncy Castle Accepts Wrong-Length Decapsulation Keys

What About the Other 11 Implementations?

What This Means

Crucible Is Open Source

Summer 2026 Research Internship at Symbolic Software

What We’re Working On

Who Should Apply

Details

How to Apply

Cryspen's Approach to TLS: A Critical Analysis

Checked `ASSERT?` Now Actually Halts the Principal

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