1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
# 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.
|
