diff --git a/docs/TICKETS.md b/docs/TICKETS.md index 7e251e6..a5b5ed5 100644 --- a/docs/TICKETS.md +++ b/docs/TICKETS.md @@ -61,6 +61,9 @@ Newest first. Update on every open/close. | ID | Title | Status | Opened | Directive | |----------|------------------------------------------------|-----------------------|------------|-----------| +| #000036 | T3 per-window covert-channel budget bound | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — | +| #000035 | PRG choice for φ_PRG (HMAC-SHA-512 expansion) | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — | +| #000034 | Hessian alignment under φ_linear | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — | | #000033 | Claim-pack pillar VII (combinatorics) | open · awaiting go/no-go | 2026-05-09 | — | | #000032 | combinatorics@v1 π* (integer counting kernel) | closed · landed 2026-05-09 | 2026-05-09 | — | | #000031 | Surface-ingest cited textbooks for claim-pack warrant promotion | open · awaiting go/no-go | 2026-05-09 | — | @@ -97,4 +100,4 @@ Newest first. Update on every open/close. ## Next ID -`000034` +`000037` diff --git a/docs/tickets/ticket-000018-soft-hash-covert-channel.md b/docs/tickets/ticket-000018-soft-hash-covert-channel.md index 2753cf4..daa8007 100644 --- a/docs/tickets/ticket-000018-soft-hash-covert-channel.md +++ b/docs/tickets/ticket-000018-soft-hash-covert-channel.md @@ -1,6 +1,6 @@ # Ticket #000018 — Adversarial soft-hash covert channel analysis -**Status:** closed · landed 2026-05-09 (analysis doc at `docs/soft-hash-channel-analysis.md`) +**Status:** closed · landed 2026-05-09 (analysis doc at `docs/soft-hash-channel-analysis.md`; three §9 open questions split into follow-ups #000034 / #000035 / #000036) **Opened:** 2026-05-07 **Scope:** Formal threat model + falsifier set for whether training gradients can route information from training data through soft hashes diff --git a/docs/tickets/ticket-000034-hessian-alignment-phi-linear.md b/docs/tickets/ticket-000034-hessian-alignment-phi-linear.md new file mode 100644 index 0000000..37ba203 --- /dev/null +++ b/docs/tickets/ticket-000034-hessian-alignment-phi-linear.md @@ -0,0 +1,180 @@ +# Ticket #000034 — Hessian alignment under φ_linear + +**Status:** open · awaiting go/no-go +**Opened:** 2026-05-09 +**Scope:** Empirically measure whether the v7 reference +`embed_hard_to_vec` matrix W (frozen-seed linear projection from +SHA-256 digest space → dim_h vector space) has structural alignment +with low-eigenvalue directions of the typical training-loss Hessian. +If yes, the §4 reduction in #000018 is loose under φ_linear and +T2 adversaries can amplify covert-channel steerage beyond the +random-oracle baseline. +**Audience:** maintainers of the v7 plastic-training spec; #000018 +follow-up. +**Hard constraint:** measurement-only. This ticket does NOT change +v7 spec or the φ implementation; it produces a residual-channel +bound that informs the M1 (φ_PRG) vs M2 (anchor nonce) priority. + +--- + +## 1. Problem statement + +The #000018 analysis (`docs/soft-hash-channel-analysis.md` §4) +shows that under threat models T1 (data poisoner) and T2 (gradient +adversary), the covert channel from training data → committed +hard hash `C(M_{t+1})` is bounded by SHA-256 partial-preimage +hardness — **provided φ is independent of parameter geometry**. + +§5.1 flags the v7 reference choice (frozen-seed linear projection) +as not obviously independent. If W's column space aligns with +low-eigenvalue directions of the loss Hessian, the L2 anchor pull +provides cheap parameter movement in directions correlated with +SHA-256 buckets. Cheap = "reachable within a per-step gradient +budget" = exploitable. + +This ticket measures whether that alignment exists. + +## 2. Design choices + +### 2.1 Measurement target + +For a representative model checkpoint: + +``` +W — dim_d × 256 frozen projection matrix + (in v7 reference: digest_as_uint32 → dim_h via + random-seed Gaussian) +H(Θ) — Hessian of L_task at Θ (dim_d × dim_d, symmetric) +{λ_i, v_i} — eigenvalue / eigenvector pairs of H(Θ) +``` + +Quantity of interest: does W's column space concentrate on the +low-eigenvalue subspace of H(Θ)? + +Define **alignment score**: + +``` +A(W, H) = (Σ_i ⟨W·e_i, v_i⟩² / (λ_i + ε)) / ‖W‖_F² +``` + +where the sum is over the 256 columns `W·e_i` of W and the +eigenvectors of H, and ε is a small regularizer to avoid +division by 0 on flat directions. + +Under random-oracle modeling, A is uniformly distributed across +the eigenvalue spectrum (no preference for low-λ). If A is +concentrated on the low-λ tail, we have evidence of structural +alignment. + +### 2.2 Hessian estimation strategy + +The Hessian of a 10⁹-parameter model is intractable. Three +approximation choices: + +**A. Top-k Lanczos.** Estimate the top-k and bottom-k eigenpairs +via Lanczos iteration. Captures the spectrum's tails — the +ones that matter for the alignment question. + +**B. Hutchinson stochastic trace estimator.** Bounds the trace +distribution but doesn't give per-eigenvector alignment. + +**C. KFAC / block-diagonal approximation.** Layer-wise Hessian +approximation. Cheap; loses cross-layer structure that may be +exactly where the alignment lives. + +**Recommendation:** A. Top-100 + bottom-100 eigenpairs is +empirically tractable on a single GPU for ~10⁸-parameter +checkpoints. + +### 2.3 Reference checkpoints + +Run the measurement on: + +1. v7-reference fresh-init checkpoint (no training). +2. v7-reference after K=1000 steps on a representative task. +3. v7-reference after K=10⁵ steps (mid-training). + +If the alignment score remains low across all three, the +structural-alignment concern is empirically dismissed. + +If alignment grows during training (e.g., the loss landscape +develops low-λ valleys aligned with W's columns), that's the +exploit pathway and M1 (φ_PRG) becomes the recommended +mitigation. + +## 3. Implementation sketch + +### 3.1 New script + +`bench/scripts/phi_alignment_probe.py`: + +```python +def measure_alignment(checkpoint_path, k=100): + # 1. Load Θ, W (from v7 boot manifest). + # 2. Build a small task-loss closure on a fixed eval batch. + # 3. Run top-k + bottom-k Lanczos on H(Θ). + # 4. Compute A(W, H_top) and A(W, H_bottom). + # 5. Emit JSON with eigenvalue spectrum + alignment scores. + ... +``` + +### 3.2 Bench fixture + +`bench/fixtures/phi-alignment/sentinel-checkpoint.json` (or +similar) — a deterministic mini-checkpoint we can re-measure +across runs to detect drift in the analysis. + +### 3.3 Interpretation thresholds + +- A_low / A_uniform ratio > 1.5 → structural alignment confirmed, + M1 (φ_PRG) becomes priority over M2. +- A_low / A_uniform ratio ≈ 1.0 → no alignment, M2 alone is + sufficient. +- A_low / A_uniform ratio < 0.7 → φ_linear is anti-aligned with + the loss landscape; the linear projection is actually safe. + +## 4. Out of scope + +- Full Hessian computation (intractable). +- Implementing M1 / M2 in code (separate tickets). +- Training new models for the experiment (use existing + representative checkpoints). +- Adversarial training that deliberately creates alignment + (out-of-scope; that's an attack-construction experiment, not a + measurement). + +## 5. Risks + +- **No representative v7 checkpoint exists today.** v7 plastic + training is on the roadmap, not deployed. This ticket assumes + a v7 reference checkpoint becomes available; it parks until + one does. Until then, measurement on a *proxy* checkpoint + (e.g., a small transformer trained with the L2-anchor term + retrofit) lets us derive a preliminary bound. +- **Lanczos convergence on noisy gradients.** Stochastic Hessian + estimation has well-known noise issues; bound calculations + should report confidence intervals. + +## 6. Acceptance criteria + +1. `bench/scripts/phi_alignment_probe.py` runs against any + v7-reference-shape checkpoint. +2. Output JSON includes per-eigenvalue alignment scores for + top-k and bottom-k. +3. Decision threshold (§3.3) yields one of three verdicts: + `STRUCTURAL_ALIGNMENT`, `NO_ALIGNMENT`, `ANTI_ALIGNED`. +4. Result feeds back into #000018 §9.1 — either closes the + open question (if NO_ALIGNMENT) or escalates the M1 + priority (if STRUCTURAL_ALIGNMENT). + +## 7. Status + +**Open · awaiting go/no-go.** Parks until a v7 reference +checkpoint is available; the analysis is empirical-only and +useless without representative training data. Recommended +deferral to v7 deployment ramp-up. + +Closure criterion: `bench/scripts/phi_alignment_probe.py` lands ++ a measurement run against a representative checkpoint +produces a verdict that resolves §9.1 of `docs/soft-hash- +channel-analysis.md`. diff --git a/docs/tickets/ticket-000035-prg-choice-phi-prg.md b/docs/tickets/ticket-000035-prg-choice-phi-prg.md new file mode 100644 index 0000000..8d5e000 --- /dev/null +++ b/docs/tickets/ticket-000035-prg-choice-phi-prg.md @@ -0,0 +1,255 @@ +# Ticket #000035 — PRG choice for φ_PRG + +**Status:** open · awaiting go/no-go +**Opened:** 2026-05-09 +**Scope:** Pin a specific cryptographic PRG construction for the +M1 mitigation (PRG-based anchor map) proposed in #000018 §5.2 + +§9.2. The §4 reduction in `docs/soft-hash-channel-analysis.md` +treats φ_PRG as a random oracle; in deployment we need a +deterministic PRG with explicit cryptographic strength assumption. +**Audience:** maintainers of the v7 plastic-training spec; #000018 +follow-up. +**Hard constraint:** the PRG security parameter MUST match SHA-256 +in the substrate (≥128-bit security level). Adding a weaker PRG +would create a cryptographic-strength asymmetry — adversary breaks +the PRG, channel re-opens. + +--- + +## 1. Problem statement + +#000018 §5.2 proposes φ_PRG as the M1 mitigation: + +``` +φ_PRG(digest) = PRG(seed = published, output_len = dim_h * 4 bytes) + then bytes → floats in [-1, 1] +``` + +The §4 reduction proves channel-bound under the random-oracle +model for φ_PRG. In deployment, "random oracle" becomes "PRG with +public seed and computational indistinguishability from random." + +The reduction holds **modulo PRG security**. Pick a weak PRG and +the reduction's looseness is the PRG's distinguishing advantage. +This ticket pins which PRG. + +## 2. Design choices + +### 2.1 Candidate PRG constructions + +**A. HMAC-SHA-512 expansion.** + +``` +def phi_prg(digest_32bytes, dim_h): + out = b"" + counter = 0 + while len(out) < dim_h * 4: + out += hmac.new(seed, digest_32bytes + counter.to_bytes(4, 'big'), + hashlib.sha512).digest() + counter += 1 + return bytes_to_floats(out[:dim_h * 4]) +``` + +- **Strength:** HMAC-SHA-512 is a PRF under the standard SHA-512 + Merkle-Damgård + HMAC assumption. Distinguishing advantage is + bounded by the SHA-512 collision-resistance bound (~2^256). +- **Dependency:** keeps the substrate's hash family at SHA-{256,512} + — already in the dependency surface. +- **Speed:** ~1 GB/s on a modern x86 CPU; negligible per-checkpoint. + +**B. AES-256-CTR with public IV.** + +``` +def phi_prg(digest_32bytes, dim_h): + aes = AES.new(seed[:32], AES.MODE_CTR, nonce=digest_32bytes[:8]) + out = aes.encrypt(b"\\0" * (dim_h * 4)) + return bytes_to_floats(out) +``` + +- **Strength:** AES-256 PRP under the standard AES key-recovery + hardness assumption. Distinguishing advantage bounded by AES key + search (~2^256) under known plaintext. +- **Dependency:** adds `cryptography` package's AES (already in + arborist core deps as `cryptography>=42`). +- **Speed:** ~1.5 GB/s on x86 with AES-NI; faster than HMAC-SHA-512 + but the difference doesn't matter at v7 checkpoint cadence. + +**C. ChaCha20 with public nonce.** + +- **Strength:** ChaCha20 PRF under the cryptographic standard. +- **Dependency:** `cryptography` provides; same as AES. +- **Considered:** redundant with AES — pick one. + +**D. SHA-256 as a hash chain.** + +``` +def phi_prg(digest_32bytes, dim_h): + out = b"" + h = digest_32bytes + while len(out) < dim_h * 4: + h = hashlib.sha256(seed + h).digest() + out += h + return bytes_to_floats(out[:dim_h * 4]) +``` + +- **Strength:** **Insufficient.** SHA-256 hash chains are NOT + guaranteed PRFs — known length-extension and predictable + fixed-points make this unsuitable. Reject. + +### 2.2 Recommendation + +**A — HMAC-SHA-512 expansion.** + +Reasons: +1. Tightest dependency: stays inside the SHA family already + committed to by SHA-256 (the substrate's hard-hash). Adding + AES would multiply the assumption surface without + cryptographic gain. +2. Standard NIST-approved PRF construction (SP 800-108 + KDF in counter mode using HMAC). +3. Speed parity with AES at v7 cadence (per-checkpoint cost + negligible compared to gradient computation). +4. Provable security reduction: HMAC-SHA-512 PRF security + reduces to SHA-512 collision-resistance, which is structurally + stronger than SHA-256 (output space is 2× larger). + +### 2.3 Float conversion + +PRG outputs uniform-random bytes. The anchor space is `[-1, 1]^dim_h`. +Convert via: + +``` +def bytes_to_floats(b): + """uint32 → float in [-1, 1) via 2 * (u32/2^32) - 1.""" + n = len(b) // 4 + floats = [] + for i in range(n): + u32 = int.from_bytes(b[4*i:4*(i+1)], 'big') + floats.append(2.0 * (u32 / 2**32) - 1.0) + return floats +``` + +Distribution: uniform on [-1, 1) modulo a 2^-32 quantization +discontinuity; ignored at our precision. + +### 2.4 Seed handling + +The PRG seed is published (committed in v7 boot manifest). It's +NOT a secret — secrecy isn't the security property. The property +is computational indistinguishability of the OUTPUT from random, +which holds even when the seed is public, because the adversary +can't invert the PRF without solving the underlying SHA-512 +problem. + +Rotating the seed per-checkpoint becomes the M2 mitigation +(#000018 §5.3) — orthogonal concern; M1 + M2 stack cleanly. + +## 3. Implementation sketch + +### 3.1 New module + +`arborist/v7/anchor_prg.py` (new directory if v7 work hasn't +landed yet; or wherever v7's plastic-training surface is +implemented): + +```python +"""φ_PRG — HMAC-SHA-512 anchor map for v7 § 9.10.""" +import hashlib +import hmac + +PUBLISHED_SEED = b"..." # 32-byte committed seed + +def phi_prg(hard_hash_32: bytes, dim_h: int) -> list[float]: + if len(hard_hash_32) != 32: + raise ValueError("hard hash must be 32 bytes (SHA-256)") + block_bytes = dim_h * 4 + out = bytearray() + counter = 0 + while len(out) < block_bytes: + msg = hard_hash_32 + counter.to_bytes(4, 'big') + out += hmac.new(PUBLISHED_SEED, msg, hashlib.sha512).digest() + counter += 1 + return _bytes_to_floats(bytes(out[:block_bytes])) +``` + +### 3.2 Tests + +`tests/test_anchor_prg.py`: + +- Determinism: same input + same seed → same output bytes. +- Distinguishing-from-random sanity: chi² test on a sample of + outputs (loose; just catches gross bugs). +- Boundary: dim_h=1, dim_h=10⁶ both produce sensible outputs. +- Seed-change sensitivity: flipping one bit of the seed produces + outputs uncorrelated with the original (Hamming distance ≈ + output_size / 2). + +### 3.3 Bench fixture + +`bench/fixtures/phi-prg/known-answer-tests.jsonl` — fixed +(seed, hard_hash, dim_h) → expected_output_sha256 triples for +regression coverage. Generated once, pinned. + +### 3.4 Spec amendment + +v7 § 9.10 amendment text: + +``` +The anchor map φ_PRG(C(M), dim_h) is defined as follows: + Let SEED be the v7 boot manifest's `phi_prg_seed` field + (32-byte committed value). + Let counter range over big-endian 4-byte integers from 0. + Output := concatenate HMAC-SHA-512(SEED, C(M) ‖ counter) + until ≥ dim_h * 4 bytes; truncate. + Convert each successive 4 bytes to a float via + 2 * (uint32_be / 2^32) - 1. + The dim_h-vector is the resulting list. + +φ_PRG SHALL replace the v7 reference linear projection +embed_hard_to_vec when the M1 mitigation is enabled. +``` + +## 4. Out of scope + +- v7 spec full revision; this ticket lands the §9.10 amendment + text, not the surrounding chapter. +- M2 (per-checkpoint nonce) implementation; orthogonal. +- Empirical Hessian-alignment measurement under φ_PRG (covered + by #000034). +- Performance tuning (PRG eval cost is ~µs per checkpoint; + irrelevant). + +## 5. Acceptance criteria + +1. `arborist/v7/anchor_prg.py` (or equivalent location) lands. +2. Tests pin determinism + seed-sensitivity + boundary cases. +3. Known-answer-test fixture committed under bench/fixtures. +4. v7 § 9.10 amendment text drafted (this ticket §3.4 is the + draft; final landing waits on v7 spec maintainer review). +5. #000018 § 9.2 closes — the PRG choice question becomes + "HMAC-SHA-512 with 32-byte committed seed." + +## 6. Risks / Considerations + +- **Future SHA-512 weakness.** If SHA-512 is broken in a way that + affects HMAC-SHA-512 PRF security, the M1 mitigation's + cryptographic foundation cracks. Mitigation: the v7 manifest's + `phi_prg_version` field lets future deployments swap to a + successor PRF without breaking historical replay. +- **Seed compromise.** If the published seed is somehow swapped + by an adversary (e.g., supply-chain attack on the manifest), + the PRG is still PRF-secure but the seed is now adversarial- + controlled. The hard-hash chain (SHA-256 of the manifest) + catches the swap as a chain-break, so this reduces to a + manifest-integrity attack — out of scope for #000018, in + scope for chain-check. + +## 7. Status + +**Open · awaiting go/no-go.** Doc-only spec amendment + reference +implementation. Lands when v7 plastic-training has a deployment +target. + +Closure criterion: `arborist/v7/anchor_prg.py` ships, tests pass, +known-answer-test fixture pinned, v7 § 9.10 amendment text +accepted into the v7 spec. diff --git a/docs/tickets/ticket-000036-t3-per-window-bound.md b/docs/tickets/ticket-000036-t3-per-window-bound.md new file mode 100644 index 0000000..5ce090b --- /dev/null +++ b/docs/tickets/ticket-000036-t3-per-window-bound.md @@ -0,0 +1,229 @@ +# Ticket #000036 — T3 per-window covert-channel budget bound + +**Status:** open · awaiting go/no-go +**Opened:** 2026-05-09 +**Scope:** Derive an explicit closed-form upper bound on the covert- +channel capacity under threat model T3 (hyperparameter adversary), +when M2 (per-checkpoint anchor nonce) is in place. The §6 table in +`docs/soft-hash-channel-analysis.md` lists "bounded by per-window +budget" without giving the bound. This ticket calculates it. +**Audience:** maintainers of the v7 plastic-training spec; #000018 +follow-up; operators sizing nonce-window length vs acceptable +residual. +**Hard constraint:** the bound must be **explicit closed form** — +not an asymptotic Big-O claim. Operators need it expressed in +bits-per-window with named inputs (per-step bandwidth, window +length, gradient budget) so they can plug in their deployment's +actual numbers and read off the residual. + +--- + +## 1. Problem statement + +#000018's §4 reduction bounds T1 + T2 channels at the SHA-256 +random-oracle baseline. T3 (hyperparameter adversary) is **not** +covered by that reduction: T3 controls learning-rate scheduling +and batch ordering, breaking the implicit assumption that A's +training-oracle queries follow the published schedule. + +§6 of the analysis claims "T3 bounded by per-window budget" with +M2 enabled. The intuition: the per-checkpoint nonce randomizes +the anchor between checkpoints, so T3 only has a single window +of length W steps to exploit before the anchor re-randomizes. +The bound on per-window steerage is the open question. + +This ticket pins the bound. + +## 2. Design choices + +### 2.1 Capacity model + +Define the per-window channel as: + +``` +I_window = I(adversary inputs over W steps ; C(M_{t+1})) + conditional on H_{≤t}, n_t (the published nonce) +``` + +For each adversary input (gradient bias, learning-rate change, +batch order swap), measure how many bits of `Q(Θ_{t+1})` the +adversary can steer relative to the random baseline. + +### 2.2 Three input bandwidths + +T3 has three control surfaces. Each contributes to the per- +window channel: + +**B1 — Gradient bias (bits per step).** Inherited from T2: +adversary controls `g`-fraction of gradient computations; each +step the adversary biases `O(g · ‖∇L‖)` of the gradient signal. +Per-step bandwidth ≈ `g · ‖∇L‖ / unit-Hessian-step`. + +**B2 — Learning-rate selection (bits per LR decision point).** +T3 picks LR from a constrained range. With log-grid LR space +of `R` levels, B2 = log₂ R bits per decision point. Decision +points typically once per K steps under standard cosine / +warmup schedules. + +**B3 — Batch order (bits per epoch).** T3 reorders batches +within an epoch. With N batches per epoch, B3 ≤ log₂ N! ≈ N log N +bits per epoch — but most of those bits don't translate to +parameter steerage because batch order has weak influence on +final Q(Θ) under gradient averaging. Effective bandwidth is +much smaller; see §3.2 for the conjecture. + +### 2.3 Per-step → per-bit-of-C(M) conversion + +The adversary's per-step control bandwidth is in parameter- +space directions. Translating to "bits of C(M_{t+1}) controlled" +requires the inverse map: + +``` +parameter shift δΘ → SHA-256 bucket shift = ? +``` + +By the §4 random-oracle reduction (when φ is independent of +Hessian), each independent parameter direction maps to +independent SHA-256 bucket bits — so the conversion is +information-preserving but at the random baseline. T3's edge +over T2 is that hyperparameter control multiplies effective +gradient bandwidth. + +### 2.4 The bound (sketch) + +Combining the three bandwidths over a window of W steps: + +``` +I_window ≤ C_B1 · g · W · log₂(N_directions) + + C_B2 · ⌈W / K⌉ · log₂ R + + C_B3 · log₂ (W / batch_count) · ⌈W / E⌉ +``` + +where: +- `C_B1, C_B2, C_B3` are channel-efficiency constants + (≤ 1 by data-processing inequality, typically much smaller). +- `g` is the fraction of gradients the adversary controls. +- `N_directions` is the effective parameter-direction count + the adversary can steer per step (bounded by the gradient + budget ‖∇L_max‖). +- `K` is the LR-decision interval (steps between LR changes). +- `R` is the LR-grid size. +- `E` is the steps-per-epoch count. +- `batch_count` is batches per epoch. + +The closed-form bound's **goal**: be tight enough that operators +can pick W (the nonce-window length) such that I_window stays +below their target residual (e.g., < 1 bit per window means the +adversary needs ≥ 2^256 windows to steer C(M) to a specific +target). + +## 3. Implementation sketch + +### 3.1 Formal derivation + +Section-by-section in a new doc +`docs/soft-hash-channel-t3-bound.md`: + +- §1 Restate T3 model from #000018. +- §2 Define per-window channel formally. +- §3 Bound C_B1 (gradient bias) — Fano's-inequality-style + argument from information theory. +- §4 Bound C_B2 (LR selection) — finite-alphabet capacity + argument; LR is a categorical channel with R symbols. +- §5 Bound C_B3 (batch order) — argument that batch-order + effects on final Q(Θ) are bounded by gradient-noise scale, + not factorially. +- §6 Combine §3-§5 into a closed-form per-window bound. +- §7 Numeric examples for representative deployments + (e.g., g=0.05, K=100, R=8, W=10000 → bound in bits). +- §8 Operator guidance: how to choose W given a target + residual. + +### 3.2 Conjecture for C_B3 + +Standard SGD analysis (Bottou-Bousquet 2008, Hardt-Recht-Singer +2016) shows batch-order effects on final loss are bounded by +the gradient-variance scale, not by the entropy of the +permutation. We conjecture C_B3 ≤ `O(σ_grad / ‖∇L‖)` per epoch, +which is much smaller than `log₂ N!`. + +The bound's most important refinement is making this precise. +Random-shuffle SGD has near-zero C_B3; cyclic-shuffle SGD has +O(1) bits per epoch; adversarial-order SGD is the open +question. + +### 3.3 Tooling + +`bench/scripts/t3_bound_calculator.py` — small CLI that takes +deployment parameters (g, K, R, W, batch_count, gradient_norm) +and emits the closed-form bound: + +``` +$ python -m bench.scripts.t3_bound_calculator \ + --gradient-fraction 0.05 \ + --lr-decision-interval 100 \ + --lr-grid-size 8 \ + --window-length 10000 \ + --batch-count 1024 +{ + "I_window_bits_upper_bound": 3.41, + "B1_contribution": 2.85, + "B2_contribution": 0.31, + "B3_contribution": 0.25, + "recommendation": "I_window ≈ 3.4 bits/window. To steer + C(M) to a 256-bit-specific target, adversary + needs ≥ 2^252 windows." +} +``` + +Operators can plug in their deployment numbers and decide +whether the residual is acceptable. + +## 4. Out of scope + +- Empirical validation of the bound (separate ticket; needs + v7 deployment + adversarial training infrastructure). +- Tightening the random-oracle assumption to a concrete PRG + (covered by #000035). +- Implementing M2 in the v7 codebase (separate ticket). +- T1 / T2 bounds (covered by #000018 §4). + +## 5. Acceptance criteria + +1. `docs/soft-hash-channel-t3-bound.md` lands with §1-§8 above. +2. Closed-form per-window bound expressed in bits/window with + named inputs. +3. `bench/scripts/t3_bound_calculator.py` lands; produces + closed-form output for any (g, K, R, W, batch_count, + gradient_norm) input. +4. `docs/soft-hash-channel-analysis.md` §9.3 closes — the open + question becomes "see #000036's bound." +5. Numeric examples cover three representative deployments + (small / medium / large LR-grid + window combinations). + +## 6. Risks + +- **Bound too loose to be useful.** If the calculation produces + e.g. "≤ 100 bits/window", operators have no actionable + guidance. Mitigation: walk through C_B3 carefully — + factorial-batch-order naive bound is the loose one. The + Bottou-Bousquet refinement is what makes the bound useful. +- **Bound depends on unknown gradient geometry.** The + ‖∇L_max‖ term is deployment-specific. Mitigation: report + the bound parametrized in ‖∇L_max‖, let operators measure + it on their deployment. +- **T3 attack model evolution.** Future hyperparameter-control + surfaces (e.g., adaptive optimizer state manipulation) may + add B4-B5 bandwidth channels. The framework here generalizes: + add new B_i terms as new control surfaces are documented. + +## 7. Status + +**Open · awaiting go/no-go.** Doc-only formal-derivation + +calculator script. Lands when #000018's other follow-ups +(#000034 + #000035) have either resolved or been parked — +the T3 bound's value depends on M2 being the chosen +mitigation. + +Closure criterion: bound landed, calculator works against named +inputs, #000018 §9.3 closes.