warp/TRUSTED-COMPUTING-BASE.md

TRUSTED-COMPUTING-BASE — Lux Warp TCB Inventory

What you must trust below the warp implementation. Companion document to SUBMISSION.md, PROOF-CLAIMS.md, and CRYPTOGRAPHER-SIGN-OFF.md.

The Warp envelope soundness claim (PROOF-CLAIMS.md §1) rests on three layered trust bases:

1. Cryptographic primitives — separately audited modules.
2. Implementation TCB — the runtime + standard library + build tooling.
3. Operational TCB — the operator's environment + key custody.

If any element of the TCB is compromised, warp's soundness claim is unsound regardless of how well-implemented the envelope verifier is.

§1 Cryptographic primitive TCB

Primitive	Module	What you trust	Audit ref
BLS12-381 aggregate (Beam)	github.com/luxfi/crypto/bls	supranational/blst constant-time correctness; co-CDH hardness	blst upstream audit + LP-075
ML-DSA-65 single-party	github.com/luxfi/crypto/mldsa (Cloudflare CIRCL backend)	NIST FIPS 204 spec text; CIRCL implementation correctness; MLWE / MSIS hardness	NIST FIPS 204 (August 2024) + CIRCL audit
SLH-DSA single-party	github.com/luxfi/crypto/slhdsa (Cloudflare CIRCL backend)	NIST FIPS 205 spec text; CIRCL implementation correctness; hash-function security	NIST FIPS 205 + CIRCL audit
Pulsar threshold (R-LWE)	github.com/luxfi/pulsar	Pulsar Class N1 byte-equality theorem; R-LWE / Ring-SIS hardness; jasmin-ct constant-time	~/work/lux/pulsar/CRYPTOGRAPHER-SIGN-OFF.md
Corona threshold (R-LWE)	github.com/luxfi/corona	Corona implementation correctness; R-LWE hardness; dudect constant-time	~/work/lux/corona/CRYPTOGRAPHER-SIGN-OFF.md
legacy-Keccak256 (digest D / envelope IDs)	golang.org/x/crypto/sha3 (NewLegacyKeccak256)	Keccak256 correctness; second-preimage resistance; byte-match with the EVM keccak256 opcode	NIST FIPS 202 (Keccak)
Pulsar hash suite ("Pulsar-SHA3")	crypto/sha3 (Go x/crypto), inside luxfi/pulsar / luxfi/corona	Go x/crypto SHA-3 correctness; standard Keccak preimage resistance	NIST FIPS 202

§2 Implementation TCB

Layer	What you trust	Reproducibility
Go toolchain	Go 1.26.4 compiler + runtime; crypto/rand randomness quality	Version pinned in go.mod (go 1.26.4)
warp/zap.go (in-package)	ZAP canonical-TLV codec: fixed-width BE ints, u32-framed varbytes, trim-canonical bitset, trailing-byte rejection	This module; KAT-locked; fuzz-tested (FuzzZapReader)
golang.org/x/crypto/sha3	NewLegacyKeccak256 for the digest D	Go x/crypto; pinned by FIPS 202
luxfi/geth/common	common.Hash 32-byte helper	go-ethereum upstream; reviewed
luxfi/ids	32-byte ID type + SHAKE-256 derivation	Reviewed; pinned by FIPS 202
luxfi/log	Structured-log emission (no secret material)	Reviewed; warp emits only public envelope metadata
luxfi/pq	The single posture gate pq.ValidateMode + pq.Mode enum	This module; the entire gate is 16 lines (gate.go)
luxfi/lattice	R-LWE polynomial arithmetic backend for Pulse byte layout	Reviewed (lattigo fork)

The implementation TCB is intentionally small. Warp's root package imports no networking, no consensus, no chain state. The verification path is a pure function of (envelope bytes, validator-set snapshot, mode) → (nil | error).

§3 Build TCB

