pereq - Blog

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 Cryspen, 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, Cryspen 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. Cryspen 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 Cryspen 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. Cryspen 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 Cryspen, 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 Cryspen 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, Cryspen 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 Cryspen had towards this effort, leaving deeper technical details to a future publication.

Analyzing the SPQR Protocol Design

In our previous analysis of PQXDH, Cryspen 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 Cryspen can help you with your cryptographic protocol design or software verification, email us.