1 files changed, 182 insertions, 0 deletions
diff --git a/docs/FOG-CRYPTO-BENCHMARKS.md b/docs/FOG-CRYPTO-BENCHMARKS.md
new file mode 100644
index 0000000..9f6ea21
--- /dev/null
+++ b/docs/FOG-CRYPTO-BENCHMARKS.md
@@ -0,0 +1,182 @@
+# FOG Cryptographic Benchmark Baseline
+
+## 1. Status
+
+This document records the first reproducible implementation benchmark for the
+non-active candidates in `FOG-CRYPTO-SUITES.md`.
+
+It is an engineering baseline, not a profile selection or activation. It does
+not establish anonymity, post-quantum security, constant-time behavior,
+production capacity, or interoperability.
+
+The executable harness and complete three-sample data are in:
+
+- `../benchmarks/crypto/`
+- `../benchmarks/crypto/results/2026-08-08-x86-64-i5-6300u.md`
+
+## 2. Snapshot
+
+The first host is an Intel Core i5-6300U with two physical cores and four
+threads, running Linux amd64, Go 1.26.5, `GOAMD64=v1`, and the `powersave`
+governor. It is useful as an older low-power x86-64 baseline, but it is not a
+substitute for the required server, ARM64, and offline Composer classes.
+
+The Go module pins:
+
+- Katzenpost `v0.0.97`;
+- HPQC `v0.0.85-0.20260715190213-e598e7ee2843`;
+- the complete transitive graph in `go.mod` and `go.sum`.
+
+The harness is isolated from future daemons. It has no network listener,
+persistent state, runtime suite registry, packet autodetection, algorithm
+fallback, or profile activation path.
+
+## 3. Coverage
+
+The measured operations are:
+
+- SHA3-256 over 4 KiB, 128 KiB, 1 MiB, and 8 MiB objects;
+- ML-DSA-65 plus Ed25519 key generation, signing, valid verification, and
+  verification with either component invalid;
+- ML-KEM-768, X25519 hashed-ElGamal, the exact HPQC split-PRF KEM, and X-Wing
+  key generation, encapsulation, and decapsulation;
+- four-logical-CPU parallel decapsulation for the two hybrid candidates;
+- exact four-hop KEMSphinx forward construction, SURB construction, each hop
+  unwrap, all-hop unwrap, reply construction, and full request/reply crypto.
+
+The harness verifies both composite signature components over the same opaque
+input before combining their results. It performs no component fallback.
+
+## 4. First-Host Medians
+
+All sequential values below use one logical CPU and the median of three
+500 ms calibrated samples. The host was not frequency-locked or isolated, so
+the raw ranges remain authoritative.
+
+### 4.1 PKI
+
+| Operation | 4 KiB | 128 KiB | 1 MiB | 8 MiB |
+| --- | ---: | ---: | ---: | ---: |
+| SHA3-256 | 19.2 us | 0.567 ms | 4.71 ms | 37.7 ms |
+| composite sign | 1.16 ms | 2.33 ms | 11.0 ms | 78.5 ms |
+| composite verify | 0.254 ms | 1.15 ms | 12.0 ms | 57.9 ms |
+
+Composite key generation measured 0.460 ms. The benchmark framing uses a
+1,984-byte public key and 3,373-byte signature. These sizes do not define the
+pending canonical FOG PKI encoding.
+
+At 128 KiB, an invalid ML-DSA-65 component measured 1.13 ms while an invalid
+Ed25519 component measured 0.715 ms. Both components were evaluated, but the
+paths were not timing-uniform. Focused statistical and implementation review
+is required before accepting a remote failure surface.
+
+### 4.2 Hybrid KEMs
+
+| Construction | key generation | encapsulation | decapsulation |
+| --- | ---: | ---: | ---: |
+| HPQC ML-KEM-768 plus X25519 split-PRF | 0.348 ms | 0.515 ms | 0.460 ms |
+| X-Wing | 0.180 ms | 0.275 ms | 0.365 ms |
+
+Both constructions use a 1,216-byte public key and 1,120-byte ciphertext in
+this dependency snapshot. The split-PRF private serialization is 1,280 bytes;
+X-Wing is 1,248 bytes.
+
+X-Wing is faster in this local snapshot. That result supports continued
+FOG-WIRE evaluation only. It does not satisfy the distinct KEMSphinx combiner
+proof obligation and cannot silently replace the retained split-PRF candidate.
+
+### 4.3 Complete KEMSphinx Geometry
+
+| Operation | Median | B/op | allocs/op |
+| --- | ---: | ---: | ---: |
+| build forward packet | 2.43 ms | 177,492 | 391 |
+| create SURB | 2.33 ms | 123,668 | 348 |
+| unwrap one hop | 0.515 to 0.519 ms | about 32,560 | 80 to 81 |
+| unwrap all four hops | 2.04 ms | 130,192 | 323 |
+| build reply from existing SURB | 11.6 us | 28,368 | 14 |
+| full request/reply crypto | 8.89 ms | 653,450 | 1,452 |
+
+The complete operation covers two 16,150-byte packets, eight total unwraps,
+one 6,058-byte SURB, and one 320-byte private reply-key block. It excludes
+persistent replay insertion, wire I/O, queues, mixing delay, storage, and cover
+traffic.
+
+The timing is acceptable for continued simulation and implementation
+profiling on an old mobile CPU. The allocation volume is not yet acceptable as
+capacity evidence and must be included in bounded-load and denial-of-service
+work.
+
+## 5. Exact-Length Integration Finding
+
+The evaluated Katzenpost API is intentionally parameterized. Direct
+`Unwrap` use did not impose FOG's exact external packet length and accepted a
+packet shortened by one byte.
+
+FOG therefore needs an explicit protocol boundary before the cryptographic
+library. The benchmark module implements a narrow adapter that requires:
+
+- exactly four path hops;
+- exactly 10,156 forward or reply payload bytes;
+- exactly 16,150 packet bytes;
+- exactly 6,058 SURB bytes;
+- exactly 10,188 encrypted reply bytes, including the payload tag;
+- exactly 320 private reply-key bytes.
+
+Both shorter and longer inputs fail before cryptographic processing. The
+adapter does not add a primitive or alternate wire format. Equivalent strict
+checks are mandatory in any future FOG implementation and conformance corpus.
+
+## 6. Deliberate Exclusions
+
+No Noise benchmark is published because FOG has not selected exact reviewed
+entry and mutual post-quantum handshake patterns. A primitive X-Wing result is
+not a Noise handshake result.
+
+No PQXDH, Triple Ratchet, or ML-KEM Braid result is published because the
+complete FOG message integration and supported implementation path remain
+unselected. Rust was also absent on the first host.
+
+The first harness also does not supply:
+
+- peak live memory or stack-use evidence;
+- persistent replay-database cost;
+- p50, p95, or p99 latency under bounded adversarial load;
+- malformed-input timing distributions or dudect-style testing;
+- fuzzing, sanitizer, or cross-implementation vectors;
+- current server, ARM64, or offline Composer measurements;
+- queue, bandwidth, cover-traffic, or long-term disclosure results;
+- a complete vulnerability, license, AEZ, or side-channel review.
+
+Direct HPQC and Katzenpost dependencies are AGPL. Their use here is evaluation
+only and does not decide the future FOG distribution license.
+
+## 7. Selection Consequences
+
+This baseline makes the following limited decisions possible:
+
+1. Retain SHA3-256 and ML-DSA-65 plus Ed25519 for continued PKI encoding,
+   vector, separability, timing, and implementation work.
+2. Retain the exact HPQC ML-KEM-768 plus X25519 split-PRF construction for the
+   calculated KEMSphinx geometry.
+3. Retain X-Wing as the leading KEM to evaluate inside a future exact reviewed
+   FOG-WIRE Noise construction.
+4. Require an exact-length FOG boundary around the maintained KEMSphinx API.
+5. Move next to the privacy and capacity simulator while leaving every
+   cryptographic candidate non-active.
+
+No numeric suite or packet profile ID is assigned.
+
+## 8. Required Next Evidence
+
+Before activation, repeat and extend the matrix on:
+
+- a current x86-64 server;
+- a lowest-supported ARM64 node or Composer;
+- the intended offline Composer hardware;
+- a controlled host with fixed governor, CPU isolation, and recorded thermal
+  behavior.
+
+Then add exact Noise handshakes, complete messaging operations, persistent
+replay work, tail latency, memory profiles, fuzzing, deterministic positive and
+negative vectors, dependency and license review, side-channel review, and an
+independent implementation or integration.