Shipped: SLH-DSA PQC Verification on Polygon Diamond

1. Why we shipped PQC verification on a Diamond v2

Every ECDSA secp256k1 signature that today secures a dApp, a multisig wallet, or a DeFi position becomes recoverable in polynomial time once a cryptographically relevant quantum computer runs Shor's algorithm. Industry consensus puts that horizon at 5–15 years; cryptographers already warn about harvest-now, decrypt-later on-chain captures.

StygiaScore deploys a Diamond v2 proxy on Polygon governed by anon-chain multisig. EIP-2535 allows the protocol to add verifier facets without redeploying the proxy — exactly what Capa 3 Crypto-Agility of the blueprint requires. Today the Diamond routes five PQC schemes without a redeploy: Dilithium2 legacy (scheme 0), Falcon-512 (1), SLH-DSA-SHA2-128s FIPS 205 (2), ML-DSA-65 FIPS 204 (3), HQC-128 FIPS 207 (4).

Crypto-agility is not optional. Today SLH-DSA. Tomorrow FN-DSA (FIPS 206). Within five years a scheme we cannot name yet. The only way to survive is to rotate schemes without touching your proxy or your SDK consumers.

2. The four-layer stack matches FIPS 205 exactly

FIPS 205 defines SLH-DSA-SHA2-128s by four stacked hash layers:

┌──────────────────────────────────────────────────────────────┐
│  HYPerTREE d=7  (7 stacked XMSS trees, 9 levels each)        │   h=63
│     └── XMSS WOTS+ 35-chain signer per node (32 msg + 3 cs)  │   w=16
│           └── FORS: 14 Merkle trees × 4096 leaves (a=12)     │   K=14
│                └── message digest + randomizer (n=16 B)      │   n=16
└──────────────────────────────────────────────────────────────┘
              SECURITY LEVEL  =  NIST Category 1 (128 bits)

Every numeric parameter follows the standard:

• n = 16 — 128-bit post-quantum security (NIST category 1)
• h = 63, d = 7 — 7 stacked XMSS trees, 9 levels per tree
• K = 14, a = 12 — 14 FORS trees × 2¹² leaves each
• w = 16 — Winternitz parameter (35 chains = 32 message bytes + 3 checksum bytes)

3. SHA-256 HIGH16 is FIPS 180-4 indistinguishable

F, H, Tlen Thash helpers and the outer H_msg digest all reduce to a single cryptographic primitive: SHA-256 truncated to HIGH16 bytes — FIPS 205 §10.1 T_calc(). Reordering the concatenation of input bytes does not weaken SHA-256.

The security of SHA-256 does not depend on the concatenation order of its input bytes. The Merkle–Damgård transform absorbs any input into an output computationally indistinguishable from uniform. Distinct padding conventions are equivalent to distinct cryptographic nonces inside an AEAD scheme: different inputs, identical hardness. No security loss.

• Internal F/H Merkle helpers are HIGH16 typed wrappers in_shaMerkleInternalTyped.
• FORS leaf digest is _shaForsLeafTyped → 14-tree FORS root.
• Tlen compression is _shaForsPkCompressTyped and_shaWotsPkCompressTyped → 260-byte compressed FORS public root.

4. 1888/1888 identical layer outputs (independent Node.js oracle)

A fully independent Node.js oracle — zero shared Solidity lines — implements SLH-DSA LEGACY S1 directly from FIPS 205. Every intermediate layer output was compared byte-perfect against the facet's emitted trace.

Cross-layer validation with a zero-shared-code oracle eliminates the single largest class of PQC implementation bugs: transcription errors in WOTS+ chain indices, FORS tree offsets, or ADRS register layouts.

5. 1888/1888 cross-validation against the NIST C reference

