Skip to content

[SHA3] Lean verification proof#161

Open
abentkamp wants to merge 2 commits into
alex/sha3-verified2from
alex/sha3-verified3
Open

[SHA3] Lean verification proof#161
abentkamp wants to merge 2 commits into
alex/sha3-verified2from
alex/sha3-verified3

Conversation

@abentkamp

@abentkamp abentkamp commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

This PR provides a Lean equivalence proof connecting the hacspec-style sha3 specification to the libcrux-iot implementation. The implementations are proved equivalent up to the top-level SHA-3 and SHAKE functions (sha256_ema, etc.). The incremental API is not verified.

Most of the code has been generated by Claude.

The Readme at libcrux-iot/sha3/proofs/aeneas-lean/LibcruxIotSha3/README.md contains more information about the Lean verification.

One issue that I don't have a good solution for yet: The extraction works only with hax-evit, which must be reviewed by Evit before we are allowed to publish it. It will probably be public in 2-3 weeks.

@abentkamp abentkamp mentioned this pull request Jun 3, 2026
@abentkamp abentkamp force-pushed the alex/sha3-verified2 branch from 62b87e5 to f0328b1 Compare June 3, 2026 11:58
@abentkamp abentkamp force-pushed the alex/sha3-verified3 branch 3 times, most recently from ade135e to 205eebf Compare June 8, 2026 19:43
@abentkamp abentkamp changed the base branch from alex/sha3-verified2 to main June 8, 2026 19:49
@abentkamp abentkamp changed the base branch from main to alex/sha3-verified2 June 8, 2026 19:50
@abentkamp abentkamp force-pushed the alex/sha3-verified3 branch from 205eebf to 8ea00e8 Compare June 9, 2026 10:01
abentkamp pushed a commit to abentkamp/libcrux-iot-for-claude that referenced this pull request Jun 10, 2026
…dels

Ports the working proofs from `cryspen/libcrux-iot` PR cryspen#161
(`libcrux-iot/sha3/proofs/aeneas-lean/LibcruxIotSha3/{Composition/HacspecBridge,
Foundation/I32LoopSpec}.lean`) to the ml-kem tree.

The toolchain bump to Lean v4.30.0-rc2 brought a new
`CoreModels.core.iter.range.IteratorRange.next` body that uses
`cloneCloneInst` / `corecmpPartialOrdInst` field names (was `cloneInst` /
`partialOrdInst`) and threads `partial_cmp`'s output through `Result`
(was a plain `Option Ordering`). The two `IteratorRange_next_spec_*`
theorems we hand-wrote previously no longer typecheck, so they were
sorry'd in 1813afc.

New proof strategy mirrors PR cryspen#161: split on `i.val < e.val`, derive
an `h_eq` equation showing `IteratorRange.next … = .ok (…)` by unfolding
the partial_cmp + clone + forward_checked components, then close the
Hoare triple with `simp [Triple, WP.wp, PredTrans.apply]` and either
`exact h_lt …` or `exact h_ge …`.

Net delta: -2 sorries in `LibcruxIotMlKem/Util/LoopSpecs.lean`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant