# THREAT-WALKTHROUGH.md — what a relay actually learns

Assignment 01, deliverable 3. Per packet type, precisely what a passive relay observes.

**The instruction this document is written under**, from `ASSIGNMENT-01.md`:

> Show that a relay observing ROUTE_QUERY + ROUTE_RESPONSE + ENVELOPE cannot identify sender,
> recipient, or conversation. **If it *can* learn something, say so plainly rather than asserting
> privacy.**

It can. §5 and §6 say so plainly. Assertions of privacy that do not survive an adversary who is
paying attention are worse than useless, because people rely on them.

---

## 1. Adversary positions

These are genuinely different, and conflating them is how privacy claims become false.

| Position | Description |
|---|---|
| **P1 · First hop** | The relay a sender hands a packet to directly |
| **P2 · Middle relay** | A relay with another relay on both sides |
| **P3 · Final hop** | The relay that hands a packet to its destination |
| **P4 · Passive listener** | In radio range, relaying nothing |
| **P5 · Global observer** | Sees many locations at once — **out of scope** (`SPEC-ORIGINAL` §32) |

**With `MAX_DISCOVERY_HOPS = 3`, P2 frequently does not exist.** On a two-hop route A→B→C there is
exactly one relay, and it is simultaneously P1 and P3. §6 is about what that means.

---

## 2. What every relay learns unconditionally

Regardless of packet type, from the fact of the encounter itself:

- A device running this protocol is physically nearby, now.
- Its ephemeral advertisement ID — rotating every 15 minutes, derived from nothing.
- Approximate distance, from radio signal strength.
- Packet sizes, to bucket granularity, and arrival times.
- Whatever the radio layer discloses beneath us — MAC-layer behaviour, chipset fingerprints, timing
  characteristics. **We do not control this and do not claim to** (`SPEC-ORIGINAL` §3).

---

## 3. Per packet type

| Packet | What a relay learns | What it does **not** |
|---|---|---|
| `HELLO` | A protocol version | Anything about the device, user or contacts |
| `CAPABILITY` | Transport-class bits, storage class, persistent/gateway role | Platform, model, OS, build. Capabilities are protocol bits, never `deviceType = iPhone17` (`SPEC-ORIGINAL` §15) |
| `PRESENCE` | Exactly 32 opaque 16-byte values | Who they belong to; **and not the contact count**, since the set is fixed-size and padded (§7) |
| `ROUTE_QUERY` | A random query ID, one opaque token, a hop budget ≤ 3 | Who is asking, who is sought, or whether either is a contact of the relay |
| `ROUTE_RESPONSE` | That *someone* holding the right secret answered; a link-quality figure; a hop count | The path, the responder's identity, or any node between |
| `INVENTORY` | Which packet IDs a peer holds, and their destination tokens | Who those packets are for. Destination tokens are derived under a different label from presence tokens, so they cannot be matched against any beacon (`PROTOCOL.md` §4.4) |
| `WANT` | Which packet IDs a peer lacks | Why, or for whom |
| `ENVELOPE` | Only §2's fields — see §4 below | Content, sender, recipient, conversation, or any permanent identifier |
| `ACK` | That a relay took custody of a packet ID | That anyone received or read anything. Delivery receipts are end-to-end encrypted envelopes of their own |
| `GOODBYE` | The encounter ended, and loosely why | Anything else |

---

## 4. The Envelope, field by field

