Microsoft moves Lean-checked crypto proofs into SymCrypt production code

Microsoft has shown a workflow that verifies Rust implementations in SymCrypt against formal Lean specifications through the Aeneas toolchain. The first public branch includes code, specifications, properties and proofs for SHA-3 and ML-KEM, and Microsoft says the code is already used in Windows Insider builds.

SymCrypt now puts proofs next to the Rust implementation

SymCrypt is Microsoft’s open-source cryptographic library used across products including Windows and Azure Linux. The new post describes a path from a public standard to a Lean specification, from Rust code to a Lean model, and then to a proof that the implementation matches the mathematical description.

The practical detail is that Microsoft is not asking product teams to rewrite cryptography in a verification-specific language. Engineers write safe Rust, Aeneas turns it into a Lean model, and proof engineers prove the relation between that model and a standard-derived specification.

Formal verification is being pulled into the release workflow

For cryptography teams, the operating model matters as much as the theorem. Tests and audits still matter, but with algorithms such as ML-KEM, passing vectors is weaker than proving that every allowed input follows the standard, for example in an NTT transform over 256 coefficients in ML-KEM.

Microsoft also tackles the awkward part of production: optimized code, intrinsics and multiple architectures. The post describes x86-64 and aarch64 paths, including SSE2 and Neon, so verification does not stop at a clean reference implementation nobody actually ships.

Agents can draft proofs, but Lean keeps the stamp

The interesting AI angle is the boundary of authority. Agents may help translate standards into Lean specifications and write proof scripts, but Lean accepts the result only if the kernel verifies it. AI work becomes a proposal that must pass a deterministic checker.

The fragile point remains the specification layer. If humans formalize the standard incorrectly, or hide a too-strong assumption in a theorem statement, the proof can look green while protecting less than the engineering team believes.

Dashboards will decide whether the method survives code churn

Microsoft says developer-facing dashboards will expose preconditions, postconditions, covered functions, trusted models and remaining assumptions. That may matter more than the proof-agent demo, because developers need to see exactly what remains verified after a code change.

The next signal is breadth. SHA-3 and ML-KEM are a credible start, but the harder test comes with AES-GCM, FrodoKEM, ML-DSA and optimized paths where assurance meets performance and maintenance pressure.

Lilith's verdict

For cryptography, this is like attaching the inspection tag to the part Windows already installs: fewer safety promises, more checkable evidence.