Archive external benchmark outside active FOG

1 files changed, 0 insertions, 182 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.