path: root/docs/FOG-THREAT-MODEL.md

# FOG Threat Model

Status: Draft 0.1

Date: 2026-08-08

## 1. Purpose

This document defines the security and privacy model for the FOG autonomous
mix network and its native asynchronous services. It identifies protected
assets, trust boundaries, adversary capabilities, assumptions, required
properties, non-goals, residual risks, and the evidence required before FOG
makes public security claims.

FOG is not implemented yet. Every property in this document is therefore a
design requirement or a validation target, not a statement about deployed
software.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY describe
normative requirements in the sense of BCP 14 when they appear in uppercase.

## 2. Scope

This threat model covers:

- the offline `fog-compose` environment;
- transfer through QR or `FOG-SX` simplex media;
- the online `fog-client-relay`;
- entry gateways and three stratified mix layers;
- directory authorities and signed epoch consensus;
- KEMSphinx packet processing and replay handling;
- Noise-protected adjacent-node links;
- couriers, native services, and capability-addressed storage replicas;
- asynchronous one-way drops, mailboxes, private messaging, and later group
  messaging;
- software distribution, configuration, updates, backups, logs, and
  operational metrics.

The FOG core does not include SOCKS, VPN, general Internet proxying, clearnet
exit nodes, web browsing, real-time audio or video, tokenomics, or arbitrary
user-selected routes. SMTP, NNTP, and foreign Sphinx networks may be reached
only through separately reviewed edge bridges whose weaker guarantees are
outside the core anonymity claim.

## 3. System Boundary

The intended high-level path is:

```text
offline Composer
    -> QR or FOG-SX simplex transfer
online blind relay
    -> temporary entry selected from authenticated consensus
entry gateway
    -> mix layer 1 -> mix layer 2 -> mix layer 3
courier / native service
    -> capability-addressed storage replicas
recipient blind relay
    -> recipient offline Composer
```

The entry is not one of the three mix hops. The Composer constructs the
internal KEMSphinx route from authenticated consensus. The blind relay may
select an entry only from the Composer-approved consensus and temporary entry
set. The recipient Composer is the only component intended to recover message
plaintext.

FOG uses three separate cryptographic layers:

1. message-level end-to-end protection between Composers;
2. KEMSphinx protection for routing and per-hop transformation;
3. fixed Noise profiles for authenticated adjacent-node transport.

No layer may be treated as a substitute for another.

## 4. Protected Assets

### 4.1 User and message assets

- message plaintext, attachments permitted by the future format, and drafts;
- long-term identity keys, contact state, ratchet state, recovery material,
  and backup keys;
- contact vouchers, reply material, mailbox capabilities, and storage
  capabilities;
- the fact that a user is sending, receiving, polling, replying, or remaining
  idle;
- sender identity, recipient identity, sender-recipient relationships,
  conversation membership, and social graph;
- message length, fragment count, timing, frequency, retry behavior, and
  conversation lifetime.

### 4.2 Network and operator assets

- authority identity keys, consensus signing keys, and voting state;
- node identity, Noise, KEMSphinx, replay, storage, and update keys;
- descriptors, operator-family declarations, topology assignments, epoch
  state, revocations, and key-overlap state;
- unreleased topology changes and security-sensitive configuration;
- replay caches, delay queues, cover-traffic schedules, storage shards, and
  tombstone state;
- release signing keys, build provenance, update metadata, and rollback state.

### 4.3 Availability and integrity assets

- consistent authenticated consensus;
- correct routing and packet transformation;
- bounded and non-amplifying protocol behavior;
- eventual delivery within the limits of an asynchronous best-effort system;
- integrity and freshness of Composer imports and software updates;
- the ability to revoke compromised identities, nodes, authorities, and
  releases.

## 5. Security Objectives

### 5.1 Cryptographic objectives

FOG MUST be designed so that:

- only the intended recipient Composer can decrypt message content;
- recipients can authenticate the claimed sender or contact context according
  to the selected messaging protocol;
- alteration, truncation, reordering, substitution, and unauthorized replay of
  protected message state are detected;
- a node learns only the routing information needed for its immediate role;
- packet transformation prevents bitwise input-output linkage at an honest
  mix;
- storage replicas cannot decrypt message content or derive stable contact
  identities from capabilities;
- compromise of one key purpose does not directly expose keys for another
  purpose;
- forward secrecy and post-compromise recovery are provided only if the final
  reviewed messaging construction supports them and its state transitions are
  implemented correctly.

FOG MUST NOT claim forward secrecy, post-compromise security, deniability, or
post-quantum security merely because individual primitives have those labels.
Those properties apply only after the complete protocol and lifecycle have
been analyzed.

