# FOG Status: public design and evidence documentation This repository intentionally publishes documentation only. It contains no production daemon, private deployment material, operator inventory, runtime secret, or claim that FOG currently provides anonymity. The integrity of every published Markdown file is committed by `merkle-tree.txt`. FOG will be an autonomous, modular network for asynchronous private communication. Its initial native services will be one-way drops, anonymous mailboxes, direct messages, and asynchronous chat. SOCKS, VPN, web proxying, and public Internet exits are excluded from the current design. FOG is one coherent product, but its security roles remain separable: ```text offline Composer | | QR or FOG-SX one-way transfer v online blind relay | random temporary entry selected from signed FOG-PKI consensus | entry gateway | mix layer 1 -> mix layer 2 -> mix layer 3 | courier / native service | four or more distributed storage replicas | recipient blind relay | recipient Composer decrypts and verifies ``` The Composer encrypts each message for the recipient before it leaves the offline environment. The blind relay, entry, mixes, courier, and storage never receive plaintext. KEMSphinx protects routing through the mixnet, while Noise protects each adjacent online connection. These layers use different keys and do not replace one another. Contacts use private pairwise identities and targeted single-use vouchers, not global usernames. The Composer persists each ratchet transition together with its exact fixed message envelope before export. Storage then persists an immutable box and courier request generation. Retransmission reuses those storage bytes for deduplication but receives fresh route, KEMSphinx, entry, rendezvous, and reply material. Authenticated message acknowledgments report durable receiving-Composer commit, never that a human read the message. Each conversation direction uses a separate evolving capability stream. Two final replicas store each pseudorandom box, while two disjoint intermediate replicas prevent the courier from learning the final pair. At least four independent storage replicas are required. Courier acceptance is not storage durability; ordinary durability requires authenticated receipts from both final replicas. Empty reads do not advance a stream, and signed tombstones prevent data resurrection until bounded expiry. FOG uses one source tree and coordinated release, but each online security role is a separate executable with its own identity, keys, writable state, account, configuration, and network policy. The initial `fog-drop`, `fog-mailbox`, and `fog-im` features run as Composer-side modules over one common messaging and storage protocol, not as distinguishable public services. The Composer can run as a networkless microVM on an online host or as a portable bootable USB system on a physically offline computer. High-assurance transfer avoids USB shuttling and uses QR or `FOG-SX`, an acknowledgment-free simplex protocol. The preferred physical FOG-SX backend is a one-way TOSLINK fiber called `FOG Lightpipe`. FOG-SX fixes bounded padded objects and frames, but its RaptorQ and Reed-Solomon FEC options and its QR, Lightpipe, and MIDI physical profiles remain non-active pending implementation, hardware, and resource review. Visible light, audio modem, and paper tape remain possible future backends. Composer software boots from an authenticated read-only image and keeps mutable secrets in a volume-encrypted, object-authenticated transactional vault. Imports are hostile fixed bundles; exports contain only committed opaque work. A local commitment chain is not presented as complete rollback protection. That claim requires an independent monotonic anchor outside the vault and host rollback domain. Identity recovery does not resume stale live ratchets, capabilities, prekeys, or outboxes. An entry is never globally predefined. The blind relay randomly selects a small temporary set from the signed consensus and rotates it by session or epoch. It chooses only among opaque entry variants prepared by the Composer and does not learn the first internal mix hop. The entry remains separate from the three mix hops. Paths avoid using the same operator more than once. Three independent mix nodes are enough for a functional local PoC, not for production anonymity. Six mix nodes are the minimum meaningful alpha target, and nine mix nodes are the preferred initial network target. At least four storage replicas and three independent directory authorities are also needed. FOG will use signed epoch consensus, fixed packet sizes, randomized mixing delays, replay protection, traffic padding, decoy traffic, capability-based mailboxes, safe retries, and privacy-minimizing logs. The current non-active cryptographic shortlist uses SHA3-256 and mandatory ML-DSA-65 plus Ed25519 for PKI evaluation, the exact HPQC ML-KEM-768 plus X25519 split-PRF construction for the calculated KEMSphinx candidate, and PQXDH plus Triple Ratchet and ML-KEM Braid for messaging. X-Wing leads the adjacent-link KEM evaluation, but FOG has not selected an exact post-quantum Noise profile. `FOG-WIRE-1` protects adjacent online links with TCP and one exact consensus-authorized Noise profile. Relay-to-entry connections authenticate the entry without assigning the relay a stable Noise identity; all node, authority, courier, storage, and observer links use mutual role-specific authentication. A fixed preface and authenticated prologue bind the network, epoch, consensus, roles, peers, keys, and adjacency. Encrypted records have one fixed size per profile, rekey after every record, and force a fresh handshake at bounded record, byte, time, epoch, profile, or authorization boundaries. There is no runtime profile negotiation, 0-RTT, resumption, TLS fallback, or generic RPC bus. `FOG-PKI-1` uses complete deterministic consensus documents with independent M-of-N authority signatures. Authority roots stay offline and certify rotating online voting keys. Consumers never merge partial directory views. Offline Composers retain monotonic state and verify newer consensus through a threshold-signed append-only checkpoint, archive inclusion, and a Merkle consistency proof. The initial claim-bearing quorum is 2-of-3. FOG will preserve Sphinx-family application compatibility through a stable client SDK and explicit, consensus-authorized packet profiles. Core nodes will not auto-detect foreign Sphinx variants or negotiate packet suites. Bridges to specific external mix networks remain isolated edge adapters with separately documented cross-network correlation risks. The normative baselines are `docs/FOG-THREAT-MODEL.md`, `docs/FOG-ARCHITECTURE.md`, `docs/FOG-PKI.md`, `docs/FOG-WIRE.md`, `docs/FOG-SPHINX-PROFILES.md`, `docs/FOG-MESSAGING.md`, `docs/FOG-STORAGE.md`, `docs/FOG-COMPOSER.md`, `docs/FOG-SX.md`, and `docs/FOG-OBSERVABILITY.md`. `docs/FOG-CRYPTO-SUITES.md` is the current non-normative selection and evidence record. Cryptographic properties are tied to exact protocols and implementations. All named cryptographic, messaging, and narrow BACAP/Pigeonhole storage candidates remain non-active pending exact integration evidence. Anonymity, unlinkability, and unobservability remain conditional on measured traffic, cover, topology, operator independence, endpoint integrity, and the stated adversary. The global passive observer is a simulation and validation target, not a present guarantee. `docs/FOG-SIMULATION.md` records the first deterministic traffic and topology comparison matrix. It confirms that the functional PoC and sparse traffic are not anonymity evidence, and it selects no numeric cover, delay, polling, topology, or degraded-mode profile. The remaining formal observer, storage, loop, queue, behavior, churn, and trace-driven models precede any such selection. `FOG-OBSERVABILITY-1` now fixes the structural operations boundary. Production roles emit no packet or request event streams. They collect only closed typed metrics in coarse windows, export bucketed fixed-shape aggregates after a delay, suppress traffic-sensitive values under a minimum activity threshold, and keep bounded local summaries. The Composer and FOG-SX roles have no automatic observer path. A public view requires multi-reporter aggregation, fixed grouping, delayed non-overlapping windows, low-population suppression, and anti-differencing review. No numeric observability profile or observer service is active. Development proceeds from specifications and simulation through functional fixtures, fault injection, an independent-operator alpha, and external review before any real anonymity claim. `docs/FOG-LOCAL-POC.md`, `docs/FOG-SECURITY-TEST-PLAN.md`, and `docs/FOG-ALPHA.md` describe the functional test boundaries and the next transition without pretending that local containers are independent operators. A reproducible local six-mix laboratory has completed its 13 fault families, but it remains a non-cryptographic functional fixture. No FOG protocol daemon or public network exists. The 19 distributed-alpha evidence gates remain open pending active profiles, real daemons, governance, independent operators, independent reproduction, and review. Supporting documents cover cryptographic evaluation, simulation, local PoC constraints, security testing, alpha readiness, and PoC preservation. The implementation and raw test workspace are deliberately outside this documentation-only publication.