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