path: root/docs/FOG-CRYPTO-SUITES.md

# 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.