pereq - Blog

Developer-driven Rust verification using hax, Lean, and AI

2026-10-12T00:00:00+00:00

As announced in our recent blog post, hax 0.4 has a new Lean backend that relies on Aeneas. In this post, we describe how we used this new backend to verify the SHA-3 implementation in libcrux-iot, an IoT-friendly cryptographic library developed by CE Labs. Our goal was to find out how close we are to a workflow in which a Rust developer without any knowledge of Lean can verify their own code using hax and AI.

The results of the project are publicly available in this GitHub repository.

Of course, we are not the first to prove the correctness of a SHA-3 implementation. We previously verified libcrux’s SHA-3 using hax and F*. Just this year, Apple verified their assembly and C implementations of SHA-3 using a combination of SAW and Isabelle. Microsoft verified a Rust implementation of SHA-3 also using Aeneas and Lean.

What distinguishes the hax approach is that we try to model as much as possible in Rust: the specification is in Rust, and even our models of the Rust core libraries are written in Rust. This allows a Rust developer with no knowledge of Lean to test and review the specifications, assumptions, and target theorems. They can then use hax to generate the Lean, invoke their favorite AI agent to fill in the proofs, and run Lean to verify that the proofs are complete.

The workflow that we followed for SHA-3 is depicted below. The developer works on the red (Rust) parts; the blue (Lean) parts are generated by hax and AI, and checked by Lean.

An IoT-friendly implementation of SHA-3

The libcrux-iot library is a collection of cryptographic algorithms implemented in Rust and targeted at IoT devices and other embedded systems that have low memory and operate on simple (32-bit or smaller) processors. Specialized implementations help to cope with these constraints.

In SHA-3, for example, a central data structure, the lane, is not implemented as a 64-bit integer, as is usually the case. Instead, libcrux-iot uses two 32-bit integers, with all of the even-numbered bits going into one 32-bit integer and the odd-numbered bits into the other, which allows the procedure to be executed more efficiently on 32-bit processors.

The main permutation of SHA-3 consists of 24 rounds of transformations on an internal state, and each round requires an additional working copy of the internal state. The libcrux-iot implementation instead operates fully in-place to save memory, by reorganizing accesses to the internal state such that its layout conforms to the specification only every 4 rounds.

These optimizations make the implementation look very different from the specification.

Specification in Rust

The NIST FIPS 202 standard specifies the SHA-3 algorithm in pseudocode. To be able to verify our implementation against it, we used AI to transcribe SHA-3 into Rust, staying as close as possible to what’s described in the FIPS 202 standard. We call this Rust specification pedantic_sha3.

For example, here is how the standard describes ρ, one of the internal permutation functions used by SHA-3. It permutes the state array, a 5×5×w array of bits, for some constant w that determines its size.

Here is the corresponding part of our Rust specification:

/// Algorithm 2: `ρ(A)`.
pub fn rho<const W: usize>(a: &StateArray<W>) -> StateArray<W> {
    let w = W as i64;
    let mut out = StateArray::<W>::zero();

    // 1. For all z, A′[0, 0, z] = A[0, 0, z].
    for z in 0..W {
        out.a[0][0][z] = a.a[0][0][z];
    }

    // 2. Let (x, y) = (1, 0).
    let (mut x, mut y) = (1usize, 0usize);

    // 3. For t from 0 to 23:
    for t in 0..24i64 {
        // a. A′[x, y, z] = A[x, y, (z - (t+1)(t+2)/2) mod w].
        let offset = (t + 1) * (t + 2) / 2;
        for z in 0..W {
            out.a[x][y][z] = a.a[x][y][imod(z as i64 - offset, w)];
        }
        // b. (x, y) = (y, (2x + 3y) mod 5).
        let (nx, ny) = (y, (2 * x + 3 * y) % 5);
        x = nx;
        y = ny;
    }
    out
}

By comparing them side by side, the developer can check that the specification reflects the standard. Moreover, the Rust specification is executable, so we can increase our confidence by extensive testing. We test the properties stated in the FIPS 202 standard itself, run NIST’s CAVP vectors, and compare with other implementations on random inputs, including a C reference implementation.