### 5.2 Metadata privacy objectives

FOG targets the following conditional properties:

- sender anonymity against third parties;
- recipient anonymity against third parties;
- sender-recipient relationship unlinkability;
- route unlinkability across at least one honest mix transformation;
- resistance to short-term timing and volume correlation;
- reduced long-term intersection leakage;
- sender and recipient unobservability when traffic normalization, decoy
  traffic, padded retrieval, and sufficient anonymity-set activity are all
  present;
- unlinkability of successive mailbox locations and storage operations;
- indistinguishability, within defined traffic classes, of real messages,
  retries, empty reads, acknowledgments, and cover operations.

These are probabilistic properties, not absolute concealment. Their strength
depends on measured traffic volume, latency distributions, cover ratio,
topology, operator independence, user behavior, and adversary position. FOG
MUST publish the conditions and measured bounds attached to every metadata
privacy claim.

### 5.3 Availability objectives

FOG provides best-effort asynchronous delivery. It SHOULD tolerate isolated
node loss, replica loss, delayed packets, duplicate packets, temporary
partitions, and ordinary churn. It does not promise delivery against a global
active adversary, sustained distributed denial of service, a failed authority
quorum, or deliberate destruction of enough storage replicas.

Privacy MUST fail closed where continuing would silently weaken a claimed
property. Availability failover MUST NOT introduce direct delivery, smaller
packet classes, bypassed layers, unauthenticated directories, fixed emergency
routes, or disabled cover traffic without placing the deployment outside the
affected privacy claim.

## 6. Actors and Trust Boundaries

| Role | May legitimately learn | Must not learn or control alone |
| --- | --- | --- |
| Composer | Local plaintext, identity and contact state, selected consensus, constructed route | Other users' plaintext or secrets; unauthenticated network state |
| FOG-SX receiver | Transfer size class, transfer timing, opaque bundle | Plaintext, contacts, private keys, final recipient |
| Blind relay | Client-side network context, opaque packets, chosen temporary entry | Plaintext, internal route, final service or recipient |
| Entry | Previous peer, next mix, packet timing, random short-lived return rendezvous and reply ID | Message plaintext, complete route, recipient identity, durable user account |
| Mix | Previous hop, next hop, local delay, replay tag | Complete route, endpoint identities, message plaintext |
| Authority | Node descriptors, operator declarations, votes, epoch state | User messages, mailbox capabilities, unilateral valid consensus |
| Courier | Requested native operation, replica set or shard information required by protocol | User plaintext, stable user identity, contact graph |
| Native service | Minimum service-specific opaque state | Network origin, unrelated conversations, Composer secrets |
| Storage replica | Opaque record, capability-derived location, retention state, access timing | Plaintext, stable mailbox identity, sender-recipient relationship |
| Observer | Delayed coarse health aggregates | Payloads, packet identifiers, detailed routes, capabilities, fine-grained timing |
| Edge bridge | Data required by the external protocol | Authority to extend core guarantees to the external network |

No online role is universally trusted. Each role MUST be independently
deployable and separately keyed. Co-location is a deployment fact, not a
reason to collapse protocol boundaries or share secrets.

## 7. Adversary Capabilities

FOG analyzes capabilities independently rather than assuming a single linear
attacker tier. Real adversaries may combine any subset.

### 7.1 Passive observation

The adversary may:

- observe one link, multiple links, the network perimeter, or nearly all
  Internet links;
- record packet sizes, directions, timing, connection duration, retransmits,
  outages, routing changes, and user online periods;
- retain encrypted traffic for future cryptanalysis;
- observe hosting providers, AS paths, DNS, time synchronization, software
  downloads, bridge traffic, and public authority activity;
- compare observations across hours, epochs, months, and user behavior cycles.

The global passive observer is a target adversary for metadata-resistance
research and simulation. FOG MUST NOT claim resistance to that observer until
the complete deployed traffic process, including clients, storage access, and
cover traffic, has quantitative evidence.

### 7.2 Active network interference

The adversary may drop, delay, reorder, duplicate, replay, corrupt, tag,
inject, selectively forward, partition, throttle, or burst packets. It may
manipulate clocks and availability to trigger retries or route changes. It may
create distinguishable failure patterns and observe the resulting behavior.

The adversary may run malicious clients at scale and may attempt n-1,
confirmation, blending, flooding, resource-exhaustion, and amplification
attacks.

### 7.3 Infrastructure compromise and collusion

The adversary may compromise or operate:

- one or more entries, mixes, couriers, services, replicas, observers, or
  authorities;
- multiple roles on the same route;
- multiple nominal operators that secretly form one operator family;
- hosting providers, hypervisors, management networks, build systems, package
  registries, or time sources;
