Implement IHAT over P-256, cross-verified against the ihat-rs reference implementation

[OR13]

Implements IHAT over NIST P-256 in crypto::exp_ihat, behind an off-by-default feature, aligned byte-for-byte with ihat-rs — the reference implementation published in the MoLE org by Samuel Schlesinger, one of the draft authors. Renames the package to mole-exp with publish = false; the lib is still mole to import.

It follows code, not prose

The crypto draft is prose that names no group, no DST, and no wire structures. ihat-rs is executable with a canonical wire format. Where they disagree, ihat-rs wins — it is by an author, and interoperating with it is the only validation available since neither publishes test vectors.

Taken from it: P-256, SEC1 compressed Point[33], RFC 9380 P256_XMD:SHA-256_SSWU_RO_, hash_to_field for scalars, the four MOLE-IHAT-P256:<use>:v1 DSTs verbatim, Y = H₁(nf), a context-bound Pedersen generator, both Fiat–Shamir transcripts, and CDS 1-of-n for the OR proof.

Validation

Cross-verified in both directions. interop/ is a detached package pinned to an upstream revision: ihat-rs accepts presentations produced here and re-encodes them byte-identically, this crate accepts ihat-rs's, keys round-trip, and neither accepts a substituted accepted set.

Appendix A end to end with no mocks. interop/tests/appendix_a_end_to_end.rs pairs the profile with real RFC 9578 Privacy Pass credentials via privacypass — issuance, finalization, presentation, nonce checks on both layers, reissue. tests/appendix_a_flow.rs runs the same exchange on the profile alone, asserting issuer hiding at the protocol level and that the accepted set's order is load-bearing.

The library did not grow

Still #![no_std] on thumbv7em-none-eabi, still two dependencies (sha2, base64), still forbid(unsafe_code). exp-ihat adds one optional dependency, p256. The credential layer needed no Privacy Pass dependency at all — §5.2.1 has MoLE carry TokenRequest/TokenResponse opaquely, so the only addition is credential::reverse_flow::Token, a parser for the one RFC 9578 structure a Moderator must read to enforce §5.2.2. Structure only, no cryptography.

privacypass is std-only with an async issuer API, which is why it lives in the detached package and not here.

The one thing that cannot be reconciled

ihat-rs has no challenge_digest anywhere — not in a structure, not in a transcript, not in its API. So protocols §4.1.3's two MUSTs about binding it are satisfied by no implementation, including the authors' own. ChallengeBinding exposes both sides rather than picking silently:

Mode	Binds digest	Interoperates	Satisfies §4.1.3
IhatRsCompatible	❌	✅	❌ — replayable
MoleBound (default)	✅	❌	✅

Both are tested, including that they do not cross-verify.

Findings worth reporting upstream

Seven, indexed by #13. The sharpest:

• #8 — challenge_digest binding is implemented by no one
• #16 — §5.2.2's constant-digest requirement is unsatisfiable with a conformant RFC 9578 implementation: it cross-references §3.3, but the token's field is computed over an RFC 9577 TokenChallenge, which is never empty
• #9 — Anchor nonce reuse recovers the secret key, and no draft says so. Deterministic nonces, the usual advice, are the dangerous choice here
• #11 — no session identifier on the wire in any of the four grant messages

Plus: upstream PR #39 contradicts ihat-rs on point encoding, the Pedersen generator, and the OR-proof construction.

Still not deployable

ihat-rs states it has not been audited. The construction has no security proof and no public cryptanalysis. Interoperability is agreement, not correctness — if the construction is flawed, both implementations are flawed identically.

Verification

111 tests plus 7 in the detached package. Clippy pedantic, rustdoc, fmt clean; no_std on thumbv7em-none-eabi with and without the profile; MSRV 1.75 builds and tests --locked. Four CI jobs, including the cross-verification and end-to-end run.

🤖 Generated with Claude Code

[OR13]

Update: switched from ristretto255 to P-256

Aligned the profile with the group the drafts point at. This removed inventions rather than adding them — four things that were this crate's choices are now the specification:

	before	now
