From 25356debcce4118cdfa86842029278fde1e64518 Mon Sep 17 00:00:00 2001 From: Gab <24553253+gabrix73@users.noreply.github.com> Date: Tue, 18 Aug 2026 21:43:48 +0200 Subject: Publish FOG design documentation and Merkle tree --- docs/FOG-THREAT-MODEL.md | 962 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 962 insertions(+) create mode 100644 docs/FOG-THREAT-MODEL.md (limited to 'docs/FOG-THREAT-MODEL.md') 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*: + +- 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. -- cgit v1.2.3