Archive external benchmark outside active FOG

4 files changed, 21 insertions, 218 deletions

diff --git a/docs/FOG-CRYPTO-BENCHMARKS.md b/docs/FOG-CRYPTO-BENCHMARKS.md
deleted file mode 100644
index 9f6ea21..0000000
--- a/docs/FOG-CRYPTO-BENCHMARKS.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# 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.
diff --git a/docs/FOG-CRYPTO-SUITES.md b/docs/FOG-CRYPTO-SUITES.md
index 48402c1..e9aee7f 100644
--- a/docs/FOG-CRYPTO-SUITES.md
+++ b/docs/FOG-CRYPTO-SUITES.md
@@ -155,10 +155,10 @@ collapse honestly to one marketing figure.
 
 | 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 |
+| 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 |
@@ -651,9 +651,9 @@ 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.
+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
 
@@ -701,23 +701,13 @@ The benchmark harness also runs or records:
 
 Passing statistical tests is evidence, not proof of constant-time behavior.
 
-### 16.4 First-host baseline
+### 16.4 Active evidence status
 
-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`.
+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
 
@@ -767,9 +757,9 @@ 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 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;
@@ -826,8 +816,6 @@ The following items remain before any cryptographic profile can become active:
 - 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.
diff --git a/docs/FOG-PKI.md b/docs/FOG-PKI.md
index 4bc0ebd..5394f06 100644
--- a/docs/FOG-PKI.md
+++ b/docs/FOG-PKI.md
@@ -1784,7 +1784,6 @@ vectors. Implementations MUST NOT invent local defaults.
 - FOG storage protocol: `FOG-STORAGE.md`
 - FOG Composer protocol: `FOG-COMPOSER.md`
 - FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
-- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
 - FOG local Podman PoC: `FOG-LOCAL-POC.md`
 - NIST FIPS 204, Module-Lattice-Based Digital Signature Standard:
   <https://csrc.nist.gov/pubs/fips/204/final>
diff --git a/docs/FOG-SPHINX-PROFILES.md b/docs/FOG-SPHINX-PROFILES.md
index f1d32de..2c4aac8 100644
--- a/docs/FOG-SPHINX-PROFILES.md
+++ b/docs/FOG-SPHINX-PROFILES.md
@@ -764,12 +764,11 @@ complete-packet benchmarking but does not activate it. The unresolved
 non-KEM primitives and implementation evidence keep the complete profile
 non-active.
 
-`FOG-CRYPTO-BENCHMARKS.md` records a first-host benchmark of this exact
-geometry. Future implementations MUST preserve its strict integration
-finding: the parameterized maintained API is wrapped by a FOG boundary that
-rejects every path, packet, payload, SURB, encrypted reply, or reply-key length
-that differs from this profile before cryptographic processing. The first-host
-result does not change `geometry-only` status or assign a profile ID.
+No active FOG implementation benchmark exists for this geometry. Every future
+implementation MUST enforce the exact path, packet, payload, SURB, encrypted
+reply, and reply-key lengths at the FOG boundary before cryptographic
+processing. This requirement follows from the profile contract itself, not
+from an archived external implementation experiment.
 
 ### 18.2 Candidate primitive inputs
 
@@ -1158,7 +1157,6 @@ These risks must appear in deployment documentation and public claims.
   <https://www.rfc-editor.org/rfc/rfc7748>
 - FOG Composer protocol: `FOG-COMPOSER.md`
 - FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
-- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
 - FOG traffic and topology simulation: `FOG-SIMULATION.md`
 
 ## 31. Completion Checklist