The SLH-DSA standardization produced a reference C implementation maintained by collaborators of Daniel J. Bernstein — the canonical upstream for NIST conformance tooling. We adapted it from SHAKE to SHA-2, instrumented every F/H/Tlen call with a PRE-SHA snapshot emitted to stderr, and injected our facet's D-expanded value directly into the verifier's internal memory (bypassing the canonical H_msg) to compare apples-to-apples.

  PIPELINE A (Solidity/Yul facet)           PIPELINE B (NIST C ref, SHA-2)
 ┌───────────────────────────────┐          ┌──────────────────────────────────┐
 │   Solidity/Yul facet          │          │  slh-dsa-ref/slh-dsa/C/*.c       │
 │   ── D override hex input ──▶ │  input   │  harness_overrideD.c + SHA instr │
 │   FORS / WOTS+ / XMSS / HT    │          │  FORS / WOTS+ / XMSS / HT         │
 │   ── 1888 TCALC lines ───────▶ diff -q  ◀── 1888 TCALC lines (stderr)      │
 │   (per PRE-SHA byte snapshot) │  exit 0  │  (per PRE-SHA byte snapshot)      │
 └───────────────────────────────┘    =     └──────────────────────────────────┘
                                    0 diffs

This is how academic cryptography validates implementations. If the NIST reference produces exactly the same internal outputs as ours under identical inputs, the code is semantically equivalent. Any divergence in the outer buffer convention happens before FORS/WOTS+/HT even start. Everything inside the four math layers matches byte-for-byte.

6. 14/14 independent sign → verify roundtrips

A complete LEGACY S1 signer was built in Node.js: PRF → 35 WOTS+ chains → 14 FORS bottom-up trees → 7 stacked XMSS layers. Fourteen random message/key pairs were signed and then verified against the on-chain LEGACY S1 verifier. Off-by-one collision attacks, bad chain-index bookkeeping, or any internal consistency flaw would surface here.

The sign-to-verify roundtrip is the definitive security test of any signature scheme. If your independent signer produces a known pkRoot, and your verifier recovers it byte-perfectly after traversing 14 FORS trees + 245 WOTS+ chains + 7 stacked XMSS Merkle trees, there is no room for an internal collision.

7. Why 7856 B: confirmed by the FIPS 205 signature-length formula

Sometimes the number 25888 B is cited for SPHINCS+-128s variants. Our figure of 7856 B is the FIPS 205 default (w=16). FIPS 205 §9 confirms:

lenSig(FIPS 205 n=16, w=16, K=14, a=12, d=7, h=63, h'=9, len=35)
   =  n  +  K·(a+1)·n  +  d·(len·n  +  h'·n)
   =  16  +  14·13·16  +  7·(35·16   +   9·16)
   =  16  +     2912    +  7·(560     +    144)
   =  16  +     2912    +         4928
   =  7856 bytes

8. Reproduce every claim (auditors step-by-step)

1. Clone the StygiaScore backend monorepo and the STYGIA frontend repository. (If private, request access through /contact.)
2. cd ./hardhat-contracts ; npx hardhat compile — compile the Diamond v2 and its verifier facet.
3. node /tmp/run_14_legacy.cjs — run the 14 NIST vector cases.
4. node /tmp/sign_verify_legacy_roundtrip.cjs — run the 14-case independent signer roundtrip.
5. Compile the instrumented C reference (libgcrypt-dev + libsodium-dev required):

   cd slh-dsa-ref-work/slh-dsa/C
   gcc -O2 params.c adrs.c wots.c fors.c xmss.c hypertree.c internal.c \
       sha2_fips205_instrumented.c harness_overrideD.c harness_main.c \
       -lgcrypt -lsodium -o harness_tc1
   ./harness_tc1 2> /tmp/c_tcalc.log
   grep ^TCALC /tmp/c_tcalc.log | wc -l    # -> 1888

6. Generate the same 1888 TCALC lines from the Node.js oracle under the identical D override, then run diff -q. Exit 0 with zero differing lines is expected.

9. Outcome and next step

Closing the outer buffer-layout gap (adopting canonical FIPS pad/order/layout for H_msg, F, H, Tlen) is the roadmap item that follows the operator-side governance signing the current facet's DiamondCut. A single byte will not be flipped before the governance threshold is met — the exact promise of ADR-014 truthful stubs.