1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
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.
|
