WOTS+ chains recomputed on every sign + missing slot range validation

[jiayaoqijia]

Summary

xmss_sign regenerates the WOTS secret key from seed on every call, recomputing all WOTS+ chains (294 extra Poseidon hashes per signature). Additionally, xmss_key_gen does not validate that slot_end < 2^LOG_LIFETIME.

Severity

MEDIUM -- Performance and validation gap.

Location

WOTS+ chain recomputation:

• crates/xmss/src/wots.rs:32-37 -- WotsSecretKey::new computes iterate_hash(&pre_images[i], CHAIN_LENGTH - 1) for all V chains
• crates/xmss/src/xmss.rs:142-145 -- xmss_sign regenerates the WOTS secret key from seed on every call

Missing slot validation:

• crates/xmss/src/xmss.rs:53-60 -- xmss_key_gen checks slot_start > slot_end but not slot_end < 2^LOG_LIFETIME

Impact

Performance: Signing latency includes 294 unnecessary Poseidon hash invocations per operation (V=42 chains of length CHAIN_LENGTH=8, so 42 * 7 = 294). Acceptable for single-slot signing but becomes a bottleneck in batch signing scenarios.

Validation: With LOG_LIFETIME=32 and u32 slots, the range is naturally bounded by the type. However, if LOG_LIFETIME were reduced for testing or alternative configurations, slots could exceed tree capacity silently.

Suggested Fix

WOTS+ caching: Cache WOTS secret keys in the XmssSecretKey struct:

pub struct XmssSecretKey {
    // ... existing fields ...
    wots_cache: HashMap<u32, WotsSecretKey>,
}

Slot validation: Add explicit range check:

if slot_end >= (1u64 << LOG_LIFETIME) as u32 {
    return Err(...);
}

References

• Full audit: https://github.com/jiayaoqijia/eth2030/blob/master/docs/plans/lean-vm-audit.md
• Findings: F-11, F-16

[lau90eth]

Looked into both parts of this issue against current main:

Slot range validation (part of F-11) already appears to be enforced: xmss_key_gen rejects slot_end >= 2^LOG_LIFETIME (and slot_start > slot_end) with XmssKeyGenError::InvalidRange, and xmss_sign rejects slot < slot_start || slot > slot_end with XmssSignatureError::SlotOutOfRange. Looks like this half is already resolved; might be worth closing/updating that part of the issue.

One micro-note, not worth a separate PR: in xmss_sign, find_randomness_for_wots_encoding runs before the slot-range check, so an out-of-range slot still pays for randomness search before being rejected. Low-impact since slot isn't attacker-controlled in the intended usage, but free to fix if touching that function anyway.

WOTS+ chain recomputation (F-16): within this repo, xmss_sign is only ever called once per slot (tests, and the benchmark signer cache) — I couldn't find a call site here where the same slot signs more than once. If downstream clients (ream, zeam, ethlambda, etc.) call sign() multiple times for the same slot in a single duty cycle (e.g. attestation + block in the same slot), the caching win is real; otherwise this is optimizing a path that isn't hot in practice.

If the multi-call-per-slot pattern is confirmed downstream, worth flagging that the unbounded HashMap<u32, WotsSecretKey> suggested in the issue is itself a memory-growth vector across LOG_LIFETIME slots — a single-entry memoization of "most recently computed slot" would capture the same-slot-reuse case without unbounded growth, and is a much smaller change to review. Happy to put that together if someone can confirm the call pattern client-side.