Publish FOG design documentation and Merkle tree

1 files changed, 962 insertions, 0 deletions

diff --git a/docs/FOG-THREAT-MODEL.md b/docs/FOG-THREAT-MODEL.md
new file mode 100644
index 0000000..f0dde91
--- /dev/null
+++ b/docs/FOG-THREAT-MODEL.md
@@ -0,0 +1,962 @@
+# 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.