Layer	What you trust	Reproducibility
go.mod dependency pins	Every transitive dep is pinned by hash in go.sum	GOWORK=off go mod verify runs clean
scripts/kat/envelope_kat.json	KAT vectors regenerate deterministically from cmd/envelope_kat_oracle/	GOWORK=off go run ./cmd/envelope_kat_oracle/ produces byte-identical JSON across hosts
Makefile	Build orchestrator's correctness — reproducible across hosts	Reviewed; no host-specific paths
CI	GitHub Actions runs the test suite + KAT regen on every PR	Pinned action versions in .github/workflows/

§4 Operational TCB

Layer	What you trust	Mitigations
Validator key custody	Operator's HSM / KMS for BLS / ML-DSA / threshold-share material	Not warp's responsibility; operator runbook in DEPLOYMENT-RUNBOOK.md
Source-chain validator set integrity	Source chain's consensus protocol + slashing rules	Inherited from luxfi/consensus; out of scope for warp
Destination-chain validator-set registry	Destination chain's record of source-chain GroupKey lineage	Implemented as a contract; pulsar.GroupKeyResolver interface
Time / timestamp source	Source chain's wall-clock for replay-window decisions	Out of scope; warp's replay protection is content-addressed (Message.ID() = D)
Network transport	ZAP (or other transporter) integrity / authenticity guarantees	See TRANSPORT.md; ZAP carries warp envelopes verbatim

§5 Out-of-scope (NOT in the warp TCB)

Item	Why excluded
Bridge-quorum compromise	A compromised source-chain validator set produces valid envelopes; warp can't detect that. Verifier's responsibility (TOFU / slashing / multi-source quorum).
HSM / KMS provider correctness	Operator's choice; outside the protocol.
Operator OS kernel / CPU	Standard for any cryptographic implementation.
Network DDoS / partitioning	Liveness, not soundness; warp is content-addressed and replay-safe regardless of network state.
Compiler trust ("Reflections on Trusting Trust")	Cannot be eliminated; partial mitigation via reproducible builds.

§6 TCB minimization principles

Warp's wire-format and posture-gate code is intentionally TCB- minimizing:

1. No background goroutines in the verification path — verification is a pure function of input bytes.

2. No mutable global state in the warp root package — Envelope is a value type; the registry is constructed per caller; the posture gate is a stateless function.

3. Single sentinel error for the strict-PQ refusal (pq.ErrClassicalAuthForbidden) — audit pipelines grep ONE identifier across every refusal site.

4. Domain-separation tags pinned in source — the per-lane DST constants ("LUX-WARP-ZAP-CORE-v1", "LUX-WARP-ZAP-BEAM-v1", "LUX-WARP-ZAP-PULSE-v1", "LUX-WARP-ZAP-MLDSA-v1") live in codec.go and are tested (TestLaneSigningBytesDistinct); they are distinct from the consensus-side "QUASAR-PULSAR-BUNDLE-v1".

5. Fuzz-tested decoders — FuzzEnvelope, FuzzEnvelopeRaw, FuzzZapReader, FuzzSignatureSchemeLegParser, FuzzCorruptedMLDSACertSet, and FuzzBeamCodec exercise the byte-input surface.

6. No reflection-driven serialization — ZAP framing is explicit (the append* / zapReader primitives in zap.go) so the field count and order are wire-stable; there is no reflection path and no struct-tag dependence.

§7 What an auditor mapping the warp TCB should do

1. Verify every primitive module in §1 has its own CRYPTOGRAPHER-SIGN-OFF.md (or equivalent audit ref). Warp inherits trust; it does not re-prove primitives.

2. Verify the implementation TCB §2 packages are at the exact versions pinned in go.mod. Re-run GOWORK=off go mod verify to confirm hash integrity.

3. Regenerate the KAT manifest §3 and diff byte-by-byte. Any drift indicates a build-tool divergence.

4. Read DEPLOYMENT-RUNBOOK.md for the operational TCB §4 responsibilities. Confirm operators implement the runbook.

5. Confirm the §5 out-of-scope items are explicitly addressed by separate audits (bridge-quorum, HSM, etc.) before relying on warp for production traffic.

---

Document metadata

• Name: TRUSTED-COMPUTING-BASE.md
• Version: v1.0 (Tier A)
• Date: 2026-05-18