- an authority threshold sufficient to sign malicious consensus;
- enough storage replicas to destroy or correlate a mailbox;
- an edge bridge and the corresponding external service.

Compromise includes software exploitation, malicious updates, physical
access, legal compulsion, bribery, operator mistakes, secret copying, and
rollback to vulnerable state.

### 7.4 Endpoint and contact compromise

The adversary may compromise the online blind relay, the host running a
networkless microVM, a physically offline Composer, a transfer device, a
backup, or a recipient contact. It may use browser, firmware, peripheral,
DMA, side-channel, evil-maid, removable-media, or supply-chain attacks.

A malicious or compromised contact may send malformed messages, exhaust reply
material, correlate replies, reveal conversation state, lie about identity,
or intentionally publish plaintext and relationship metadata.

### 7.5 Cryptanalytic capability

The adversary may exploit weak parameters, nonce reuse, RNG failure, side
channels, parser differentials, protocol composition errors, implementation
bugs, downgrade paths, key reuse, and future cryptanalytic advances. A future
adversary may have practical quantum capability.

FOG assumes reviewed primitives remain secure only within their documented
parameters. Algorithm names alone are not security evidence.

## 8. Core Assumptions

All security claims depend on the following assumptions:

1. The sender and recipient Composers are not compromised while handling the
   protected plaintext or key state relevant to the claim.
2. Users obtain authentic Composer software, trust anchors, and updates.
3. Cryptographic random number generators provide sufficient entropy.
4. Selected primitives and libraries are correctly implemented and remain
   secure for their configured parameters.
5. At least one mix on a route is honest and its secret state is not exposed
   during the period relevant to per-hop route unlinkability.
6. The authority signing threshold is not compromised, and enough honest
   authorities remain available to produce consensus.
7. Composer and relay reject stale, rolled-back, malformed, or
   insufficiently signed consensus.
8. Declared operator families and infrastructure diversity reflect reality
   closely enough for path constraints to matter.
9. Traffic classes, packet geometry, delay distributions, retry behavior, and
   cover traffic are followed by all honest implementations.
10. The anonymity set has enough concurrent real and decoy activity for the
    measured privacy target. A nearly idle network cannot hide activity by
    declaration.
11. Users follow the operational profile attached to a claim. A networkless
    Composer does not help if its secrets are copied to an online system.
12. External bridges, recipients, and publication systems may disclose the
    content and metadata that their protocols inherently require.

Violating an assumption MUST narrow or invalidate the corresponding claim. It
MUST NOT be hidden behind a generic statement that FOG is anonymous.

## 9. Threat Catalogue and Required Responses

### TM-NET-01: Timing and volume correlation

An observer compares ingress and egress timing, size, direction, and burst
shape.

Required responses:

- fixed packet geometry within consensus-defined traffic classes;
- randomized independently sampled per-hop delays;
- normalized client transmission and retrieval schedules;
- decoy traffic and loops that use the same processing path as real traffic;
- padded storage operations and acknowledgments;
- no application-specific route, packet, or retry fingerprint;
- simulation and trace-based evaluation against realistic observers.

Residual risk: timing defenses reduce correlation advantage but cannot make
repetitive behavior, low traffic, or indefinite observation harmless.

### TM-NET-02: Long-term intersection and statistical disclosure

An observer records which users are active around repeated sends or receives
and intersects candidate sets over time.

Required responses:

- cover activity independent of message activity;
- retrieval schedules that continue across empty and non-empty states;
- delayed and padded acknowledgments;
- rotating unlinkable capabilities and reply material;
- immutable storage-epoch manifests with disjoint intermediate and final
  replicas under an explicit non-collusion assumption;
- client guidance that does not encourage deterministic schedules;
- long-horizon simulation and publication of residual disclosure risk.

Residual risk: intersection leakage exists in all practical systems when user
behavior and availability are sufficiently distinctive. Repeated polling of
one empty capability-derived box remains linkable at its final replicas.

### TM-NET-03: n-1 and active confirmation

An active adversary suppresses honest traffic, injects its own packets, or
forces distinctive bursts so that a target packet becomes isolated.

Required responses:

- decoy-loop health signals and anomaly detection;
- conservative behavior during unexplained traffic collapse;
- no immediate deterministic retry after loss;
- rate and admission controls that limit hostile traffic without creating
  stable user fingerprints;
- fault-injection tests that measure isolation and confirmation advantage;
- documented shutdown or degraded-mode policy when required anonymity
  conditions disappear.

Residual risk: a sufficiently strong active adversary can deny service and
may isolate traffic. FOG does not promise availability or anonymity under
arbitrary global active control.

