quip-crypto-primitives: HKDF info is not suite-separated (two SHRINCS suites from one seed share a tree)

[rcarback]

Code location: the quip-crypto-primitives crate and BABE integration in the QuipNetwork polkadot-sdk fork (branch v0.2). Issues are disabled on that fork, so this is filed here on the consuming protocol repo.

Summary

quip-crypto-primitives derives component seeds with a fixed HKDF info (b"pq" and b"classical") that does not vary by hybrid suite. Two different suites derived from the same master seed get the same pq_seed and the same classical seed. For the lattice suites this is a key-reuse concern that domain separation at signing time covers in practice. For the proposed stateful hash-based suites (H5 = ed25519+SHRINCS, H6 = sr25519+SHRINCS) it is worse. An identical pq_seed yields a byte-identical SHRINCS signing key. Two independent signers then operate one stateful Merkle tree, reuse its one-time leaves, and compromise the key.

Detail

• HKDF_PQ_INFO = b"pq" and HKDF_CLASSICAL_INFO = b"classical", fixed for every suite — quip/primitives/crypto/src/seed.rs:16-40 (path on branch v0.2).
• derive_component_seeds(master_seed) returns the same pq_seed for H5 and H6 (and for H1/H3). SHRINCS keygen(pq_seed, maxSignatures) is deterministic, so H5 and H6 from one master seed share stateful_sk_seed, stateful_prf_seed, the leaf secrets, stateful_root, and the commitment.
• Each signer keeps its own leaf counter starting at 1 and advances it independently. When H5 signs message A at leaf 1 and H6 signs a different message B at leaf 1, two messages share one WOTS-C one-time leaf. Two signatures under one one-time leaf yield a forgery that breaks the SHRINCS component, and the composite drops to classical-only security with no signal.
• The ordinary one-master-seed backup pattern triggers this.

Fix

Bind the construction's suite label and profile into the HKDF info for both components:

classical_seed = HKDF-Expand(prk, info = "classical/" ‖ Label, L = 32)
pq_seed        = HKDF-Expand(prk, info = "pq/"        ‖ Label, L = 32)

with Label the construction's registry label such as hybrid-sr25519-shrincs-256s-v1. A SHRINCS key then becomes a function of (master_seed, suite, profile, maxSignatures), and two suites cannot map to one tree.

Found during the SHRINCS-hybrid spec review (companion to hybrid signature spec v2.0, section 9). H5/H6 are proposed and not yet implemented, so there is no current deployed exposure — but the derivation should be suite-separated before any stateful suite merges.

[rcarback]

Confirmed against code while triaging the hybrid-spec v2.0 doc gaps: the fixed-info HKDF gap this issue tracks is live H1↔H3 exposure today, not only a future H5/H6 hazard.

Findings (polkadot-sdk fork, branch v0.2, quip/primitives/crypto):

• derive_component_seeds (src/seed.rs:24-41) expands every suite's master seed with HKDF-SHA256, salt b"hybrid-sig", fixed info b"classical" / b"pq" — no suite label enters derivation. Suite labels (hybrid-ed25519-mldsa44-v1 / hybrid-sr25519-mldsa44-v1) bind only the signing domain via prepare_message.
• Both Ed25519MlDsa44::from_seed_slice and Sr25519MlDsa44::from_seed_slice route through the same expansion (suite/ed25519_mldsa44.rs:169-170, suite/sr25519_mldsa44.rs:181-182 → fixed.rs:330-340), and ML-DSA keygen is deterministic from the shared 32-byte pq_seed (pq/mldsa44.rs:36-38). One master seed therefore yields byte-identical ML-DSA-44 key material for H1 and H3. The classical halves differ (ed25519 vs sr25519 expansion), so it is lattice key-reuse across suites, not full key collision.
• No fix has landed on this path (seed.rs unchanged since its introduction in f1f8d40c8a).
• quip-protocol-rs has no second derivation site; transaction-crypto-core delegates to Sr25519MlDsa44::from_seed_slice.

Spec side is already covered: hybrid-spec v2.0 §9 REQUIRES suite-bound info (info = "classical/" ‖ Label / "pq/" ‖ Label) and §22 tracks this issue as the implementation gap.

Suggested scope broadening for this issue: include the current H1↔H3 shared-ML-DSA-material exposure alongside the H5/H6 framing (where fixed info is catastrophic via tree collision). Note the fix is derivation-breaking for existing seeds — it needs a derivation epoch or a one-time testnet rekey plan.

[linear]

QUI-893

QUI-924