Group	ristretto255 (ours)	P-256, per the crypto draft
Point[33]	32-byte ristretto + a 0x00 tag byte	genuine SEC1 compressed point
Hash-to-curve	hand-rolled expand_message_xmd(SHA-256) + ristretto map	RFC 9380 P256_XMD:SHA-256_SSWU_RO_
Scalar derivation	SHA-256 widened to 64 bytes, our width	RFC 9380 hash_to_field, 48 bytes by the spec
Pedersen generator	our "pedersen-H" label	Hash2Curve("IHAT second generator"), PR #39's literal string

The clearest win is Point[33]: a compressed SEC1 P-256 point is exactly 33 bytes, so the protocols draft's opaque Point[33] is now the encoding rather than something we pad to fit. The tag-byte hack is gone.

SHA-256 stopped being a preference and became the specification — P256_XMD:SHA-256_SSWU_RO_ expands with SHA-256 internally, and hash_to_field for P-256 expands to 48 bytes before reduction, so the draft's H "whose output length is sufficiently long" is satisfied by construction.

Worth recording: the original argument for ristretto255 was curve25519's cofactor 8 against three stacked sigma protocols. P-256 has cofactor 1, so that argument was moot for the drafts' actual curve.

Correction

The crypto draft's {{DLEQ}} reference has always been I-D.draft-irtf-cfrg-sigma-protocols, not RFC 9497 as an earlier analysis in this work claimed. It never reached an issue body or the code, but it understated how much specified machinery the draft already pointed at — which is why #4 turns out to be much closer to closed than it first looked.

What is still open

Six items, and two of them are now deliberate deviations from things upstream PR #39 does specify rather than gaps:

• Upstream: the two MoLE drafts disagree on point compression #1 — the two MoLE drafts disagree on point compression (Point[33] vs bytes[65]), and the group is named only by a forward reference the architecture draft does not satisfy (it contains no group instantiation at all).
• exp-ihat: no hash-to-curve suite string or domain separation tag is specified #2 — no DST upstream; ours now name the suite per RFC 9380 §3.1 convention.
• exp-ihat: H is only "a hash function whose output length is sufficiently long" #3 / exp-ihat: Fiat–Shamir transcript encodings are unspecified #4 — e = H(Y, Zhat, T1, T2, C) is the one hash left outside any framework; the profile does not yet use the SHAKE128 sponge and P-256 codec of draft-irtf-cfrg-fiat-shamir. Held because PR #39 is unmerged and this pulls in two further CFRG drafts.
• Upstream: C' is used before it is defined #5 — C' is still used before it is defined.
• exp-ihat: OR proof is now specified as a one-of-N trapdoor commitment tree; our CDS is a deviation #6 — textbook CDS OR proof rather than PR #39's one-of-N trapdoor commitment tree, held because that PR carries its own TODO saying the construction may be replaced.
• exp-ihat: m is typed as a Scalar, which cannot carry endorsement_context #7 / Upstream: challenge_digest binding (4.1.3) is implemented by no one #8 — upstream contradictions: m typed as Scalar cannot carry endorsement_context, and challenge_digest appears in no structure or challenge. Following the crypto draft here would produce something that cannot satisfy protocols §4.1.3 at all.

Verification

102 tests (profile up from 12 to 14 — new ones assert SEC1 compressed encoding with both parities occurring, and that the identity is refused rather than truncated into a 33-byte lookalike). Clippy pedantic, rustdoc, fmt clean; no_std on thumbv7em-none-eabi with and without the profile; MSRV 1.75 --locked.

CI green: run 30393126931.

[OR13]

Update: aligned with ihat-rs — and it interoperates

The MoLE org publishes ihat-rs, a reference implementation by Samuel Schlesinger, one of the draft authors, with a canonical wire format. I should have checked the org's other repos before inventing parameters — several of the things filed as unguessable were already decided in code.

The profile now follows code rather than prose. Where ihat-rs and the crypto draft disagree, ihat-rs wins: it's executable, it's by an author, and interoperating with it is the only validation available since neither publishes test vectors.

It cross-verifies, both directions