### TM-NET-04: Replay and duplicate confirmation

An adversary replays packets or reply material and observes repeated effects.

Required responses:

- consensus-bound replay tags and bounded replay windows;
- replay state that survives ordinary process restarts for the required
  maximum packet lifetime;
- single-use reply material with atomic consumption;
- message-level deduplication that does not emit distinguishable responses;
- duplicate storage writes and reads handled idempotently;
- fail-closed behavior if required replay state is corrupt or unavailable.

### TM-NET-05: Tagging and malleability

An adversary modifies a packet and observes whether a later component reacts
differently.

Required responses:

- a reviewed KEMSphinx profile with authenticated routing data and the
  documented payload-integrity construction;
- constant-behavior rejection without detailed remote error oracles;
- no service action before complete packet and message validation;
- conformance and mutation tests covering every authenticated field;
- explicit analysis of SURB-specific tagging and confirmation risks.

### TM-NET-06: Packet, route, and implementation fingerprinting

An adversary distinguishes application, client version, route choice, or
fallback state.

Required responses:

- one authenticated profile and geometry per authorized traffic class and
  epoch;
- identical core processing for all native source applications;
- no packet autodetection, silent downgrade, or per-packet suite negotiation;
- complete authenticated consensus view for route construction;
- bounded version overlap and a clear minimum accepted epoch;
- rollout tests that prevent minority clients from becoming a fingerprint.

### TM-PKI-01: Sybil nodes and false operator diversity

An adversary obtains many node positions or hides common control behind
nominally different operators.

Required responses:

- permissioned admission for the initial network;
- signed operator-family declarations and conflict rules;
- independent verification of provider, ASN, jurisdiction, ownership, and
  administration where practical;
- route rejection when one declared family appears twice;
- transparent admission, suspension, and revocation records;
- no claim that permissionless Sybil resistance has been solved.

Residual risk: social and corporate control can be concealed. Governance and
operator investigation remain part of the security boundary.

### TM-PKI-02: Stale, rolled-back, frozen, split, or equivocated consensus

An adversary gives different network views to clients or prevents updates.

Required responses:

- threshold signatures over canonical consensus bytes;
- monotonically increasing epochs and explicit validity intervals;
- current and next keys with bounded overlap;
- persisted highest-accepted epoch and rollback protection;
- independent retrieval paths or gossip for equivocation evidence;
- fail-closed behavior when quorum, time validity, or profile authorization
  cannot be established;
- an offline-safe recovery procedure for long-disconnected Composers.

Residual risk: a compromised signing threshold can authorize malicious
topology. A fully isolated client may not learn that another valid-looking
view exists without an external consistency mechanism.

### TM-PKI-03: Authority outage or capture

One or more authorities withhold votes, disappear, leak keys, or act under
compulsion.

Required responses:

- threshold operation with documented safety and liveness limits;
- offline root and recovery material separated from online epoch keys;
- rehearsed revocation and authority-replacement ceremonies;
- deterministic consensus failure behavior;
- no automatic trust-on-first-use replacement authority.

### TM-ROLE-01: Malicious entry or blind relay

A blind relay observes the local user context. An entry observes the relay
connection and first mix hop. On a reply, the entry also observes one random
short-lived rendezvous capability and reply ID while performing the terminal
KEMSphinx unwrap. Either role may delay, drop, batch, or fingerprint traffic.

Required responses:

- the Composer exports only opaque authenticated bundles;
- the blind relay cannot alter Composer-approved consensus or the internal
  route;
- entry choice is constrained to a small authenticated temporary set;
- traffic normalization begins before application-dependent variation reaches
  the entry;
- entry rotation is by session or epoch, not every message by default;
- entry return KEMSphinx keys are separate from forward capsule and mix keys;
- return rendezvous capabilities and reply IDs are random, bounded,
  single-use, and do not create a durable entry account;
- clients detect sustained failure without switching to a privacy-bypassing
  direct path.

Residual risk: a compromised blind relay can associate the local endpoint with
FOG use and can deny service. Collusion with downstream observation increases
correlation power.

### TM-ROLE-02: Malicious mix or route collusion

A mix observes adjacent hops and local timing. Multiple malicious mixes share
their observations or secrets.

Required responses:

- independent operators and family-constrained route construction;
- per-epoch mix keys with overlap only where required;
- KEMSphinx transformation and replay detection at every mix;
- no detailed per-packet logs;
- cover traffic processed identically to real traffic;
- compromise simulations for every layer and route position.

Residual risk: if all privacy-relevant hops on a route collude, route
unlinkability is not guaranteed. Later key disclosure may affect recorded
packets depending on the final KEMSphinx construction and key-erasure policy.

