diff options
Diffstat (limited to 'docs/FOG-CRYPTO-SUITES.md')
| -rw-r--r-- | docs/FOG-CRYPTO-SUITES.md | 833 |
1 files changed, 833 insertions, 0 deletions
diff --git a/docs/FOG-CRYPTO-SUITES.md b/docs/FOG-CRYPTO-SUITES.md new file mode 100644 index 0000000..48402c1 --- /dev/null +++ b/docs/FOG-CRYPTO-SUITES.md @@ -0,0 +1,833 @@ +# FOG Cryptographic Suite Evaluation + +Status: Evaluation Draft 0.1 +Date: 2026-08-08 + +## 1. Purpose + +This document evaluates concrete cryptographic constructions for the distinct +security roles in FOG. It narrows the pre-implementation candidates without +activating a numeric protocol profile or treating algorithm names as security +evidence. + +The outcome is deliberately not one global cryptographic suite. FOG needs +different constructions for: + +1. PKI object hashing and authentication; +2. KEMSphinx packet construction; +3. adjacent-link Noise handshakes; +4. Composer-to-Composer end-to-end messaging. + +Each role has a different transcript, failure boundary, lifetime, packet-size +cost, implementation surface, and security requirement. A construction +appropriate for one role is not automatically appropriate for another. + +This evaluation is subordinate to `FOG-THREAT-MODEL.md` and the structural +protocol specifications. It does not change packet geometry, wire records, +messaging state machines, or PKI quorum rules except for the explicit PKI +signature-suite binding correction in Section 7.4. + +## 2. Status and Non-Goals + +This document: + +- records the standards and implementation evidence inspected on 2026-08-08; +- advances named, non-active candidates where the evidence is sufficient; +- records where an exact construction or implementation is still missing; +- defines common activation, benchmarking, dependency, and claim gates; +- prevents one candidate from being reused silently across security roles. + +This document does not: + +- assign a numeric hash, signature, KEM, wire, packet, or messaging profile; +- invent a KEM, KEM combiner, signature combiner, Noise pattern, ratchet, KDF, + AEAD, stream cipher, or wide-block construction; +- claim production post-quantum security, forward secrecy, post-compromise + security, deniability, anonymity, or side-channel resistance; +- make an Internet-Draft equivalent to a final standard; +- approve a library merely because it implements a standardized primitive; +- make a construction secure by inheritance from another protocol. + +Numeric activation remains a separate reviewed decision after the gates in +this document and the owning protocol specification pass. + +## 3. Evaluation Invariants + +### CRYPTO-INV-01: Purpose-specific suite families + +PKI, KEMSphinx, Noise, and messaging use separate suite records, identifiers, +keys, APIs, test vectors, and transition state. There is no universal runtime +crypto registry exposed to untrusted input. + +### CRYPTO-INV-02: Exact profile before attacker input + +The already authenticated consensus, connection context, packet geometry, or +local messaging state selects one exact suite before parsing or cryptographic +work. An implementation never trial-verifies alternate suites. + +### CRYPTO-INV-03: No component fallback + +A hybrid or composite construction succeeds only when its exact definition +succeeds. It never falls back to a surviving classical or post-quantum +component after a component, encoding, randomness, or verification failure. + +### CRYPTO-INV-04: Exact encoding and domain separation + +Every combiner input has a fixed, unambiguous encoding and an exact domain +string. Raw concatenation of variable-length values is forbidden. Algorithm, +profile, role, transcript, and public context fields required by the reviewed +construction are included exactly once in the defined order. + +### CRYPTO-INV-05: Independent keys + +Component keys are generated independently. Keys are additionally separated +by protocol, role, direction where applicable, owner, profile, and epoch or +session. A key component is not copied from another suite record. + +### CRYPTO-INV-06: Uniform remote failure + +Malformed lengths are rejected before expensive work. Component failures, +decapsulation failures, authentication failures, and padding failures collapse +to the owning protocol's coarse remote behavior. Diagnostics do not reveal +which component failed. + +### CRYPTO-INV-07: Evidence is construction-specific + +A claim names the exact construction, parameter set, encoding, implementation +revision, build, platform, key lifecycle, and test evidence. A primitive's +standardization does not validate its integration. + +### CRYPTO-INV-08: Transitions do not negotiate + +Old and new suites may overlap only through an authenticated, bounded PKI +transition. They use separate keys and state. Failure of the new suite does +not extend, reactivate, or select the old suite. + +## 4. Standards Snapshot + +The following snapshot is part of the evaluation record. A future activation +review MUST check for revisions, errata, withdrawals, and implementation +changes after this date. + +| Item | Status used by this evaluation | Relevant consequence | +| --- | --- | --- | +| FIPS 203, ML-KEM | final standard; NIST page carries a pending-update note | ML-KEM-768 is the leading standardized KEM parameter set, but errata must be frozen into the implementation review | +| FIPS 204, ML-DSA | final standard; NIST page carries a pending-update note | ML-DSA-65 is the leading standardized PQ signature component; hedged signing is the production candidate | +| FIPS 205, SLH-DSA | final standard | useful diversity candidate, but its signatures are too large for the first ordinary PKI suite | +| NIST SP 800-227 | final, September 2025 | provides KEM-use, key-confirmation, input-validation, ephemeral-key, and composite-KEM guidance | +| RFC 9794 | informational terminology | separates post-quantum and traditional components without proving a hybrid integration | +| RFC 9955 | informational hybrid-signature analysis | requires explicit analysis of separability, downgrade, binding, and artifacts | +| RFC 9980 | proposed-standard OpenPGP profile | provides a deployed standards precedent for ML-DSA-65 plus Ed25519 and ML-KEM-768 plus X25519, but its OpenPGP encoding is not a FOG wire format | +| X-Wing CFRG draft | Internet-Draft | a serious hybrid KEM candidate, not yet a final general-purpose RFC | +| PQNoise | reviewed paper and artifact lineage | supports KEM-based Noise analysis, but does not define FOG's required exact entry and mutual-authentication profiles | +| PQXDH revision 3 | maintained Signal specification | leading asynchronous handshake candidate, with authentication limitations that remain explicit | +| Double Ratchet revision 4 | maintained Signal specification | defines Triple Ratchet and the Sparse Post-Quantum Ratchet integration | +| ML-KEM Braid revision 1 | maintained Signal specification | leading continuous post-quantum ratchet component using ML-KEM-768 | + +The NIST notes are not license to select whichever behavior an implementation +happens to expose. Activation pins the standard edition, incorporated errata, +known-answer tests, and rejection behavior. + +## 5. Parameter and Artifact Sizes + +These are raw primitive sizes, not complete FOG objects or packets. + +| Primitive | Public or encapsulation key | Ciphertext or signature | Secret output or note | +| --- | ---: | ---: | --- | +| X25519 | 32 bytes | 32-byte public contribution | 32-byte shared value before protocol KDF | +| Ed25519 | 32 bytes | 64-byte signature | classical signature component | +| ML-KEM-768 | 1,184 bytes | 1,088-byte ciphertext | 32-byte shared secret | +| ML-DSA-65 | 1,952 bytes | 3,309-byte signature | NIST category 3 parameter set | +| ML-DSA-65 plus Ed25519 | 1,984 bytes | 3,373 bytes | raw component totals before FOG framing | +| SLH-DSA-SHA2-128s | 32 bytes | 7,856-byte signature | category 1, small public key but large signature | + +ML-KEM-768 is the common PQ KEM component advanced across current candidates. +That reduces implementation diversity, but it does not authorize key reuse or +a common KEM combiner. Every protocol still has independent keys, transcripts, +and failure handling. + +FOG does not describe the selected parameter sets as one exact symmetric-bit +security number. Classical and post-quantum categories, multi-user effects, +protocol composition, implementation leakage, and traffic analysis do not +collapse honestly to one marketing figure. + +## 6. Evaluation Outcome + +| Security role | Leading result | Status after this evaluation | +| --- | --- | --- | +| PKI object hash | SHA3-256 | first-host benchmark complete, still non-active | +| PKI signatures | ML-DSA-65 plus Ed25519, both mandatory over one FOG-bound input | first-host benchmark complete, still non-active | +| KEMSphinx KEM | HPQC ML-KEM-768 plus X25519 split-PRF construction in the already calculated order | first-host complete-packet benchmark complete, still non-active | +| KEMSphinx remaining primitives | evaluated Katzenpost KDF, MAC, stream, AEZ SPRP, and payload-tag integration | hold pending side-channel, AEZ, multi-host, and complete implementation review | +| Noise KEM | X-Wing is the leading construction to evaluate | component candidate only | +| Noise profile | exact PQ entry and mutual-authentication profiles | hold, no FOG profile selected | +| End-to-end handshake and ratchet | PQXDH revision 3 plus Triple Ratchet revision 4 plus ML-KEM Braid revision 1 | retained and advanced to integration and geometry review | +| Storage and Composer-local crypto | owned by their candidate specifications | not selected by this document | + +Advancing a candidate means that benchmark and integration work may target it. +It does not mean that a daemon, consensus, bundle, or public claim may use it. + +## 7. PKI Hash and Signature Candidate + +### 7.1 Candidate records + +```text +hash_candidate_name = FOG-PKI-HASH-CANDIDATE-SHA3-256-1 +hash_suite_id = UNASSIGNED +hash_output_length = 32 +hash_status = non-active + +signature_candidate_name = FOG-PKI-CANDIDATE-MLDSA65-ED25519-1 +signature_suite_id = UNASSIGNED +signature_status = non-active +component_order = ML-DSA-65, Ed25519 +verification_rule = ALL_COMPONENTS_REQUIRED +``` + +SHA3-256 preserves the existing 32-byte identifier widths and avoids a +length-extension interface. Its selection is still candidate-level because +FOG must publish byte-exact vectors for every PKI domain and measure its +implementation on every authority and consumer class. + +ML-DSA-65 plus Ed25519 is advanced because: + +- both components have stable standardized definitions; +- the parameter pair has a current standards precedent in RFC 9980; +- ML-DSA-65 and ML-KEM-768 target the same NIST category without selecting the + larger category-5 signature for every consensus object; +- Ed25519 is compact and widely implemented; +- requiring both components avoids a success path that silently becomes only + classical or only post-quantum. + +RFC 9980 is evidence for the parameter pairing, not the FOG encoding. FOG +does not copy OpenPGP packets, prehash rules, algorithm identifiers, or key +material formats. + +### 7.2 Key representation + +One FOG composite public-key record contains two independently generated +public keys in the fixed order ML-DSA-65, then Ed25519. One signature value +contains two exact-length signatures in that same order. + +The eventual PKI profile MUST define a fixed-length array rather than a raw +concatenated byte string. It MUST reject missing, duplicated, reordered, +trailing, unknown, or incorrectly sized components before verification. + +Key identifiers cover the complete candidate suite ID and complete composite +public-key encoding. A component key ID is not a substitute for the composite +key ID. Components from different records, subjects, authorities, purposes, +or validity intervals cannot be assembled into one valid key. + +### 7.3 Verification rule + +Both component signatures MUST validate over the identical exact FOG +signature input using the public keys in the one already trusted composite +key record. There is no threshold inside a signature and no partial success. + +Verification evaluates both components using an implementation strategy whose +remote timing does not disclose which component failed. The final result is +one success or one coarse authentication failure. Parser and key-record errors +are checked before signature work but do not produce component-specific remote +responses. + +### 7.4 Suite binding and separability + +The signature suite ID MUST be inside the signed input. The FOG-PKI signature +input is therefore: + +```text +[ + "FOG-PKI-SIGNATURE-1", + network_id, + object_type, + signature_suite_id, + signed_object_bytes +] +``` + +This corrects the earlier structural draft, in which `signature_suite_id` +appeared only in the outer `SignatureRecord`. Without this binding, one valid +component could be extracted and presented to a profile that accepted that +component alone over the same bytes. + +Binding the suite ID supplies the weak non-separability property described by +RFC 9955 when combined with exact key purpose, all-component verification, and +no fallback. It does not establish strong non-separability. Before activation, +FOG MUST publish an artifact analysis covering at least: + +- component stripping and rewrapping; +- cross-suite and cross-protocol reuse; +- key substitution and component recombination; +- duplicate or reordered components; +- mixed old and new profile records during transition; +- verification differences across implementations; +- exposure of a component signature outside FOG. + +FOG MUST NOT activate a classical-only signature suite that accepts an +extracted component under a compatible transcript during the candidate's +validity or drain interval. + +### 7.5 Signing randomness + +Production ML-DSA-65 signing uses the hedged variant with a fresh 32-byte +random value from the approved operating-system randomness source for every +signature operation. Deterministic signing is reserved for fixed conformance +vectors and explicit failure testing, not normal authority operation. + +Randomness failure stops signing. It does not select deterministic mode. +Ed25519 and ML-DSA component keys are independently generated and stored. + +### 7.6 Implementation candidates + +For a Go implementation, the standard `crypto/ed25519` package is the leading +Ed25519 component. Cloudflare CIRCL version 1.6.5 is a candidate source for +ML-DSA-65 and X-Wing evaluation because it is versioned, has known-answer +tests, and documents package-level review expectations. + +CIRCL's own project description still treats deployment conservatively and +does not make every package or integration constant-time by declaration. +Activation therefore pins the exact module version and package paths, audits +attacker-controlled panic paths and secret-dependent behavior, reproduces +FIPS vectors, and records the license and dependency graph. + +### 7.7 Alternatives not advanced + +- ML-DSA-44 is smaller but targets a lower category than the leading FOG + candidate. +- ML-DSA-87 increases every signature and public key without a demonstrated + FOG need for category 5 in the first profile. +- SLH-DSA provides valuable design diversity but a 7,856-byte 128s signature + is costly for frequently signed PKI objects and update bundles. It remains a + future root, release, or diversity study, not the first ordinary suite. +- NIST's additional-signature candidates and HQC are still undergoing + standardization work. They are tracked, not placed into an active profile. +- A classical-only signature is useful for isolated development tests only if + it has a separately named profile and no automatic relationship to the + claim-bearing network. + +## 8. Hybrid KEM Requirements + +FOG treats a hybrid KEM as a complete construction, not as two KEM names and a +concatenation operator. Its immutable definition includes: + +- component algorithms and parameter sets; +- component key and ciphertext encodings; +- generation independence; +- component order; +- combiner function; +- exact combiner input encoding and domain; +- public context bound by the combiner; +- malformed-key and malformed-ciphertext behavior; +- implicit-rejection and failure semantics; +- shared-secret length; +- key-confirmation responsibility; +- test vectors and implementation revision. + +NIST SP 800-227 requires the complete composite-KEM construction to receive +analysis. It also recommends explicit, unambiguous inputs and key confirmation +where the protocol requires assurance that both parties derived the same key. +FOG follows that guidance at the owning protocol boundary. + +No FOG code may expose an API equivalent to: + +```text +CombineAnyKEMs(list_of_names, raw_concatenated_values) +``` + +Each reviewed construction instead has a compile-time adapter with exact +types, lengths, domains, and failure behavior. + +## 9. KEMSphinx Candidate + +### 9.1 Retained construction + +The existing packet candidate remains: + +```text +FOG-SPHINX-CANDIDATE-MLKEM768-X25519-1 +``` + +It uses the evaluated HPQC security-preserving split-PRF hybrid construction +with X25519 hashed-ElGamal first and ML-KEM-768 second. The display name does +not define component order. The exact registry record and test vectors do. + +The hybrid ciphertext is 1,120 bytes: + +```text +X25519 hashed-ElGamal ciphertext 32 +ML-KEM-768 ciphertext 1088 +total 1120 +``` + +The complete already calculated four-hop FOG packet remains 16,150 bytes, +with a 4,096-byte user payload and a 6,058-byte public SURB. This evaluation +does not change a byte of that geometry. + +### 9.2 Why X-Wing does not silently replace it + +X-Wing is a strong general hybrid-KEM candidate, and RFC 9980 contains a +QSF/X-Wing-compatible ML-KEM-768 plus X25519 construction for OpenPGP. That +does not prove interchangeability inside KEMSphinx. + +KEMSphinx needs a hybrid KEM with the security properties required by its +packet proof and active-attacker model. The maintained Katzenpost KEMSphinx +specification explicitly warns that a hybrid construction designed for a +handshake protocol is not automatically suitable unless it provides the +required robust IND-CCA behavior. + +Replacing the split-PRF construction with X-Wing would create a newly named +packet candidate, new header bytes, new vectors, and a new proof and +implementation review. It cannot keep this candidate name or geometry record +by convenience. + +### 9.3 Evidence and implementation risks + +The HPQC repository supplies the exact split-PRF construction, X25519 adapter, +ML-KEM-768 implementation bindings, and KEMSphinx-oriented interfaces. It also +describes itself as experimental and states that it has not received an +external security review. No stable release line is assumed by FOG. + +The candidate therefore pins an exact source commit and transitive dependency +set. Its AGPL-3.0 licensing must be compatible with the future FOG repository +and distribution model before adoption. + +The rest of the evaluated Katzenpost packet suite, including KDF, header MAC, +header stream, AEZ-based payload SPRP, and payload-tag construction, remains +under review. AEZ's age and small implementation ecosystem make complete +vectors, misuse analysis, constant-time inspection, fuzzing, and an +independent review mandatory. Geometry compatibility is not primitive +approval. + +### 9.4 Benchmark admission + +The candidate is admitted to complete-packet benchmarking because its exact +ciphertext sizes and packet arithmetic are known. It remains non-active until +the gates in `FOG-SPHINX-PROFILES.md` and this document pass. + +## 10. Adjacent-Link Noise Evaluation + +### 10.1 Required FOG semantics + +FOG-WIRE needs at least two exact post-quantum link profiles: + +1. entry mode, where the blind relay authenticates the entry without exposing + a stable relay Noise identity; +2. mutual node mode, where both authorized adjacent roles authenticate each + other and the PKI-bound role and key context. + +Both profiles must preserve the existing fixed preface, authenticated +prologue, empty application payload during the handshake, fixed encrypted +records, standard Noise message bound, no 0-RTT, no resumption, and no runtime +negotiation. + +### 10.2 Evidence reviewed + +The PQNoise paper gives a reviewed method for replacing Noise DH operations +with KEM operations and analyzes the resulting protocol family. Katzenpost's +current wire specification gives concrete operational experience with +`Noise_pqXX_Xwing_ChaChaPoly_BLAKE2b`. + +That Katzenpost profile is not adopted directly because: + +- its `pqXX` authentication sequence is not the exact FOG entry or mutual + pattern already specified; +- FOG entry mode must avoid a stable initiator identity; +- FOG mutual mode is bound to exact PKI roles and adjacency; +- Katzenpost's nonstandard large Noise-message allowance is unnecessary for + FOG's empty-handshake-payload rule; +- FOG has its own preface, prologue, record, command, epoch, and transition + contract. + +### 10.3 Result + +X-Wing is the leading KEM construction to evaluate for FOG-WIRE because it +combines ML-KEM-768 and X25519 with a fixed analyzed combiner and has both a +current CFRG draft and maintained implementations. It is not yet a selected +FOG-WIRE profile. + +No exact hybrid post-quantum Noise profile is advanced in this evaluation. +FOG will not create `pqNK` or `pqKK` pattern names without a reviewed +specification, transcript definition, state-machine analysis, vectors, and a +maintained library that supports the required semantics. + +Classical Noise profiles may be used in an isolated functional PoC only under +separate explicit names and claims. They are not fallback profiles and cannot +produce a post-quantum or public-alpha security claim. + +### 10.4 Noise activation requirements + +Before selecting a numeric wire profile, FOG MUST have: + +- an exact reviewed entry handshake with responder authentication and no + stable initiator identity; +- an exact reviewed mutual handshake; +- exact protocol names, token sequences, transcript hashes, KEM operations, + combiner inputs, cipher, hash, prologue processing, and message limits; +- deterministic positive and negative vectors for both roles; +- identity-misbinding, unknown-key-share, downgrade, replay, reflection, + malformed-ciphertext, and component-failure analysis; +- key confirmation and channel-binding analysis; +- a maintained implementation or a separately reviewed implementation plan; +- byte, CPU, memory, handshake-flood, and side-channel benchmarks; +- independent review of the exact FOG integration. + +Until then, `FOG-WIRE.md` remains structurally complete but cryptographically +non-active. + +## 11. End-to-End Messaging Candidate + +### 11.1 Retained construction + +The leading messaging integration remains: + +```text +FOG-MSG-CANDIDATE-PQXDH-TR-MLKEM768-1 +``` + +It pins: + +- PQXDH revision 3 for asynchronous session initiation; +- Double Ratchet revision 4 Triple Ratchet; +- ML-KEM Braid revision 1 using ML-KEM-768; +- one-time classical and signed one-time ML-KEM prekeys; +- no reusable last-resort PQ prekey in a claim-bearing profile; +- the fixed FOG envelope, voucher, storage, retry, and transaction contracts. + +This is the strongest maintained end-to-end candidate found that matches +FOG's asynchronous, intermittently transferred Composer state without +inventing a ratchet. + +### 11.2 Claim boundaries + +The candidate does not by itself establish post-quantum authentication. +PQXDH revision 3 retains classical authentication assumptions. An outer FOG +PKI or pairwise-root signature does not silently rewrite PQXDH's proof or +turn its authentication into a post-quantum property. + +Triple Ratchet combines a classical Double Ratchet and the Sparse +Post-Quantum Ratchet. Post-quantum post-compromise recovery depends on fresh +ratchet progress. Dropped, delayed, reordered, or never-returning traffic can +delay or prevent the expected recovery boundary. + +FOG also withholds deniability, safe backup, multi-device convergence, group +security, and complete geometry claims until the exact integration is tested. + +### 11.3 Implementation evidence and risk + +Signal publishes the PQXDH, Double Ratchet, and ML-KEM Braid specifications. +The Sparse Post-Quantum Ratchet repository includes Rust code and formal +artifacts, including hax/F* and ProVerif work. This is useful evidence, not a +release or support promise for FOG. + +The broader `libsignal` repository is production software for Signal's own +clients, but its public documentation warns that external use is unsupported +and APIs may change. Its AGPL licensing, Rust integration boundary, release +pinning, unsupported external API status, and transitive dependency surface +must be resolved before selection. + +FOG will choose one of two explicit paths after a spike and license review: + +1. pin a reviewed Rust implementation behind a minimal memory-safe interface + with ownership, zeroization, panic, and serialization tests; or +2. implement the exact published construction using reviewed primitives and + reproduce upstream plus FOG integration vectors. + +A partial port, altered KDF, altered transcript, changed ratchet combination, +or locally simplified loss behavior is a new candidate, not this one. + +### 11.4 Integration work admitted + +The candidate advances to byte-exact envelope and packet-geometry work. The +next benchmark must include PQXDH initiation, ongoing Triple Ratchet headers, +ML-KEM Braid state and ciphertexts, skipped-key bounds, storage framing, and +fragmentation against the exact 4,096-byte KEMSphinx user payload. + +## 12. Storage and Composer Boundary + +This evaluation does not select the `FOG-STORAGE` or `FOG-COMPOSER` local +cryptographic profiles. Their candidates have different properties: + +- capability derivation and authenticated storage requests; +- object-level vault AEAD and key wrapping; +- passphrase KDF and platform memory limits; +- backup and recovery encryption; +- update and release authentication. + +Those profiles may reuse a standardized primitive only through independent +suite records and purpose-separated keys. They do not inherit the PKI, +KEMSphinx, Noise, or messaging suite identifier. + +## 13. Implementation Architecture + +The future source tree SHOULD isolate construction-specific adapters by +security role, for example: + +```text +internal/crypto/pki/ +internal/crypto/kemsphinx/ +internal/crypto/wire/ +internal/crypto/messaging/ +internal/crypto/testvectors/ +``` + +The shared layer may contain only inert metadata types, constant-time utility +wrappers whose behavior is independently reviewed, randomness interfaces, and +test-vector loading. It does not contain a generic negotiate-and-dispatch +registry or accept algorithm names from the network. + +Each executable imports only the operations required by its role. In +particular: + +- a mix does not import PKI signing or messaging secret operations; +- an authority does not import KEMSphinx decapsulation for mix processing; +- a blind relay does not import Composer message decryption; +- a Composer does not import online authority signing; +- a bridge does not receive core private-key handles. + +Secret-bearing types should be non-copyable where the implementation language +permits it. Serialization APIs are private to the owning persistence or +descriptor boundary. Ordinary application APIs do not return raw private +keys. + +## 14. Dependency and Supply-Chain Record + +Every candidate benchmark and later activation records: + +- upstream repository and canonical source location; +- exact tag and commit; +- standard edition and incorporated errata; +- module and transitive dependency lock; +- checksums and reproducible build procedure; +- implementation language and compiler version; +- license and redistribution analysis; +- known audit, review, issue, and vulnerability status; +- known-answer and cross-implementation vector results; +- target operating systems, architectures, and CPU feature paths; +- constant-time and attacker-controlled panic review; +- generated SBOM and release provenance. + +An untagged dependency may be benchmarked by commit. It cannot be activated +without an explicit maintenance and update policy. A repository being active +does not replace a cryptographic or side-channel review. + +## 15. Randomness, Secret Memory, and Failure + +### 15.1 Randomness + +All production key generation, ML-KEM encapsulation, ML-DSA hedged signing, +ephemeral handshake operations, and packet creation use the approved +operating-system randomness source through one narrow injectable interface. +Deterministic entropy is available only in test builds or explicit vector +tools. + +Short reads, unavailable randomness, health-test failure, fork duplication, +or impossible state stop the operation. No protocol silently repeats a seed, +switches to time-based randomness, or changes to deterministic mode. + +### 15.2 Secret lifetime + +The owning specifications define durable lifetime. At the implementation +boundary: + +- ephemeral KEM and DH private material is single-use where the construction + requires it; +- retired shared secrets and message keys are released promptly; +- error, metrics, tracing, panic, and crash paths never format secret bytes; +- core dumps and swap are addressed by the deployment profile; +- zeroization claims are limited to memory actually controlled by the + implementation and compiler; +- immutable language copies and allocator remnants remain documented limits. + +### 15.3 Remote behavior + +The implementation may keep coarse local counters such as malformed length, +authentication failure, resource limit, or internal failure. It never logs a +key, ciphertext content, transcript, message identifier, capability, route, +or component-specific decapsulation result. + +Externally, failures follow the owning protocol's uniform drop, close, or +fixed response. A second algorithm is never tried after failure. + +## 16. Benchmark Contract + +The benchmark phase measures complete protocol operations, not primitive +microbenchmarks alone. `FOG-CRYPTO-BENCHMARKS.md` records the first-host +implementation baseline. That partial completion does not relax the remaining +hardware, operation, review, or activation requirements below. + +### 16.1 Required hardware classes + +At minimum, publish results for: + +- the lowest supported x86-64 class without optional acceleration assumptions; +- a current x86-64 server class; +- the lowest supported ARM64 Composer or node class; +- the intended offline Composer hardware class. + +Every result names the CPU, microcode, OS, compiler, power mode, dependency +commit, feature flags, iteration count, warmup, and raw result artifact. + +### 16.2 Required measurements + +For every applicable role, measure: + +- key generation, encapsulation, decapsulation, signing, and verification; +- complete four-hop packet create and each hop unwrap; +- complete SURB creation, reply creation, and final reply decryption; +- entry and mutual Noise handshake candidates when available; +- PQXDH initiation and steady-state Triple Ratchet send and receive; +- allocation count, peak live memory, stack use, binary-size contribution, + and persistent key size; +- success, malformed, and cryptographic-failure paths; +- concurrent throughput and tail latency under bounded adversarial load; +- descriptor, consensus, update-bundle, envelope, record, SURB, and packet + byte costs; +- queue, cover-traffic, storage, and bandwidth consequences of the exact + complete geometry. + +Primitive results are retained for diagnosis, but profile selection uses the +complete-operation figures. + +### 16.3 Side-channel checks + +The benchmark harness also runs or records: + +- secret-dependent branch and memory-access review for exact package paths; +- dudect-style timing tests where applicable; +- malformed-input timing distributions; +- CPU-feature and fallback-path equivalence; +- race, sanitizer, fuzz, and attacker-controlled panic results; +- cross-process isolation assumptions for co-located PoC roles. + +Passing statistical tests is evidence, not proof of constant-time behavior. + +### 16.4 First-host baseline + +The pinned Go harness in `../benchmarks/crypto/` completed the first older +x86-64 baseline for SHA3-256, composite PKI operations, candidate KEMs, and the +exact four-hop 16,150-byte KEMSphinx request/reply path. + +The full request/reply cryptographic operation measured about 8.89 ms at the +median, with about 638 KiB and 1,452 allocations per operation. Direct use of +the parameterized maintained `Unwrap` API did not enforce FOG's exact external +packet length, so the harness adds a typed FOG boundary that rejects all +non-exact paths, packets, payloads, SURBs, encrypted replies, and reply-key +blocks before cryptographic processing. + +The result retains the evaluated candidates without activating them. Raw +three-sample data, environment details, exact sizes, exclusions, and observed +timing variability are in +`../benchmarks/crypto/results/2026-08-08-x86-64-i5-6300u.md`. + +## 17. Activation and Retirement + +A candidate can receive a numeric ID only after: + +1. its complete immutable record and encoding are published; +2. the owning protocol's geometry and state machine are byte-exact; +3. at least two independently integrated implementations reproduce positive + and negative vectors where the protocol gate requires them; +4. dependencies, licenses, builds, randomness, failures, side channels, key + lifecycle, and resource limits are reviewed; +5. complete-operation benchmarks fit the supported hardware and cover model; +6. transition, rollback, revocation, compromise, and retirement behavior is + tested; +7. protocol and implementation review findings are resolved or explicitly + accepted with bounded claims; +8. a decision record names the profile and its permitted deployment stage. + +Activation is monotonic. A newly discovered vulnerability can stop creation +or acceptance, but cannot trigger an unauthenticated downgrade. Emergency +retirement may cause message, packet, or availability loss. + +## 18. Claims Deliberately Withheld + +This evaluation does not support the following statements: + +- FOG is post-quantum secure. +- A hybrid is secure whenever either component remains secure. +- ML-KEM inclusion makes authentication post-quantum. +- ML-DSA plus Ed25519 is strongly non-separable. +- KEMSphinx geometry proves packet security or anonymity. +- PQNoise research already supplies FOG's exact Noise profiles. +- Signal's specifications validate FOG framing, persistence, loss, backup, or + offline transfer behavior. +- a memory-safe language eliminates side channels, secret copies, panics, or + protocol errors. +- NIST standardization or a maintained repository replaces independent + integration review. + +Public wording must name the exact active profile and evidence, or state that +the construction is a non-active research candidate. + +## 19. Open Work After This Evaluation + +The following items remain before any cryptographic profile can become active: + +- publish the exact FOG PKI composite-key and signature-component encoding; +- produce SHA3-256 domain vectors and the full PKI signature artifact analysis; +- decide the implementation and license path for ML-DSA-65; +- audit the pinned HPQC, Katzenpost, and AEZ dependency set; +- repeat complete 16,150-byte KEMSphinx packet, SURB, and persistent replay + benchmarks on current server, ARM64, and offline Composer hardware; +- select or produce a reviewed exact FOG entry and mutual PQNoise profile; +- complete the PQXDH, Triple Ratchet, ML-KEM Braid, FOG envelope, and storage + serialization and state integration; +- measure all candidates against complete packet, wire, bundle, and storage + geometry; +- publish deterministic and negative vectors and independent review results; +- revisit standards, drafts, errata, and implementation status at activation. + +## 20. Primary References + +- NIST FIPS 203, ML-KEM: + <https://csrc.nist.gov/pubs/fips/203/final> +- NIST FIPS 204, ML-DSA: + <https://csrc.nist.gov/pubs/fips/204/final> +- NIST FIPS 205, SLH-DSA: + <https://csrc.nist.gov/pubs/fips/205/final> +- NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms: + <https://csrc.nist.gov/pubs/sp/800/227/final> +- RFC 9794, Terminology for Post-Quantum Traditional Hybrid Schemes: + <https://www.rfc-editor.org/rfc/rfc9794.html> +- RFC 9955, Hybrid Signature Spectrums: + <https://www.rfc-editor.org/rfc/rfc9955.html> +- RFC 9980, Post-Quantum Cryptography in OpenPGP: + <https://www.rfc-editor.org/rfc/rfc9980.html> +- CFRG X-Wing KEM Internet-Draft: + <https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/> +- PQNoise: + <https://eprint.iacr.org/2022/539> +- Katzenpost wire protocol: + <https://katzenpost.network/docs/specs/wireprotocol/> +- Katzenpost KEMSphinx specification: + <https://katzenpost.network/docs/specs/kemsphinx/> +- Katzenpost HPQC implementation: + <https://github.com/katzenpost/hpqc> +- Katzenpost AEZ implementation: + <https://github.com/Yawning/aez> +- Signal PQXDH revision 3: + <https://signal.org/docs/specifications/pqxdh/> +- Signal Double Ratchet revision 4: + <https://signal.org/docs/specifications/doubleratchet/> +- Signal ML-KEM Braid revision 1: + <https://signal.org/docs/specifications/mlkembraid/> +- Signal Sparse Post-Quantum Ratchet implementation: + <https://github.com/signalapp/sparsepostquantumratchet> +- Signal libsignal implementation: + <https://github.com/signalapp/libsignal> +- Cloudflare CIRCL: + <https://github.com/cloudflare/circl> +- Go ML-KEM package: + <https://pkg.go.dev/crypto/mlkem> +- FOG threat model: `FOG-THREAT-MODEL.md` +- FOG architecture: `FOG-ARCHITECTURE.md` +- FOG PKI: `FOG-PKI.md` +- FOG wire protocol: `FOG-WIRE.md` +- FOG KEMSphinx profiles: `FOG-SPHINX-PROFILES.md` +- FOG messaging: `FOG-MESSAGING.md` +- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md` + +These sources support the shortlist and its constraints. The exact FOG +composition still requires its own vectors, tests, benchmarks, operational +analysis, and independent review. |