An issue we encountered while writing the Rust specification is that Rust arrays are limited to a theoretical maximum of usize::MAX elements (only actually reachable using zero-sized types), which is reflected in hax’s Lean model of Rust arrays. The limit applies to both the implementation and the Rust specification, but there are several reasons why the Rust specification should allow arbitrary lengths:

FIPS 202 does not impose any limits on the length of the processed messages.
The Rust specification appends, following FIPS 202, a suffix and padding to the input message, whereas the implementation packs these things more efficiently. So the implementation can handle slightly longer inputs than the specification.
We would like to use the same Rust specification to also verify the incremental API of SHA-3, which can in theory accept inputs of arbitrary length.

To resolve this, we implemented a special Rust type BitStr for arbitrary-length bitstrings and a special Rust type Nat to hold the length of such a bitstring. In Rust, these are simply wrappers for Vec<u8> and u128, and when executed they have the same limitations as before. But for verification, we exclude their definitions from extraction to Lean and instead define their Lean models to be Lean’s List Bool and Lean’s Nat. So the resulting Lean semantics are exactly what FIPS 202 describes: arbitrary-length bit strings.

Linking the implementation to the specification

To state the correspondence between our implementation and our specification, we use the Rust annotations hax_lib::requires and hax_lib::ensures. For example, for sha256, one of the top-level API functions of the SHA-3 crate, this annotation looks as follows:

#[hax_lib::ensures(|out| out.declassify()[..]
    == pedantic_sha3::bytes::sha3_256(payload.declassify_ref())[..])]
pub fn sha256(payload: &[U8]) -> [U8; SHA3_256_DIGEST_SIZE]

The function computes a 256-bit hash of a given payload.

The hax_lib::ensures-annotation states that the annotated function sha256 does not panic and computes the same value as our specification pedantic_sha3::bytes::sha3_256. The signatures of these two functions differ slightly: The implementation uses a custom integer type U8 that ensures that we use only constant-time integer operations (on the Rust side; not part of the Lean verification). That is why we need to convert U8 into u8 using .declassify() and .declassify_ref(). We must use the “[..]” to work around the fact that hax’s model of Rust core is currently missing the PartialEq implementation for comparing a Vec with an array.

SHA3-256 with an externally allocated buffer

The top-level API functions all come in an external-memory-allocation variant such as sha256_ema. They require the user to provide a digest slice, into which the function writes its output. We annotate it as follows:

#[hax_lib::requires(digest.len() == SHA3_256_DIGEST_SIZE)]
#[hax_lib::ensures(|_| future(digest).declassify_ref()
        == &pedantic_sha3::bytes::sha3_256(payload.declassify_ref())[..])]
pub fn sha256_ema(digest: &mut [U8], payload: &[U8])

The hax_lib::requires-annotation specifies that the digest slice must have the expected length. Otherwise, our verification makes no claims about what the function might do.

The hax_lib::ensures-annotation states the same property as above, but for future(digest), which represents digest’s value after the function has run.

These annotations are the theorems we prove. They are written in Rust, refer only to Rust code, and are what a developer needs to review to know what has been verified.

Extraction to Lean

Implementation, specification, and annotations all get translated via hax into Lean, where we can finally prove that the equivalences hold. For this translation, hax’s new Lean backend uses Aeneas under the hood. For example, the specification’s sha3_256 is defined in Rust as follows:

pub fn sha3_256(m: &BitStr) -> BitStr {
    keccak_c(
        512,
        &m.concat(&BitStr::from_bits(&HASH_SUFFIX)),
        Nat::new(256),
    )
}

hax (via Aeneas) translates this into the following Lean function:

def sha3.sha3_256 (m : bits.BitStr) : RustM bits.BitStr := do
  let s ← lift (Array.to_slice sha3.HASH_SUFFIX)
  let bs ← bits.BitStr.from_bits s
  let bs1 ← bits.BitStr.concat m bs
  let n ← nat.Nat.new 256#u128
  sponge.keccak_c 512#usize bs1 n