### TM-ROLE-03: Malicious courier, service, or storage replica

These roles correlate operations, return malformed data, selectively fail,
exhaust capabilities, or destroy records.

Required responses:

- message-level ciphertext remains opaque through all three roles;
- rotating capabilities and pseudorandom record locations;
- courier and replica knowledge separated by protocol design;
- at least four independently operated replicas for the intended profile;
- authenticated encrypted replica envelopes;
- final-replica receipts that distinguish courier acceptance from evidence of
  durable local commit;
- uniform treatment of empty reads, hits, misses, retries, and acknowledgments;
- quorum or erasure behavior that survives defined replica loss;
- bounded retention, tombstones, quotas, and non-amplifying requests;
- client verification of every retrieved object before state transition.

Residual risk: enough colluding replicas can correlate or destroy access. A
malicious service may learn application-level information that the final
service contract explicitly exposes.

### TM-ENDPOINT-01: Composer compromise

Malware, physical access, a hostile host, firmware, peripheral, or malicious
update captures plaintext or keys.

Required responses:

- a MicroVM profile with no virtual network interface and a minimal device
  boundary;
- a Portable profile with signed immutable media, disabled network and radio
  drivers, and no automatic internal-disk mounting;
- authenticated encryption for identities, contacts, drafts, and backups;
- purpose-separated keys and minimal plaintext lifetime;
- no secrets in logs, crash dumps, swap, thumbnails, previews, or generic
  desktop indexing;
- signed updates with rollback protection and a documented offline ceremony;
- explicit warning that endpoint compromise defeats local confidentiality and
  authenticity.

Residual risk: software cannot preserve a secret while an attacker controls
the component using it. A networkless VM on a compromised host is weaker than
a physically isolated Composer.

### TM-ENDPOINT-02: Malicious transfer input and bidirectional leakage

A crafted QR, FOG-SX stream, removable device, or optical peripheral exploits
the parser or creates an unintended return channel.

Required responses:

- one minimal bounded binary format per transfer direction;
- no generic archives, filesystems, documents, HTML, scripts, or executable
  content;
- fixed maximum sizes, allocation limits, canonical encodings, and complete
  validation before interpretation;
- fuzzing and property tests for frame, FEC, and bundle parsers;
- transfer checksum treated only as error detection, never authenticity;
- inner bundle authentication before any semantic or Composer state change;
- no automatic acknowledgment or reverse data path in the high-assurance
  FOG-SX profile;
- physical inspection that transmit-only and receive-only devices cannot
  silently reverse direction.

Residual risk: optical, acoustic, electromagnetic, thermal, and human-mediated
channels may still leak information outside the protocol model.

### TM-ENDPOINT-03: Backup, recovery, and multi-device leakage

Backups or device synchronization copy identity and conversation state into a
weaker environment.

Required responses:

- backups encrypted and authenticated independently from the live store;
- backup keys or recovery secrets stored separately from backup ciphertext;
- explicit key and format version in every encrypted store;
- tested restore, rotation, revocation, and lost-device procedures;
- no server-side recovery secret capable of silently impersonating a user;
- multi-device behavior treated as a separate protocol state machine, not file
  copying.

### TM-APP-01: Malicious contact and conversation insider

A valid contact sends malformed or adversarial messages, correlates replies,
publishes shared state, or exploits group membership changes.

Required responses:

- strict authenticated message parsing before rendering;
- no active content or automatic external resource loading;
- per-contact rate, size, and state-transition bounds;
- single-use reply material and safe exhaustion behavior;
- transcript and membership rules defined by the messaging specification;
- explicit warning that a storage writer may read and tombstone its own
  dedicated directional stream when the selected capability construction
  grants that authority;
- compromised-contact analysis for direct and group messaging;
- no promise that encryption prevents a recipient from revealing plaintext.

### TM-OPS-01: Logging and metrics leakage

Operators, attackers, or support workflows recover metadata from logs,
traces, crash reports, metrics, or dashboards.

Required responses:

- logs MUST NOT contain payloads, contacts, capabilities, message or packet
  identifiers, full routes, per-packet delay, or fine-grained event timing;
- production debug logging MUST be disabled;
- metrics MUST be coarse, delayed, aggregated, thresholded, and reviewed for
  differencing attacks;
- node health identifiers MUST not become message-flow identifiers;
- crash dumps and support bundles MUST be disabled or privacy-scrubbed by
  default;
- retention MUST be minimal and explicitly documented.

Residual risk: even aggregate metrics can leak during low-volume periods.
Metrics may need suppression rather than publication.

### TM-SUPPLY-01: Build, dependency, and update compromise

