saymrwulf/fips205-slhdsa-verified
1
0
Fork 0
mirror of https://github.com/saymrwulf/fips205-slhdsa-verified.git synced 2026-09-04 20:03:44 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

audit catch 2: the oracle boundary is FIVE, not six

Browse source 
The skeleton-era docs said 'six hash oracles' including prf — written
before the cone analysis showed prf/prf_msg are sign-side only. The
extracted model and FunsExternal carry exactly FIVE oracle axioms
(h_msg, f, h, t_l, t_len); the documented boundary now matches the
real one in README, TRUSTED-BASE, and extract.sh. Caught by the
post-flip drill's cross-consistency pass.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
mrwulf 2026-07-22 23:02:40 +02:00
parent 7acd4ec7c6
commit f1603bea87
3 changed files with 8 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
README.md
View file

@ -56,8 +56,9 @@ slh_verify -> slh_verify_internal
``` ```
Key generation and signing are out of scope (trusted base), exactly as Key generation and signing are out of scope (trusted base), exactly as
ed25519 signing was. The six hash oracles (`h_msg, prf, f, h, t_l, ed25519 signing was. The five verify-path hash oracles (`h_msg, f, h,
t_len` — SHA-2 instantiations) are opaque external models with written t_l, t_len` — SHA-2 instantiations; `prf`/`prf_msg` are sign-side only
and never enter the cone) are opaque external models with written
justifications, kept outside every certificate's dependency cone justifications, kept outside every certificate's dependency cone
(honesty invariant H4); their semantics are the standing SHA-2 oracle (honesty invariant H4); their semantics are the standing SHA-2 oracle
boundary documented in [TRUSTED-BASE.md](TRUSTED-BASE.md). boundary documented in [TRUSTED-BASE.md](TRUSTED-BASE.md).

5
TRUSTED-BASE.md
View file

@ -3,8 +3,9 @@
Initial statement, written at skeleton time (nothing proven yet); this Initial statement, written at skeleton time (nothing proven yet); this
file is maintained as the campaign proceeds and is part of every claim. file is maintained as the campaign proceeds and is part of every claim.
1. **The six hash oracles.** `h_msg, prf, f, h, t_l, t_len` 1. **The five verify-path hash oracles.** `h_msg, f, h, t_l, t_len`
(SLH-DSA-SHA2-128s instantiations over SHA-256) are modeled as opaque (SLH-DSA-SHA2-128s instantiations over SHA-256; `prf`/`prf_msg` are
sign-side only and do not appear in the cone) are modeled as opaque
functions with assumed functional behavior. Their correctness against functions with assumed functional behavior. Their correctness against
FIPS 180-4 is NOT proven here — the same standing boundary as SHA-512 FIPS 180-4 is NOT proven here — the same standing boundary as SHA-512
in the ed25519 apex. A collision or misimplementation inside the hash in the ed25519 apex. A collision or misimplementation inside the hash

4
verification/extract.sh
View file

@ -4,8 +4,8 @@
# SCOPE: the SLH-DSA verify path, parameter set SLH-DSA-SHA2-128s # SCOPE: the SLH-DSA verify path, parameter set SLH-DSA-SHA2-128s
# roots: slh_verify(_internal), fors_pk_from_sig, ht_verify, # roots: slh_verify(_internal), fors_pk_from_sig, ht_verify,
# xmss_pk_from_sig, wots_pk_from_sig, chain # xmss_pk_from_sig, wots_pk_from_sig, chain
# (sign/keygen are out of scope; the six hash oracles are opaque — # (sign/keygen are out of scope; the five verify-path hash oracles
# see TRUSTED-BASE.md.) # (h_msg, f, h, t_l, t_len) are opaque — see TRUSTED-BASE.md.)
# #
# Rust --charon--> SlhVerify.llbc --aeneas--> gen/SlhVerify/*.lean # Rust --charon--> SlhVerify.llbc --aeneas--> gen/SlhVerify/*.lean
# #