| Field | Visible to a relay | Assessment |
|---|---|---|
| `protocolVersion` | Yes | Version only |
| `packetID` | Yes | Random, not derived. **Constant along the journey** — that is what makes duplicate suppression work, and it means P5 could trace one packet across the network. Accepted; P5 is out of scope |
| `destinationToken` | Yes | Opaque, rotates every 10 minutes, unlinkable across epochs, and cryptographically unrelated to any presence beacon |
| `creationBucket` | Yes | Age of the packet, to 10-minute granularity |
| `expiresAfter` | Yes | Intended lifetime. **A minor leak we accept:** an unusually short lifetime may signal something about the sender's intent |
| `transitPolicy` | Yes | One bit. Partitions traffic into two classes — mitigated by defaulting to restrictive, so the large population carries the restrictive value (`DECISIONS.md` D5) |
| `payloadLength` | Yes | One of five buckets. Mandatory padding means it does not reveal actual length |
| `fragment*`, `totalLength` | Yes | That a message exceeded a bucket, and by roughly how much |
| `nonce` | Yes | Random |
| `hopLimit` | Yes | Remaining allowance, so roughly how far it has already travelled |
| `ciphertext` | Yes, as bytes | Nothing without the key |

No display name, device name, OS, model, build, phone number, account identifier, or permanent device
identifier appears anywhere in it (`SPEC-ORIGINAL` §13, §15).

---

## 5. The combined observation — the assignment's actual question

A relay sees, in sequence:

```
1.  ROUTE_QUERY    from peer P    { queryID Q, presenceToken X,  budget 3 }
2.  ROUTE_RESPONSE toward peer P  { queryID Q, quality, hops 2 }
3.  ENVELOPE       from peer P    { packetID N, destinationToken Y }
```

**Cryptographically, X and Y are unlinkable.** They are HMACs under different labels, and no party
without `routingSecret` can connect them. The design does what it was meant to do at the level of
values.

**Temporally, they link trivially.** All three arrive from the same immediate peer within seconds.
A relay does not need to break any cryptography to conclude: *the envelope P just handed me is for
whoever P was looking for.*

**So state it plainly. A first-hop relay learns:**

- that its peer P is trying to reach the holder of token X;
- that P then handed it a message for that same party;
- that a **communication relationship exists between two pseudonyms**, right now.

**What it still does not learn:**

- Who P is. P is an ephemeral radio identifier that rotates every 15 minutes and is derived from
  nothing — no identity key, no account, no device identifier.
- Who the recipient is. The token rotates every 10 minutes with no cryptographic relationship between
  consecutive values.
- The content, the conversation, or whether these two have ever spoken before.
- **Anything that survives the epoch.** Both the pseudonym and the token roll independently. Linking
  today's pair to tomorrow's is not possible from this observation alone.

**The honest summary:** the protocol conceals *identity*; within a single epoch, adjacency to a
sender still reveals *the existence of a correspondence*. Sealed sender protects who, not that.

---

## 6. Two-hop routes: the single relay sees both ends

On `A → B → C`, B is P1 and P3 at once. So B learns:

- the sender's radio pseudonym,
- the recipient's radio pseudonym — because B must physically hand the packet to C,
- that these two are corresponding, within this epoch.

**This is not fixable within this architecture and we do not claim otherwise.** Someone must deliver
the packet to the destination, and that someone necessarily knows which radio peer received it. Onion
routing would address it, at the cost of becoming an anonymity network rather than a messenger —
explicitly out of scope for v1 (`DECISIONS.md` D7).

**Context that matters for the flagship scenario:** on an aircraft, B is a passenger seated within a
few metres of A and C and can simply *look at them*. Radio-layer correlation is not the binding
privacy constraint in the environment this was designed for. It matters much more in a dense public
space among strangers, and that is the case to be honest about.

---

## 7. A leak found while writing this, and fixed

Checkpoint 2 moved presence tokens off the broadcast channel into a post-connection `PRESENCE` packet,
precisely so the *number* of tokens could not fingerprint a user (`PROTOCOL.md` §4.6).

**The leak came straight back on the unicast channel.** Presence tokens are pairwise, so a `PRESENCE`
list of length N discloses that the sender has N contacts — to anyone who connects, including a
stranger in a queue.

`PROTOCOL.md` §6.3 now requires the list to be **exactly `PRESENCE_SET_SIZE` (32) entries always**,
padded with CSPRNG values indistinguishable from real tokens, or randomly sampled and re-sampled each
encounter when a node has more. Contact count is no longer observable.