An attacker inserts malicious code, changes protocol parameters, substitutes a
binary, compromises a dependency, or rolls a node back.

Required responses:

- pinned reviewed dependencies and recorded provenance;
- reproducible or independently verifiable release builds where practical;
- multiple-person release review for security-critical changes;
- signed canonical release metadata with version and rollback constraints;
- separate release, authority, node, and user identity keys;
- secure boot or measured boot where the deployment profile supports it;
- emergency revocation that does not create an unauthenticated update path.

### TM-CRYPTO-01: Key compromise and lifecycle failure

A key is copied, reused, retained too long, generated weakly, or not revoked.

Required responses:

- a key inventory defining owner, purpose, scope, storage, lifetime, overlap,
  backup, revocation, and destruction;
- distinct keys for authority identity, epoch signing, release signing, Noise,
  KEMSphinx, message identity, ratchet state, storage, capability derivation,
  and backup encryption;
- cryptographic randomness from reviewed operating-system facilities;
- authenticated encrypted storage for long-lived private material;
- support for old verification keys only for explicit bounded migration;
- immediate stop of new use after compromise, followed by revocation and
  replacement;
- best-effort zeroization without claiming that managed runtimes erase every
  copy.

### TM-CRYPTO-02: Store now, decrypt later and protocol downgrade

An adversary records traffic for future classical or quantum cryptanalysis or
forces an older suite.

Required responses:

- suite and geometry authorization bound to signed epoch consensus;
- protocol identifiers authenticated in every relevant transcript;
- no silent fallback or operator-selectable downgrade;
- hybrid post-quantum constructions considered only after full packet,
  performance, side-channel, and implementation review;
- bounded suite overlap and a published retirement procedure;
- claims separated into classical confidentiality, forward secrecy, and
  post-quantum confidentiality.

Residual risk: no deployed post-quantum construction can eliminate future
cryptanalytic uncertainty or endpoint compromise.

### TM-AVAIL-01: Flooding, storage exhaustion, and distributed denial of service

An adversary creates clients, packets, reads, writes, fragments, or authority
traffic at scale.

Required responses:

- strict size, rate, queue, memory, CPU, and concurrency bounds at every
  boundary;
- admission or capability controls that avoid stable cross-service identity;
- non-amplifying error handling and bounded cryptographic work before
  authentication where possible;
- storage quotas, expiry, tombstones, garbage collection, and overload policy;
- graceful shedding that preserves packet-class indistinguishability where
  possible;
- simulation and load testing with malicious distributions;
- no availability claim against sustained global distributed attack.

## 10. Trust Effects of Role Compromise

The expected effect of isolated compromise is summarized below. Collusion can
combine observations and exceed these bounds.

| Compromised role | Immediate exposure | Property that should remain |
| --- | --- | --- |
| Composer | That endpoint's plaintext, keys, contacts, and future local actions | Other users and unrelated conversations |
| Blind relay | Local endpoint context and FOG-use timing | Message plaintext and internal route secrecy |
| Entry | Relay address, first-hop traffic, next mix, and short-lived return metadata | Plaintext and final recipient |
| One mix | Adjacent hops, local timing and local secret state | End-to-end content; route unlinkability if another relevant mix is honest |
| One authority | Descriptors, votes and ability to withhold | Consensus authenticity without threshold compromise |
| Courier | Service request pattern and required replica routing | Message plaintext and direct client network identity |
| One replica | Local opaque records and access timing | Plaintext and complete mailbox stream |
| Native service | Explicit service-level fields | Network source and unrelated application state |
| Observer | Approved coarse aggregates | Per-message and per-user activity |
| Edge bridge | External-side protocol metadata | No extension of core anonymity through that bridge |

The architecture specification MUST refine this table into exact information
flows and process privileges before implementation.

## 11. Composer Security Profiles

### 11.1 MicroVM profile

The MicroVM MUST have no virtual network interface. Its host integration MUST
be limited to explicit display, human input, and the smallest feasible
transfer device. Clipboard sharing, host filesystem mounts, drag-and-drop,
guest agents, shared memory, audio input, camera input, and USB passthrough
MUST be disabled unless a later profile specifies and analyzes them.

The MicroVM profile assumes the host can deny service and observe coarse user
activity. It MUST NOT claim protection from a host that can inspect guest
memory or replace the hypervisor.

### 11.2 Portable profile

The Portable profile MUST boot from signed immutable media, disable network
and radio support, avoid automatically mounting internal disks, and keep
mutable state in an authenticated encrypted store. Boot integrity and update
verification MUST occur without requiring an unauthenticated online channel.

The high-assurance profile MUST NOT connect its Composer media to an online
computer. A removable device shuttled between online and offline systems is a
separate lower-assurance profile.