interop/ is a detached package (git dependency; Cargo can't make dev-dependencies optional) pinned to an upstream revision. Four tests:

• ihat-rs parses and accepts our presentations for every issuer in a four-Anchor set, and re-encodes them byte-identically
• we parse and accept ihat-rs's, recovering the same nullifier and context
• Anchor keys round-trip both ways
• neither accepts a substituted accepted set

That converts the crate's worst remaining problem — no test vectors, so correctness unverifiable — into differential testing against the authors' own code. Stronger than vectors: it exercises both roles. New CI job runs it.

Two real defects this found in our own code

1. or_prove leaked the issuing Anchor. It branched on the secret index (if i == real_index { continue; }) — data-dependent control flow and memory access on exactly what issuer hiding conceals. ihat-rs is explicitly constant-time here ("no control flow depends on it"), recovering the honest base with a subtle select across the whole accepted set. Now rewritten to match.

2. Our Fiat–Shamir transcript followed the draft, which is weaker than the author's code. Draft: e = H(Y, Zhat, T1, T2, C). ihat-rs also binds X̂ and endorsement_context, commenting that this is "strengthened to bind the full statement: the rerandomised key X_hat — so a proof cannot be transported to a different X_hat". Now matched.

Also removed: a redundant 64-byte DLEQ proof per grant ((T1', T2', r') already is one — finalize checks Y'r' = Z'e'a' + T1' and Gr' = Xe'a' + T2'), and the invented m concatenation.

Adopted from ihat-rs

The four DSTs verbatim — MOLE-IHAT-P256:<use>:v1, which closes #2 outright — plus Y = H₁(nf), a context-bound Pedersen generator H(endorsement_context), the CDS OR-proof wire form, and two-byte big-endian VarBytes framing.

PR #39 contradicts the reference implementation in three places

Worth reporting upstream:

	PR #39	ihat-rs
Point encoding	uncompressed bytes[65]	compressed 33 (agrees with protocols §4.1)
Pedersen generator	global Hash2Curve("IHAT second generator")	per-context H(endorsement_context)
OR proof	O(log n) trapdoor commitment tree	O(n) CDS

The one thing that cannot be reconciled

ihat-rs has no challenge_digest anywhere — not in a structure, not in a transcript, not in its API. Its verifier docs say a presentation "verifies every time". So protocols §4.1.3's two MUSTs about binding it are satisfied by no implementation, including the authors' own.

Rather than pick silently, ChallengeBinding exposes both sides:

Mode	Binds digest	Interoperates	Satisfies §4.1.3
IhatRsCompatible	❌	✅	❌ — replayable
MoleBound (default)	✅	❌	✅

Both tested, including that they don't cross-verify, and a test that asserts compat mode accepts an unrelated digest — so the deficiency is visible rather than latent.

Issues

Closed #2 (DSTs), #3 (hash), #7 (m doesn't exist). #1, #5, #6 narrowed to upstream contradictions. #8 is now the sharpest finding in the tracker. #10 largely superseded. #13 has the full before/after.

Correction

{{DLEQ}} resolves to draft-irtf-cfrg-sigma-protocols (§2.2.8 is the DLEQ statement), not RFC 9497 as I said earlier. Recorded on #4.

Verification

109 tests + 4 interop. Clippy pedantic, rustdoc, fmt clean; no_std on thumbv7em-none-eabi with and without the profile; MSRV 1.75 --locked. CI green, all four jobs: run 30394911541.

cargo doc caught a bare [DLEQ] citation during this work — the same failure class that reddened CI at the start of the day, which is why it stays in the check list.

Still not deployable

ihat-rs says of itself: "This code has not been audited." Interoperability is agreement, not correctness — if the construction is flawed, both implementations are flawed identically.

[OR13]

Update: Appendix A now runs on real cryptography

tests/appendix_a_exp_ihat.rs walks the same exchange as appendix_a_flow.rs, but the endorsement half runs on exp_ihat instead of insecure_mock — and the grant bodies travel inside the real EndorsementRequest/EndorsementResponse envelopes rather than placeholders. Seven tests.

Two say something the mock version couldn't:

• the_moderator_cannot_tell_which_anchor_issued — issuer hiding asserted at the protocol level: every Anchor in the accepted set can issue, presentation size is invariant to which one did, and what the Moderator ends up holding is an epoch it already knew plus a nullifier.
• the_accepted_set_order_is_load_bearing — a permutation of the accepted set does not verify. That's what makes §4.1.3's normative branch ordering real rather than decorative.

One deliberate behavioural change

A redemption bound to another challenge now fails with VerificationFailed, not the mock's ChallengeMismatch. With real cryptography the Moderator genuinely cannot distinguish "wrong challenge" from "invalid proof" — the OR proof just fails. That's the better outcome: §8 warns that redeem's distinct error variants must not be surfaced to Clients, and here there's nothing to surface.

CI

Strengthened the MSRV job from cargo build to cargo test. Clippy's incompatible_msrv lint caught a split_at_checked (stable 1.80) in the new test code; running the tests on 1.75 catches that class directly instead of relying on a lint.

116 tests + 4 interop, all four jobs green: run 30396614290.

What's left

The credential half still uses a stand-in token. That is now the only fake cryptography in the reachable protocol surface — Longfellow needs libzk plus an out-of-band circuit, ACT is expiring upstream, and key rotation and the config format are TODO. in the draft.

[OR13]

Appendix A now runs with no mocks at all

The credential half was the last fake cryptography in the reachable surface. It's real now — and the std constraint turned out to be avoidable.

The boundary was in a better place than I thought

§5.2.1 has MoLE carry TokenRequest and TokenResponse opaquely — it defines no structures for them, and this crate already defined no wrappers. So the library needs no Privacy Pass dependency at all. It needed exactly one thing it was missing, and the real integration belongs where interop/ already lives.

No std feature. No async in the library. Dependency count still two (sha2, base64), still no_std on thumbv7em.

Library addition

credential::reverse_flow::Token — a parser for the RFC 9578 Token structure (token_type, nonce, challenge_digest, token_key_id, authenticator), plus TOKEN_TYPES and authenticator_len. Structure only, no cryptography.

It's there because a Moderator cannot enforce either of §5.2.2's two requirements — constant digest, unseen nonce — without reading those fields, and until now it had no way to do that short of taking a full Privacy Pass dependency. Five unit tests, including that a known token_type with the wrong Nk is malformed, that an unknown type with any non-empty authenticator is accepted (a Moderator may be configured with a type this crate predates), and that truncation never panics.

End to end, nothing mocked

interop/tests/appendix_a_end_to_end.rs: real IHAT endorsements over P-256, real RFC 9578 Privacy Pass via privacypass — issuance, finalization, presentation, nonce checks on both layers, and reissue of the update. Three tests, including that a real token cannot be spent twice and that mole's parser and privacypass's serializer agree byte-for-byte on the Token layout.

privacypass is std-only with an async issuer API, which is precisely why it lives out there.

A fourth cross-document contradiction — #16

Found by doing this; it doesn't surface any other way.

§5.2.2 says the token's challenge_digest MUST equal the Moderator's constant challenge_digest, cross-referencing §3.3 — MoLE's SHA-256(challenge octets), which for this type is SHA-256("").

That is unsatisfiable. The token's challenge_digest is computed by RFC 9578 as SHA-256(TokenChallenge), and an RFC 9577 TokenChallenge always carries a token_type and a non-empty issuer_name — so it can never digest to SHA-256(""). It would need a preimage. Two different fields share one name and the MUST tries to equate them.

The test takes the workable reading: one fixed TokenChallenge per Moderator, constant across every token it issues — which is the property the surrounding text actually asks for ("This binds the token to the Moderator, not to the exchange that presents it"). Nothing is weakened; §5.2.2 is explicit that anti-replay comes from the nonce being single-use, and that's enforced and tested on both layers.

This is the cheapest of the upstream findings to fix — a cross-reference removal and one sentence.

Verification

121 tests + 7 in the detached package. Clippy pedantic, rustdoc, fmt clean; MSRV 1.75 builds and tests --locked; library no_std on thumbv7em with and without the profile. All four CI jobs green: run 30397603087.