magnetar/BLOCKERS.md

Magnetar --- Blockers

Honest enumeration of what is sound, what is open, and what was falsely marked closed.

Deployment model (the product decision)

Magnetar ships ONE construction to each of three deployment regimes:

Regime	Construction	Posture
Permissionless public-BFT (DEFAULT, production)	Per-validator standalone (standalone.go)	SOUND. Each validator holds its own FIPS 205 keypair, signs independently; consensus collects N signatures into a ValidatorAggregateCert. No DKG, no dealer, no reconstruction anywhere.
Trusted-hardware / custody (opt-in, production)	TEE-attested combiner pool (luxfi/threshold/protocols/slhdsa-tee)	SOUND under an explicit, honest trust model: the whole seed is reconstructed INSIDE a measured enclave on t hosts that must agree. This is TRUST-RELOCATION (it adds a host to the TCB), NOT MPC.
Permissionless threshold THBS-SE (RESEARCH-ONLY)	thbsse.go + thbsse_assemble.go + PVSS-DKG	RESEARCH-GRADE. The public combiner reconstructs the full FIPS 205 master every signature. Do NOT present as production or "no host in the TCB at sign time".

The hash-based-signature literature is unambiguous that this is fundamental (Cozzo-Smart EUROCRYPT 2019; Bonte-Smart-Tan 2023; NIST IR 8214): SLH-DSA has no aggregatable structure, so one FIPS 205-shaped signature from shares requires either reconstructing the seed at some party or full MPC over the SHAKE hash tree. Magnetar's PRIMARY production answer (per-validator standalone) sidesteps the dilemma by emitting N independent signatures.

OPEN --- MAGNETAR-STRICT-ATOM --- THBS-SE reconstructs the master

Status: OPEN. (Previously, and falsely, marked CLOSED.)

assembleSignatureBytes (thbsse_assemble.go) reconstructs the full FIPS 205 master at the public combiner: it Lagrange-interpolates the shares into derivedExpandInput, SHAKE-expands them into derivedMaterial (= skSeed || skPrf || pkSeed), and drives the FIPS 205 §5--§8 walk reading positional slices of that buffer (ASSEMBLE-INVARIANT.md). The whole private key is resident in the combiner's memory for one Sign call.

The earlier "strict-atom" closure was PROOF BY RENAME: the path avoids spelling a variable seed, and a name-grep test/lint (TestThbsSE_AssembleIdentHygiene, scripts/checks/strict-atom-ast.sh) enforces the spelling. Renaming the buffer does not change the data. The "CT" gate (ct/dudect/strict_atom_combine_ct_test.go) is likewise a name lint, not a timing measurement — and constant-time is the wrong property to claim for a path that holds the master in plaintext.

What IS true: the emitted signature is byte-identical to circl/slhdsa.SignDeterministic on the reconstructed master (a correctness/interop property, pinned by TestSlhdsaInternal_ByteEqualToCirclSign and TestThbsSE_StrictAtom_Combine_ByteIdentityToCircl). That is the only property the path delivers. It is NOT a no-leak property.

Closing it requires full MPC over the SHAKE hash tree (open research; multi-second, multi-megabyte per signature) or a TEE-attested host in the TCB (the opt-in pool below). The permissionless THBS-SE path stays RESEARCH-ONLY.

SOUND (with an honest trust model) --- TEE-attested combiner pool

The strict-PQ / custody regime routes Combine through a t-of-n attested-combiner pool in luxfi/threshold/protocols/slhdsa-tee/pool.go, gated by the single profile function magnetarRefuseUnderStrictPQ in luxfi/threshold/pkg/thresholdd/magnetar.go (mirrors the precompile contract.RefuseUnderStrictPQ discipline: ONE function, ONE place, ONE refusal sentinel slhdsatee.ErrMagnetarNoTEEAttestation).

Honest trust model. The seed is still RECONSTRUCTED in full — but inside a MEASURED ENCLAVE whose binary + firmware chain-validate to the vendor root (AMD KDS / Intel PCS / NVIDIA NRAS). t hosts must agree on the output. This is TRUST-RELOCATION: it moves the reconstruction from an untrusted public combiner into attested hardware, ADDING that hardware (and the attestation chain, and the t hosts) to the TCB. It is NOT MPC; no party is prevented from seeing the seed — the enclave sees it. Use it when you are willing to trust attested hardware; do not call it threshold cryptography that keeps the seed secret from every party.

