# 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*: - Piotrowska et al., *The Loopix Anonymity System*: - Infeld et al., *Echomix: a Strong Anonymity System with Messaging*: - Katzenpost mixnet threat model: - Katzenpost protocol specifications: - Noise Protocol Framework: 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.