The developer does not need to read this code; we show it only to illustrate what hax produces.

Changing the code to aid verification

In a few cases, we had to change the implementation itself to make the Lean extraction work. Most of these changes (e.g., issues with mutability, name clashes) are no longer needed because we fixed lots of bugs both in Aeneas and in hax before releasing hax 0.4. We still have issues with code containing string formatting (e.g., derive(Debug)) and with some unverified parts of the crate (Digest and Hasher impls); these are excluded from extraction.

Another issue we encountered was that the original code contained a couple of functions with 400+ lines of code. While extraction works and proofs are feasible in principle, iterating on these proofs takes too long. Our solution is to use ordinary Rust refactoring to split these functions into smaller ones:

Using hax’s new CLI features

hax 0.4 comes with a lot of handy CLI features, and we have started to use them in this project

Previously, we used Bash or Python scripts to pin tool versions and to keep track of the exact command-line arguments they needed to be invoked with. This has become much simpler now.

The specification and the implementation are two crates in a shared Cargo workspace. To pin hax to version 0.4.2, we added the following lines to the workspace’s Cargo.toml:

[workspace.dependencies]
hax-lib = { version = "=0.4.2" }

[workspace.metadata.bin]
cargo-hax = { version = "0.4.2", bins = ["cargo-hax"], locked = true }

Along with hax, this also pins the versions of all the tools and libraries that hax uses under the hood. All that remains to be installed manually is Cargo, cargo-run-bin, and Lean (more specifically Lean’s version manager elan).

To be able to call hax via cargo hax instead of cargo bin cargo-hax, we added the following to .cargo/config.toml:

[alias]
hax = ["bin", "cargo-hax"]

To configure hax extractions, hax 0.4 now supports a hax.toml file. This project’s hax.toml currently contains only two short entries, one for the SHA-3 specification and one for the implementation:

[scenario.pedantic-sha3]
package = "pedantic-sha3"
backend = "lean"

[scenario.libcrux-iot-sha3]
package = "libcrux-iot-sha3"
backend = "lean"
output-dir = "../proofs"

If special options were needed to make the extraction work, we could specify them in this file.

Verification with AI assistance

In Lean, we then proved that the extracted implementation is equivalent to the extracted specification, as stated by the extracted annotations.

The proof uses an intermediate specification of SHA-3 in pure Lean. It proves both the extracted specification and the extracted implementation equivalent to this Lean specification. Finally, it composes these two equivalences to prove the overall correctness theorem.

The proofs were developed almost entirely by AI, with limited human guidance. The proofs are around 15,700 lines long, excluding comments and blank lines. None of this Lean code needs to be reviewed by the developer. The intermediate specification and the proofs are not trusted: Lean checks them, and what they establish is stated by the Rust annotations.

The initial proof development took around a week. We reworked the proof many times: to account for small changes in the implementation, new hax developments, new Lean versions, and changes to the Rust specification. Using AI, keeping up with these changes was surprisingly simple. Even adapting the proofs to a completely different Rust specification took only a couple of hours. Lean played a crucial role here: the fast turnaround and detailed feedback provided by the proof assistant allow the AI agent to easily fix proofs. From our work on verifying libcrux with F*, we have noticed that F* proofs are much harder to maintain, even with AI.

Sometimes, however, the AI got stuck at seemingly simple obstacles.

When Claude Opus 4.7 got stuck

In one situation, Claude Opus 4.7 got stuck because a simp lemma failed to trigger. The underlying reason was a type mismatch in an expression of the form

lift_lane_bv a0 a1 ^^^ lift_lane_bv b0 b1

where both sides were of type BitVec 64 in the simp lemma and of type BitVec U64.numBits in the goal. While U64.numBits is defined as 64, this definition is irreducible, which is why the simp lemma does not trigger. The ^^^-notation hides the mismatch a little, but for a human Lean expert, it’s trivial to hover over the notation and see the underlying issue. In principle, the AI should have the means to find the issue via the Lean MCP server as well.

