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:

```

ROUTE_QUERY from peer P { queryID Q, presenceToken X, budget 3 }
ROUTE_RESPONSE toward peer P { queryID Q, quality, hops 2 }
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.

English is the reference text; any translation is a convenience. Help is stored on this phone and never contacts anyone.