HONEST_DISCLOSURE.md

HONEST_DISCLOSURE — a11oy Receipt Signing

⚠️ Retired organs notice. amaru, sentra, and rosie have been retired and consolidated into the a11oy flagship (Memory, Sentinel, and Operator verticals). Their standalone szl-holdings/{amaru,sentra,rosie} GitHub repositories and szlholdings-{amaru,sentra,rosie}.hf.space Hugging Face Spaces no longer exist; only the signed GHCR images persist, for supply-chain verification. Any amaru/sentra/rosie Space URLs, repo links, or endpoints referenced below are historical and not live — use a11oy instead.

Doctrine: v11 LOCKED 749/14/163 · Λ = Conjecture 1 · SLSA L1 honest · L2 build-attested (Rekor) · L3+ roadmap
Date: 2026-06-03

HMAC Receipt Signing

a11oy receipt signing uses HMAC-SHA256 with a key loaded from the A11OY_HMAC_KEY environment variable (HF Space secret).

Without the secret, signatures are PLACEHOLDER (non-repudiation=false).

Specifically:

• If A11OY_HMAC_KEY is set: receipts are signed with HMAC-SHA256 under that key. This is a symmetric MAC — it proves "signed by someone holding the key," not non-repudiation. Non-repudiation requires asymmetric signing (ECDSA/DSSE); see szl_dsse.py for the asymmetric layer.
• If A11OY_HMAC_KEY is not set: the sig field in DSSE receipts is a PLACEHOLDER:<sha256-of-PAE> string, clearly labeled. The receipt chain integrity (SHA3-256 hash chain) is real and verifiable; only the HMAC authentication layer is absent.

Why HMAC, not ECDSA?

The ECDSA layer (szl_dsse.py) requires SZL_COSIGN_PRIVATE_PEM and is the production non-repudiation path. The HMAC layer in szl_receipt_substrate.py is a lightweight gate-evaluation receipt for in-process threshold policy verification — faster than asymmetric signing for the high-frequency policy path.

Shared-Key Requirement — CRITICAL

HMAC is a symmetric shared-secret scheme. The signer (a11oy) and the verifier (rosie) MUST use the same secret value.

The environment variable names differ by design for per-repo clarity:

• a11oy uses A11OY_HMAC_KEY
• rosie uses ROSIE_HMAC_KEY

However, the VALUES injected into both variables MUST be identical — the same 32+ byte secret, injected into each HF Space independently.

A mismatch means rosie will mark every real a11oy receipt as TAMPERED, even though the receipts are cryptographically correct. There is no error message that distinguishes a key mismatch from genuine tampering — both produce the same TAMPERED verdict from the verifier.

Deployment Checklist

1. Generate a single strong secret: python3 -c "import secrets; print(secrets.token_hex(32))"
2. Inject the same value as A11OY_HMAC_KEY into the a11oy HF Space secrets.
3. Inject the same value as ROSIE_HMAC_KEY into the rosie HF Space secrets.
4. Rotate both simultaneously if the key is ever compromised.

Action Required

The founder must inject A11OY_HMAC_KEY (a11oy) and ROSIE_HMAC_KEY (rosie) as HF Space secrets with the same value before the HMAC receipt layer provides any authentication guarantee. The PLACEHOLDER behavior is a deliberate fail-safe, not a silent failure.

Cross-References

• szl_receipt_substrate.py: HMAC signing implementation (env-var path)
• szl_dsse.py: ECDSA-P256 DSSE asymmetric signing layer
• szl_khipu.py: SHA3-256 hash chain (tamper-evident, works without secrets)
• RECEIPT_CHAIN_AS_SAFETY_PRIMITIVE.md: Gap analysis
• rosie HONEST_DISCLOSURE.md: Verifier-side disclosure

---

Signed-off-by: Yachay yachay@szlholdings.ai
Co-Authored-By: Perplexity Computer Agent agent@perplexity.ai