When Claude Fable 5 got stuck

Even more recent models can go wrong, as shown by the following example, which we encountered using Claude Fable 5 during our work on the verification of ML-KEM, which builds on top of SHA-3. Currently, hax’s hax_lib::implies predicate does not support lazy evaluation. That is, an expression hax_lib::implies(A,B) can panic, even when A evaluates to false. This is a problem because we cannot write expressions like

#[requires(forall(|k| implies(k < a.len(), a[k] <= bound)))]

Here, the array access a[k] can panic when k is too large, and it is modeled to panic even when the condition k < a.len() evaluates to false. A simple workaround is to write

#[requires(forall(|k| if k < a.len() { a[k] <= bound } else { true }))]

For some reason, Fable 5 failed to come up with that workaround and proposed using the following instead:

#[requires(
    let mut ok = true;
    for k in 0..a.len() {
        ok &= a[k] <= bound;
    }
    ok
)]

This formulation would have been much harder to prove properties about.

Note that the fix here is a change to a Rust annotation, which a Rust developer can spot and make without any Lean knowledge. The Opus 4.7 case, by contrast, needed genuine Lean expertise.

Next steps

This verification of SHA-3 still has many limitations and room for improvement:

Not all top-level API functions have been verified. In particular, we did not verify the incremental API (either buffered or unbuffered), and we did not verify the Digest/Hasher implementations. Also, secret independence is only ensured through Rust type mechanisms, not through Lean.
Our proofs do not rely on any non-standard Lean axioms, but we’d like to also run comparator to rule out that the AI proved something other than what we stated. This is currently blocked on a Lean upgrade.
hax does not currently support multi-crate extractions, so the plumbing between implementation and specification crates in Lean is done by hand.
The hax model of Rust core is still missing a few items that we need in our SHA-3 specification. We currently model them ourselves.

We also see room to improve the proof approach taken by the AI agents. The Lean code generated by hax is designed to be processed by Lean’s verification condition generator mvcgen, but the AI mostly bypassed it: it opened up the monad that hax uses to model Rust computations and worked directly with tactics like rw, simp, omega, and decide. Using mvcgen throughout would separate proofs of panic freedom from proofs of functional correctness, and might make the intermediate Lean specification unnecessary. We expect that more detailed, hax-specific proof skills for the AI will lead to cleaner and more maintainable proofs in the future.

Conclusion

So can a Rust developer without any Lean knowledge verify their own code using hax and AI? For SHA-3, almost. The libcrux-iot code itself was written by Rust developers with no Lean background, and verifying it required only modest Rust-level changes. The verification, admittedly, was carried out by a Lean expert, but for the most part, the steps that need human judgment happen in Rust: specification, contract annotations, modifications of the source code. Lean expertise is still needed in a few places: to fill in missing models, connect multiple crates, and help the AI with the few proofs where it got stuck. We are now working on improving hax to close these gaps. Stay tuned for hax 0.5!

Hax 0.4!

2026-10-01T00:00:00+00:00

The world of mathematics has been shaken by an earthquake: LLMs can now generate large Lean developments autonomously: Navier-Stokes solution, FLT proof, and many more. The narrow stream of proof-work has the potential to open into a free-flowing river.

This offers a promise for software verification: what used to require multi-year effort by skilled teams might become more broadly available, provided that the flow can be tamed into useful ways, that is, that formal verification toolchains adapt and improve.

We’ve been updating and improving hax, our Rust verification framework, to leverage this newfound potential. With Rust being a popular choice for AI-written code, and with Lean seeing rapid adoption and tooling investment, we believe our Rust-to-Lean pipeline could play a key role in improving confidence in many critical codebases.

We’re proud to announce the 0.4 release of hax.

TLDR: We improved hax to:

have a greater reach by expanding its support for the Rust language
be more broadly accessible to users

This new release achieves that through:

the collaboration with Aeneas as our new engine for the Rust→Lean pipeline
a new streamlined installation and setup

