saymrwulf/fips205-slhdsa-verified
1
0
Fork 0
mirror of https://github.com/saymrwulf/fips205-slhdsa-verified.git synced 2026-09-03 19:53:49 +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
ed25519 signing was. The six hash oracles (`h_msg, prf, f, h, t_l,
t_len` — SHA-2 instantiations) are opaque external models with written
ed25519 signing was. The five verify-path hash oracles (`h_msg, f, h,
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
(honesty invariant H4); their semantics are the standing SHA-2 oracle
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
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`
(SLH-DSA-SHA2-128s instantiations over SHA-256) are modeled as opaque
1. **The five verify-path hash oracles.** `h_msg, f, h, t_l, t_len`
(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
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

4
verification/extract.sh
View file

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