# 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 | candidate only, no active FOG benchmark | | PKI signatures | ML-DSA-65 plus Ed25519, both mandatory over one FOG-bound input | candidate only, no active FOG benchmark | | KEMSphinx KEM | ML-KEM-768 plus X25519 split-PRF construction in the already calculated order | geometry candidate only, implementation and benchmark pending | | KEMSphinx remaining primitives | exact KDF, MAC, stream, SPRP, and payload-tag integration | no FOG implementation selected | | 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 currently has no active cryptographic implementation benchmark. No archived external experiment satisfies or relaxes the 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 Active evidence status No first-host or multi-host cryptographic benchmark is active. A historical external-library experiment is archived outside the FOG project and is not an implementation baseline, conformance result, dependency selection, or performance claim. Benchmark work restarts only after FOG selects a reviewed implementation boundary and records its exact dependency and license set. ## 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; - select and audit the complete implementation, dependency, and license set; - execute complete 16,150-byte KEMSphinx packet, SURB, and persistent replay benchmarks on x86-64, 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: - NIST FIPS 204, ML-DSA: - NIST FIPS 205, SLH-DSA: - NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms: - RFC 9794, Terminology for Post-Quantum Traditional Hybrid Schemes: - RFC 9955, Hybrid Signature Spectrums: - RFC 9980, Post-Quantum Cryptography in OpenPGP: - CFRG X-Wing KEM Internet-Draft: - PQNoise: - Katzenpost wire protocol: - Katzenpost KEMSphinx specification: - Katzenpost HPQC implementation: - Katzenpost AEZ implementation: - Signal PQXDH revision 3: - Signal Double Ratchet revision 4: - Signal ML-KEM Braid revision 1: - Signal Sparse Post-Quantum Ratchet implementation: - Signal libsignal implementation: - Cloudflare CIRCL: - Go ML-KEM package: - 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` These sources support the shortlist and its constraints. The exact FOG composition still requires its own vectors, tests, benchmarks, operational analysis, and independent review.