For more technical details on the release, see the companion post on the hax blog. You can also try hax online!

Adopting Aeneas for the Lean backend

Hax was from the beginning thought of as a multi-backend tool, i.e. targeting several proof assistants, even though historically, F* was our preferred option. We added a new Lean backend over the course of 2025, which gave us interesting insights and promising results.

While the collaboration with the Aeneas team, which started at Inria, was still ongoing on the frontend side of hax and Charon, we decided in early 2026 to pivot and directly use the Charon+Aeneas pipeline as the translation engine for our Lean backend. Since then, we’ve been increasing our collaboration, contributing bug fixes and improvements.

While the Charon+Aeneas pipeline was made available in 0.3.7, the 0.4 release makes it officially our main Lean backend. This increases support for Rust, notably functions returning mutable borrows. Here is an example from the OpenMLS codebase, one of our ongoing proof efforts, that was previously rejected by our engine:

pub fn node_mut(&mut self) -> &mut Option<ParentNode> { ... }

Functionalizing calls to such a function, say let x = n.node_mut(), is non-trivial: it requires inserting “backward functions” at the end of the lifetime of x to “update” the value of n. Those backward functions must be computed from the code and inserted at the right locations. This is the role of the Aeneas translation.

The hax workflow

Proving properties of Rust code is not only about translation. This release also packages various extensions to Aeneas, to support the key design choices and workflows of the hax way:

a strong library of Rust-written models for core/std/alloc
a set of macros for writing specs directly in the code
and use of Lean’s built-in mvcgen tactic as our main proof framework

All tools verifying Rust code have to handle its dependencies: compiler intrinsics, core/std/alloc libraries. Often, it is done by providing a hand-written model directly in the prover, say Lean for instance. This is usually error-prone, hard to audit, hard to extend and backend-specific. To solve those issues, we’ve been developing a Rust-written library of models for core. They are easily extensible, backend-agnostic, and heavily tested against their real core counterparts. Those models rely on a small, well-defined set of primitives that have to be modeled in the library of each backend. We’re very excited about the progress there; we’ll cover it in more detail in an upcoming post.

A key part of the hax methodology is the collocation of code and specs: we encourage writing the specs alongside the code, directly in Rust (when applicable). We extended Aeneas with preliminary support for those (restricted to pre/post on standalone items for now). This eases review and sync of code and proofs.

Finally, we decided to adopt the mvcgen tactic as our entry point for actual proofs. We believe in using standard, community-backed tools as much as possible. The development speed of mvcgen is astonishing, and we’ve already used it in large-scale proofs with great success.

A streamlined installation and setup

A key friction point for formal verification tools is usually installation, setup, and maintenance. With this release, hax 0.4 is available directly with cargo install cargo-hax (or via a binary installation). Once installed, hax handles the other dependencies (Charon+Aeneas) seamlessly for the user, via the versatile command cargo hax tools (fetching the binaries, managing versions, etc.). See the manual for more details.

All the relevant settings for verification can now be stored in a single, version-controlled, crate-level file hax.toml. In that file, the user can define proof scenarios, with a specific backend, that target a subset of the crate. This is key to enabling extensible verification, or to target different properties with different backends.

Trust & assumptions

Hax makes assumptions, and there are certainly bugs in the hax codebase or in dependencies. We aim to document our trusted computing base, publish in open-source and test our toolchain comprehensively. Notably:

Hax depends on open-source tools (Cargo, rustc, Lean, F*, Aeneas) that are backed and scrutinized by a community. Hax 0.4 targets Lean v4.31.0, which has some known soundness bugs. Upgrading the Lean version is planned for the next release.
We rely on our modeling of Rust primitives and our core models being faithful to the rustc implementation. We mitigate the risk of mismatch by heavily testing them.
Issues can hide in the overall workflow: flawed specs, excluded code, ignored theorems, etc. We are building tools to surface the TCB for every hax project.

We welcome feedback and findings to continuously improve the trustworthiness of the toolchain.

Conclusion