Both profiles distinguish authenticated local state from freshness. A local
hash or MAC chain cannot detect replacement of the complete vault, journal,
and keys by an older coherent copy. A complete rollback-detection claim
requires a monotonic anchor outside the stated rollback domain. A host-
controlled virtual TPM is not independent of a hostile MicroVM host.

### 11.3 Import and export boundary

Consensus, contact vouchers, messages, updates, recovery packages, and FOG-SX
bundles are untrusted until cryptographically verified. Human-readable labels,
filenames, MIME types, QR presentation, or transport checksums do not confer
authenticity.

## 12. Key Management Requirements

Every protocol specification MUST provide a key-lifecycle table containing:

- key name and cryptographic purpose;
- generating component and entropy source;
- authorized readers and operations;
- storage and hardware assumptions;
- epoch, session, message, or long-term lifetime;
- current and next-key overlap;
- compromise impact;
- revocation and recovery procedure;
- backup policy;
- destruction and residual-copy limitations.

Private keys MUST NOT appear in source repositories, examples, test fixtures,
logs, command lines, crash reports, container images, or consensus documents.
Tests MUST use generated ephemeral fixtures.

Authority, release, and offline recovery keys SHOULD have distinct offline
storage and ceremonies. Online services MUST receive only the minimum
short-lived material required for their role.

## 13. Protocol Parsing and Failure Behavior

Every parser MUST:

- operate on a versioned format with an exact maximum size;
- reject non-canonical, truncated, overlong, duplicate, unknown-critical, and
  trailing data where the format does not explicitly permit it;
- bound allocations, nesting, fragment count, decompression, FEC work, and
  cryptographic work;
- authenticate before acting on semantic content whenever the protocol allows;
- avoid detailed remote errors that create parsing or validity oracles;
- produce deterministic local error classes suitable for testing without
  logging sensitive input;
- be covered by conformance vectors, mutation tests, fuzzing, and differential
  tests where an independent implementation exists.

Core nodes MUST NOT parse generic archives, office documents, HTML, scripts,
or executable formats.

## 14. Privacy-Preserving Operations

Operational tooling is within the threat model. Deployments MUST define:

- which metrics exist, their aggregation window, release delay, and minimum
  population threshold;
- which logs exist, their fields, retention, access control, and deletion;
- how operators diagnose packet loss without packet-level identifiers;
- how key ceremonies, node admission, revocation, and emergency changes are
  audited;
- how configuration drift and unsafe debug modes are detected;
- how time synchronization failure is detected without creating a single
  trusted time source;
- how backup restore and disaster recovery avoid cloning live identities or
  replay state.

Public dashboards MUST suppress data when aggregation would reveal the
activity of a small number of users or nodes.

## 15. Claims FOG Does Not Make

FOG does not claim:

- protection after sender or recipient Composer compromise;
- guaranteed delivery or resistance to arbitrary denial of service;
- absolute anonymity or zero metadata leakage;
- protection when all relevant route positions collude;
- that a three-node PoC has a meaningful production anonymity set;
- that encryption prevents recipients from revealing plaintext;
- permanent storage, guaranteed offline retrieval beyond the active retention
  window, or deletion from every recipient, backup, journal, and adversarial
  copy after a tombstone;
- deniability unless the selected messaging protocol explicitly provides and
  validates it;
- post-quantum security based only on the presence of a post-quantum primitive;
- privacy across SMTP, NNTP, web, or foreign-network bridges equal to the FOG
  core;
- protection from all physical, electromagnetic, acoustic, supply-chain,
  coercion, or future cryptanalytic attacks;
- that permissioned admission completely prevents concealed Sybil control;
- that offline operation automatically makes a compromised device safe.

## 16. Validation and Claim Gates

### 16.1 Before the local PoC

Required evidence:

- normative architecture and trust-boundary specification;
- PKI, wire, packet, profile, messaging, storage, Composer, and FOG-SX
  specifications;
- exact packet and message geometry;
- protocol state machines and key-lifecycle tables;
- conformance vectors and parser limits;
- simulator scenarios and measurable privacy metrics.

`FOG-SIMULATION.md` supplies the first deterministic scenario and proxy-metric
baseline. This gate remains incomplete because formal end-to-end observer
metrics, replies, retries, storage polling, loop health, queues, congestion,
user behavior, churn, confidence intervals, and PoC trace calibration remain
open.

`FOG-LOCAL-POC.md` supplies the first machine-readable local deployment and
fault-matrix definition. Its strict validator fixes the functional-only claim,
role separation, pairwise reachability, private state and secret scopes,
container containment, and required failure cases. The runnable fixture and
protocol-functional evidence remain open.