Recorded rather than quietly patched, because it is a useful demonstration that the fingerprint moved
when the channel moved, and the same mistake is available anywhere else a list length depends on a
user's contacts.

---

## 8. Leaks we accept, and why

| Leak | Why accepted |
|---|---|
| `packetID` traceable end to end | Required for duplicate suppression. Only exploitable by P5, which is out of scope |
| Correspondence visible to an adjacent relay (§5) | Inherent to relaying; mitigated by rotating pseudonyms and 10-minute tokens |
| Both endpoints visible on a two-hop route (§6) | Inherent; onion routing is the only fix and it is out of scope |
| Message size to bucket granularity | Padding buckets are a deliberate trade against bandwidth |
| **Fragment injection destroys a message** | A fragmented message has one AAD (`PROTOCOL.md` §3.2), so per-fragment index and length are unauthenticated. Corrupting reassembly makes the tag fail. It is a denial of service, never a break — and it grants nothing, since anyone able to inject fragments can already just drop them, which is simpler and equally effective |
| Hop count to the sender | Needed for route selection; discloses coarse proximity of a contact to that contact only (`DECISIONS.md` D3) |
| Packet age and intended lifetime | Needed for expiry enforcement by nodes that cannot read the packet |
| Radio-layer fingerprinting | Outside application control entirely (`SPEC-ORIGINAL` §3) |
| **A persistent node discloses that a node lives at that location** | Inherent to fixed infrastructure. Rotating the advertisement ID does not conceal a device that is always present in one place from an observer who is also in one place. One reason the persistent node is optional, and a reason not to run one somewhere the household's presence is itself sensitive |
| Install base, if broadcast push is ever enabled | Push is off by default and targeted push is a permanent non-goal (`DECISIONS.md` B1) |

---

## 9. Structural properties that do hold

- **No content, ever.** Relays hold ciphertext and no key material.
- **No mailbox role requires decryption.** A persistent node stores envelopes it cannot read
  (`DECISIONS.md` A3).
- **No originator attribution is possible.** No field carries it and no party is positioned to derive
  it. A traceability mandate cannot be satisfied by a system that never had the data — stated here so
  it is on record as a design property rather than an accident.
- **No topology tables.** Only reverse-path state (10 s) and route state (15 s), keyed by opaque
  values.
- **No key escrow, and nowhere to add one.** No server, no server-delivered key material, no lever.
- **Deleting a contact destroys the pairwise secret**, after which anything still in flight to them is
  permanently undecryptable — including by us.
- **Tampering fails closed.** Any structural or cryptographic failure is a silent discard;
  implementations MUST NOT return distinguishing errors, which would build an oracle.

---

## 10. What we do not claim

Carried from `SPEC-ORIGINAL` §32 and `SPEC-REVISION` §3, plus what this walkthrough added:

- Not protected against a **compromised destination device**, malware in decrypted memory, OS
  compromise, or physical access to an unlocked device.
- Not protected against a **global observer** correlating radio traffic across locations.
- **Not** perfect sender/recipient anonymity — §5 and §6 are the specific limits.
- **Not** concealment that a transmitting device is an iPhone. Radio fingerprinting and the
  underlying peer-to-peer protocols may reveal platform. This is application-layer minimisation.
- **Not** protection against a **targeted app-store build**. No protocol design prevents it; the
  partial answer is reproducible builds with published hashes, which requires publishing source and
  is deferred by `DECISIONS.md` F7.
- **Not** enforcement of no-forward or no-screenshot. Those are stated intent, not controls
  (`DECISIONS.md` E5).
- **Not** a guarantee that `transitPolicy` is honoured. Relays share no key with the sender.

**What we do claim**, and what `SPEC-REVISION` §3 permits: the protocol discloses **no device model,
operating system, telephone number, account identifier, or permanent device identifier** — and no
message content, to anyone but its destination.