Hax 0.4 is a pivotal moment for pereq*, leveling up to the challenges ahead. The next release will contain a new ProVerif backend, increase overall robustness and improve proof engineering.

For more details on hax 0.4, look at the companion blog post on the hax blog, the docs, or the hax repo.

Stay tuned for hax 0.5!

EIC Transition: Spectrum

2026-06-25T00:00:00+00:00

We are excited to have been awarded a Transition Grant from the European Innovation Council to build a specification and verification toolkit that developers can use to build and deploy provably-secure software. The project is called Spectrum and it builds on our hax open-source framework.

In the coming months, we will describe how we and our customers use the Spectrum tools on a daily basis to design and implement security-critical systems. If you would like to know how Spectrum can help you, get in touch.

Get in touch

Software Verification in Lean

2026-04-22T00:00:00+00:00

This week in Paris, pereq* is delighted to be co-hosting Software Verification in Lean 2026, a workshop and associated hackathon organized by the Beneficial AI Foundation and the Lean FRO.

SVIL 2026 brings together leading researchers and practitioners working on using the Lean proof assistant to formalize and verify real-world software. On Monday, I gave a talk on the challenges of verifying cryptographic applications, and the opportunities that are being opened up by the rapid innovations in Lean and by the emergence of AI-assisted formal proofs.

SVIL 2026 is initiating several exciting new collaborations. On Monday, BAIF and Lean FRO announced the Signal Shot, a challenge to the community to formally verify the Signal protocol and Signal app. Pereq intends to contribute our tools and our expertise to this effort, in collaboration with our colleagues in the Aeneas team.

If you want to learn more about how pereq can help you build ambitious software with strong security and correctness guarantees, reach out to us.

Formally Specifying and Testing the Rust Standard Library

2025-10-28T00:00:00+00:00

Modern programming languages typically come with a large standard library that implements essential language features like machine arithmetic and I/O, offers efficient data structures, provides interfaces to system libraries, etc. Although it is often overlooked, this standard library should be considered as much part of the trusted computing base (TCB) as the language compiler. Indeed, any bug in the standard library is likely to break applications and could result in security vulnerabilities.

Recognizing this concern, the Rust community has initiated an effort to formally verify the Rust standard library. Pereq* is participating in this project, and as our first contribution, we proposed and implemented a new methodology to formally specify and test the platform-specific SIMD functions in the Rust core library. These functions are used in a variety of performance-sensitive Rust applications, including cryptographic libraries like libcrux.

Modeling Rust’s `core::arch` library

The core::arch library in Rust provides a number of platform-specific functionalities, including wrappers for specific machine instructions. In particular, it provides functions corresponding to the single-instruction-multiple-data (SIMD) instructions provided by different vectorized architectures such as Intel’s AVX, AVX2 and AVX-512, and Arm’s Aarch64/Neon.

To model the behaviour of each SIMD instruction in a testable manner, we essentially write a reference implementation of the function in Rust based on the instruction’s documentation.

There are three kinds of SIMD intrinsics in core::arch.

The first kind are builtin Rust compiler intrinsics, some of which are in the intrinsics/simd.rs file in the core crate, and others are in the simd.rs file of core_arch. These builtin intrinsics define generic SIMD operations that the Rust compiler knows how to implement on each platform.

The second kind are extern intrinsics that are links to definitions in LLVM. See, for example, this list of extern intrinsics used in the Intel x86 AVX2 library. These extern intrinsics are typically platform-specific functions that map to low-level instructions.

The third kind are defined intrinsics that are given proper definitions in Rust, and their code may depend on the builtin intrinsics or the extern intrinsics. These defined intrinsics represent higher-level operations that are wrappers around one or more assembly instructions.

For builtin and extern intrinsics, we need to define reference implementations ourselves, but for defined intrinsics, we have a choice: we can either define a completely independent model of the intrinsic based on its documentation, or we can copy and adapt the implementation provided in the Rust core library and treat it as a reference implementation. If our goal is to check the Rust core library, it is always better to write a fresh model that can serve as the official specification. Conversely, deriving models from the Rust library implementations allows us to quickly obtain models for a large class of functions, and these models accurately reflect what Rust does in practice, which is useful when analyzing Rust programs that use these intrinsics. We need to balance this tradeoff based on our goals, and here, we only derive models for intrinsics whose bodies are shallow wrappers around builtin or extern intrinsics.

