# 0034 — Harvest-now-decrypt-later: values rest on X-Wing; the log keeps public-key wraps of `a_i`

- Status: accepted (corrects 0014 §2 and Consequences; closes research/11 QC-1 as "accepted residual"); round 2: also covers sealed metadata and AS (see amendment)
- Date: 2026-10-22
- Area: crypto

## Context

ADR 0014 says that after adoption "the relay holds no public-key wrap of `a_i`" and that approver shares are "immune to HNDL by construction". Spec review round 1 (CRYPTO-R1-3) showed this is false: the log is append-only and held in full by every device and the relay, and it keeps (a) `SecretVersion` field 5 (`atransit`, `a_i` HPKE-sealed to `AK_e`) for every host-proposed secret, (b) `Grant` field 10 (`grant-share`, `a_i` sealed to the request's ephemeral key) for every grant, and (c) `SecretVersion` field 4 (`h_i` sealed to the host). An adversary who harvests the log today and later breaks X-Wing recovers `a_i` and `h_i`, hence `K`, the DEK and the value.

## Decision

1. **Correct the claims.** HNDL resistance for values rests on X-Wing (ML-KEM-768 + X25519) for both halves. The ASK wrap of `a_i` in policies removes one public-key wrap, not all. P12 is reworded; ADR 0014's consequence is corrected; QC-1 is closed as an accepted residual (N18).
2. **Do not move ciphertexts out of the log tonight.** A prunable side table (log signs only the hash) protects only against a *later* breach of an *honest* relay. A malicious relay keeps the ciphertexts, and a network harvester gets them through the relay's classical TLS (N10). It adds a second storage path, deletion semantics and a delivery race for no protection against A1 + A8.
3. **Product path:** move `atransit` and `grant-share` to the mailbox with relay-side deletion, together with hybrid-PQ TLS to the relay, and re-evaluate when a CRQC timeline makes it worthwhile (deferred, ADR 0028).

## Alternatives considered

| Option | Why not |
| --- | --- |
| Side table keyed by hash, deleted after adoption / request expiry | See decision 2: no gain against the relay that is the HNDL harvester; more code |
| Symmetric-only transport of `a_i` | No symmetric key is shared between a new host and the approvers before the first grant; would need an extra pre-shared secret per host |

## Evidence

1. ADR 0014 Context (QC-1), §2, Consequences; ARCHITECTURE §5.4 fields 4, 5, 10; §6.1 (full log on every device).
2. [draft-connolly-cfrg-xwing-kem](https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) — X-Wing is secure if either ML-KEM-768 or X25519 is secure (ADR 0003) — accessed 2026-10-22.
3. research/13 round 1.

## Consequences

- P12, N-limits and ADR 0014 are corrected; no byte change.

## Amendment (spec review round 2, 2026-10-22)

- The accepted residual is wider than values (MALICIOUS-RELAY-R2-6): every `policy-host` copy of `PolicyBody` (field 7) and the `as-transfer` message (HPKE(new kem_pub, AS), which a malicious relay keeps beyond the 10-minute TTL) rest on X-Wing. A later X-Wing break of one `as-transfer` yields `AS`, hence `ASK_e`/`AK_e`, hence every policy body, every standing `a_i`, every RequestDetails and UseDetails of the account. P12 and N18 say so. Product fix: AS epochs (0014 §4) and `as-transfer` over a channel other than the relay.