### 16.2 Before an operator alpha

Required evidence:

- unit, integration, conformance, fuzz, race, and fault-injection testing;
- replay, tagging, n-1, flooding, clock, stale-consensus, split-authority,
  node-loss, and storage-loss tests;
- simulation using observed or conservatively modeled traffic distributions;
- at least six mix nodes with two per layer and documented operator-family,
  provider, ASN, and location diversity;
- at least three authorities with a 2-of-3 quorum;
- at least four storage replicas;
- reproducible deployment and rollback procedures;
- public documentation that alpha anonymity is experimental.

### 16.3 Before production security claims

Required evidence:

- independent cryptographic and implementation review;
- resolved high-severity findings and published residual risks;
- realistic traffic volume and mandatory cover traffic;
- operational exercises for compromise, revocation, partition, restore, and
  authority replacement;
- independently verified release provenance;
- quantitative claim statements tied to exact software, profile, topology,
  traffic assumptions, and review version.

Every public claim MUST identify its scope, assumptions, adversary capability,
software version, network profile, evidence, and known counterexamples.

## 17. Open Security Decisions

The following remain unresolved and block stronger claims:

- activation of a byte-exact reviewed message profile after the structural
  `FOG-MESSAGING` contract and its non-active PQXDH, Triple Ratchet, and
  ML-KEM Braid candidate pass implementation and integration review;
- activation of the non-active SHA3-256 and ML-DSA-65 plus Ed25519 PKI
  candidates after exact encoding, vectors, separability, implementation, and
  side-channel review;
- the exact entry and mutual hybrid post-quantum Noise constructions and
  reviewed library; X-Wing is only the leading KEM to evaluate;
- activation of the calculated HPQC split-PRF KEMSphinx candidate after exact
  dependency, primitive, side-channel, complete-packet benchmark, vector,
  simulation, and independent review;
- activation of a byte-exact reviewed storage profile after the structural
  `FOG-STORAGE` contract and its non-active narrow BACAP/Pigeonhole candidate
  pass receipt, geometry, implementation, DoS, and integration review;
- activation of exact Composer vault, platform, bundle, recovery, update, and
  independent monotonic-anchor profiles after the structural
  `FOG-COMPOSER` contract passes fault and implementation review;
- activation of one exact numeric FOG-SX joint profile after its fixed frame,
  object, padding, parser, no-ACK, and physical-direction contract passes FEC,
  implementation, license and IPR, resource, vector, hardware, and independent
  review;
- cover, loop, delay, retry, retrieval, and acknowledgment distributions;
- identity compromise, revocation, contact recovery, and multi-device state
  beyond the identity-only non-resumable recovery baseline;
- safe anonymous admission and rate control for clients;
- measurable degraded-mode thresholds and shutdown behavior.

No implementation convenience may silently resolve these questions.

## 18. Residual Risk Statement

Even a correctly implemented FOG network will retain risk from endpoint
compromise, malicious contacts, long-term statistical disclosure, low traffic,
operator collusion, concealed common control, active denial of service,
physical and supply-chain compromise, bridge metadata, coercion, and future
cryptanalysis. Cover traffic and delay exchange bandwidth and latency for
reduced observer advantage; they do not create certainty.

FOG's security documentation MUST remain a living record of observed attacks,
failed assumptions, simulation results, operational incidents, and changed
claims.

## 19. Primary References

- FOG messaging protocol: `FOG-MESSAGING.md`
- FOG storage protocol: `FOG-STORAGE.md`
- FOG Composer protocol: `FOG-COMPOSER.md`
- FOG simplex transfer protocol: `FOG-SX.md`
- FOG observability protocol: `FOG-OBSERVABILITY.md`
- FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
- FOG traffic and topology simulation: `FOG-SIMULATION.md`
- FOG local Podman PoC: `FOG-LOCAL-POC.md`
- Danezis and Goldberg, *Sphinx: A Compact and Provably Secure Mix Format*:
  <https://eprint.iacr.org/2008/475>
- Piotrowska et al., *The Loopix Anonymity System*:
  <https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska>
- Infeld et al., *Echomix: a Strong Anonymity System with Messaging*:
  <https://arxiv.org/abs/2501.02933>
- Katzenpost mixnet threat model:
  <https://katzenpost.network/docs/threat_model/>
- Katzenpost protocol specifications:
  <https://katzenpost.network/docs/specs/>
- Noise Protocol Framework:
  <https://noiseprotocol.org/noise.html>

References inform FOG's attack coverage and terminology. They do not make FOG
secure by inheritance. FOG requires its own profiles, proofs or analyses,
tests, simulations, deployments, and reviews.