An Example: `_mm256_bsrli_epi128`

For example, let us say the intrinsic we are modeling is _mm256_bsrli_epi128 from the Intel AVX2 feature set.

The official Intel documentation of this function provides a textual description:

Shift 128-bit lanes in a right by imm8 bytes while shifting in zeros, and store the results in dst.

It also provides pseudocode for the instruction:

tmp := imm8[7:0]
IF tmp > 15
	tmp := 16
FI
dst[127:0] := a[127:0] >> (tmp*8)
dst[255:128] := a[255:128] >> (tmp*8)
dst[MAX:256] := 0

Based on this pseudocode, we can write a model for the function, interpreting the 256-bit vector type __m256i as an array of two 128-bit integers (i128x2):

pub fn _mm256_bsrli_epi128<const IMM8: i32>(a: i128x2) -> i128x2 {
	i128x2::from_fn(|i| {
	    let mut tmp  = IMM8%256;
	    if tmp > 15 {tmp = 16}
	    ((a[i] as u128 ) >> (tmp*8)) as i128
	})
    }

However, in the Rust core library, this is a defined intrinsic, and when we began our project, this intrinsic was implemented as shown here. Notably, the implementation aims to be efficient by branching over the shift value (tmp) and implementing the shift using byte-level shuffling operations, presumably because this is faster than using a shift instruction.

We now have two different interpretations of the same instruction, a model that follows the Intel documentation and an implementation that aims to be efficient. Since both these functions are executable, we can test them against each other.

Testing the Model agains the Rust Core library

We use the standard Rust testing framework to run a large number of tests for each intrinsic we model against the same intrinsic in the Rust core library. For convenience, we implemented a set of macros that allows us to generate random tests for large inputs and comprehensive tests for small inputs.

For the _mm256_bsrli_epi128 function above, we test it for all values of IMM8 from 0 to 256 (since the Intel pseudocode only looks at the bottom 8 bits), and for a 100 random bitvectors representing the a vector (the number of tests is configurable). For each input, we test whether our model returns the same output as the Rust core. Often, this process reveals bugs in our hand-written models, where we may have misinterpreted the Intel or Arm documentation.

In the case of _mm256_bsrli_epi128 our tests revealed a bug in the Rust core library. When the value of tmp in the pseudocode above is greater than 15, instead of setting the value to 16 as specified by Intel, the Rust core implementation set it to tmp % 16. This bug can be seen on this line. As a result, the tests fail for values of IMM8 above 15.

A similar bug affects _mm512_bsrli_epi128.

We opened an issue in the Rust stdarch repository, reporting this bug, along with the precise tests that fail. This helped the Rust developers quickly agree on the bug and accept our fix, which has since been upstreamed.

Testable Models for the Rust SIMD Intrinsics

In total, we formally specified 384 intrinsics for x86 platforms, 181 intrinsics for aarch64, and tested these specifications against the Rust core library. In the course of this testing, we found and fixed bugs in two intrinsics in the Rust library.

Our challenge to Verify Rust Std: Challenge 15
Our solution to the challenge: Testable Models for SIMD Intrinsics
The bug we found in the Rust SIMD libraries: Bug, Fix

This work was done as part of Aniket Mishra’s Internship at pereq, and is part of a larger project to formally specify the Rust core and std libraries in a way that can be used in formal proofs of Rust programs in hax.

If you want to learn more about how we test and verify Rust libraries, get in touch.

Helping Secure Signal's Post-Quantum Transition

2025-10-02T00:00:00+00:00

Signal just announced the deployment of their new post-quantum ratcheting protocol, called the Sparse Post-Quantum Ratchet (SPQR), and pereq* is proud to have contributed to the formal analysis of the design and implementation of this new Signal feature.