Production attestation kinds. SEV-SNP is the only cc/attest verifier currently production-implemented. TDX / NRAS verifiers are stubs returning ErrNotImplemented (tracked at #222 stages 2--3); they wire through the same pool contract once shipped (an addition to CombinerPoolConfig.KnownIssuers, no magnetar-side change).

Pool policy defaults: Threshold = 2 (2-of-3 attested combiners), RotationWindow = 60s (per-member attestation freshness), KnownIssuers = {"amd.sev.snp"}.

Verification gates (BUILD + PASS under -race). As of the luxfi/zap bump to v0.3.1 in luxfi/threshold (which restores the NodeConfig.TLS field that pkg/thresholdd needs to build), the five gates build and pass under -race:

• TestMagnetarCombine_StrictPQProfile_RequiresTEE --- PASS (~77s)
• TestMagnetarCombine_AttestationVerified_AllowsSign --- PASS (~95s)
• TestMagnetarCombine_StaleAttestation_RejectsSign --- PASS (~128s)
• TestMagnetarCombine_TwoOfThreeAttestedCombiners_MatchSig --- PASS (~94s)
• TestMagnetarCombine_SignatureDivergence_HardRefusal --- PASS (~91s)

(ok github.com/luxfi/threshold/pkg/thresholdd ~487s under -race.) These gates exercise the profile refusal, attestation freshness, t-of-n agreement, and divergence-refusal logic. They do NOT change the trust model: the seed is reconstructed inside the enclave.

FIXED --- PVSS-DKG open-reveal leak (P2)

Status: FIXED for the production default; honest limits documented.

The earlier DKG ran in OPEN-REVEAL mode: RunDKGSimulation called RevealMsg() for EVERY party, and RevealMsg() publishes PolyCoeffs[b][0] = m_i. With every constant term public, the master M = Σ m_i was reconstructible by ANY observer of the transcript — not merely by t-1 colluding insiders. The "complaint-conditional reveal" was prose only.

The fix (pvss_dkg.go):

• Production entry RunDKG emits a transcript with Reveals == nil: no constant terms are published, so M is NOT reconstructible from the transcript. tr.RevealsMaster() is false. Regression-gated by TestPVSS_DKG_ProductionTranscriptHidesMaster (asserts production hides M, open-reveal reveals M, and the open-reveal path refuses without an explicit hazard ack).
• VerifyDKGTranscript dispatches on transcript type: the production (no-reveal) path verifies commitment shape + setup binding and qualifies well-shaped parties; the open-reveal path additionally verifies shares against published reveals.
• The leaking open-reveal simulation is renamed RunDKGSimulationOpenRevealTestOnly and gated behind a required AckOpenRevealRevealsMaster barrier (greppable, impossible to call by accident). It is TEST/KAT only.

Honest limits of the fixed production path (RunDKG HONEST LIMITATIONS in code):

1. PK derivation still reconstructs M. pk = SLH-DSA.PK(M) is a hash tree over M; there is no way to derive it from shares without reconstructing M somewhere (or TEE/MPC). deriveDKGPublicKey reconstructs M transiently to compute pk and zeroizes it. M is not published, but SOME party (whoever derives pk) holds it for an instant. "No party EVER holds M" is achievable only via the TEE or dealer paths. The earlier banner's "NO-MASTER-IN-MEMORY DISCIPLINE" (naming a buffer lagrangeScratch) was the same proof-by-rename and is corrected.

2. No robust malicious-dealer exclusion at DKG time. Hash commitments are not openable without revealing m_i, so a recipient cannot non-interactively verify a received share. The production path therefore does NOT exclude malicious dealers at setup; malformed shares are caught later at THBS-SE sign time (commit binding; TestThbsSE_RejectOversizedShareWireSize, TestThbsSE_RejectTamperedShareCommitMismatch) and via a complaint that reveals only the disputed recipient's share value. For adversarial committees, prefer the dealer path or the TEE pool.

Sound robust dealerless DKG would need group-homomorphic (Feldman / Pedersen) commitments or encrypted-shares + NIZK (proper Schoenmakers PVSS) — a separate construction, not attempted here.

OPEN --- Mechanized proofs (there are none)

There is NO mechanized proof of any Magnetar threshold property. The EasyCrypt/Lean "proof track" was vacuous (a headline theorem proved by apply-ing an axiom that restated it; lemmas of the form X = X; a CT lemma discharged by admit; a PVSS secrecy "theorem" with conclusion true) and has been deleted or reduced to explicitly-labeled scaffolds that prove nothing. See proofs/README.md and PROOF-CLAIMS.md. A genuine result (an abstract slh_sign model proven equal to the Go implementation) is multi-week work and is OPEN.

OPEN --- External cryptographer audit

No external audit. The internal sign-off (CRYPTOGRAPHER-SIGN-OFF.md) covers only the per-validator standalone primitive (sound) and explicitly does NOT bless the permissionless THBS-SE path as no-leak.

OPEN --- Cross-implementation FIPS 205 byte-equality

Byte-equality is checked only against cloudflare/circl. A cross-check against an independent FIPS 205 reference (pq-crystals C, BoringSSL when SLH-DSA lands) is a tracked gap (not yet done).

Cross-references

• README.md, DESIGN.md --- construction overview.
• ASSEMBLE-INVARIANT.md --- what the THBS-SE Combine path does.
• PROOF-CLAIMS.md --- per-property proven/asserted/open breakdown.
• TEE-INTEGRATION.md --- TEE-attested production surface spec.
• CHANGELOG.md --- release history.