The seeds of our collaboration with Signal reach back to 2023, when Signal first published PQXDH, the post-quantum key establishment protocol that marked the beginning of Signal’s post-quantum transition. We helped Signal to formally analyze and improve PQXDH, resulting in a paper at Usenix Security. This time, pereq and Signal agreed to collaborate from the very beginning of the design process for SPQR all the way through to its implementation.

The Signal blog post wonderfully describes SPQR and the role formal verification played in its design and implementation. Here, we will briefly note three contributions pereq had towards this effort, leaving deeper technical details to a future publication.

Analyzing the SPQR Protocol Design

In our previous analysis of PQXDH, pereq collaborated with Charlie Jacomme at Inria and Rolfe Schmidt at Signal to build formal models of the protocol that could be analyzed symbolically by ProVerif and verified computationally by CryptoVerif.

For SPQR, we decided to build models in ProVerif, because the protocol engineers found it easy to read and write ProVerif, and the fully automatic tool provided quick and reliable feedback on each design. We helped Signal engineers write the initial models, but they were able to modify and maintain these models as the protocol underwent a series of revisions until it reached its final form. Using formal verification in this organic way allows protocol designers to quickly try out new ideas, checking if a design change breaks a desired security property. When all the protocol details are settled, the final model can be comprehensively verified for all desired security goals.

The ProVerif models for SPQR are maintained in the SPQR repository and are verified as part of CI.

Providing Post-Quantum Cryptography

The SPQR implementation uses our libcrux implementation of the ML-KEM post-quantum key encapsulation mechanism. Our Rust implementation is formally verified for panic-freedom, functional correctness, and secret independence, and hence provides a high degree of assurance.

Interestingly, Signal’s SPQR design required a novel incremental API for ML-KEM, different from the ones usually provided by crypto libraries. At the request of the Signal developers, we implemented this new API in libcrux and helped them integrate it into the SPQR implementation. See our PR for details on the incremental API, and see this test to understand how to use the API.

Verifying the SPQR Implementation

As the design of SPQR matured, the Signal team started implementing it in Rust. At this stage, we collaborated with them to build a formal verification pipeline for their implementation using hax and its F* proof backend. We helped verify the new code for panic-freedom and some correctness goals.

The hax verification scripts are hosted on the SPQR repository. They run in CI and flag errors whenever a code change breaks some expected invariant and might (say) cause a panic at runtime. These proofs only cover the core of the new SPQR code, and formally verifying the full Signal codebase is still some distance away, but it is already exciting to see how formal proofs like these can be maintained and extended by Signal engineers in the normal course of their work.

This experience taught us a lot about real-world code verification and resulted in several improvements to hax and to our models of the Rust libraries. We are excited to continue collaborating with the Signal team to cover more of the Signal codebase and verify it for more ambitious correctness and security properties in the future.

To learn more about how pereq can help you with your cryptographic protocol design or software verification, email us.

pereq - Blog

Developer-driven Rust verification using hax, Lean, and AI

An IoT-friendly implementation of SHA-3

Specification in Rust

Linking the implementation to the specification

SHA3-256 with an externally allocated buffer

Extraction to Lean

Changing the code to aid verification

Using hax’s new CLI features

Verification with AI assistance

When Claude Opus 4.7 got stuck

When Claude Fable 5 got stuck

Next steps

Conclusion

Hax 0.4!

Adopting Aeneas for the Lean backend

The hax workflow

A streamlined installation and setup

Trust & assumptions

Conclusion

EIC Transition: Spectrum

Software Verification in Lean

Formally Specifying and Testing the Rust Standard Library

Modeling Rust’s core::arch library

An Example: _mm256_bsrli_epi128

Testing the Model agains the Rust Core library

Testable Models for the Rust SIMD Intrinsics

Helping Secure Signal's Post-Quantum Transition

Analyzing the SPQR Protocol Design

Providing Post-Quantum Cryptography

Verifying the SPQR Implementation

Modeling Rust’s `core::arch` library

An Example: `_mm256_bsrli_epi128`