• Tor / Clearnet / FIPS Speed Comparison — Results
  • Goal
  • Results
  • Explanation

§Tor / Clearnet / FIPS Speed Comparison — Results

§Goal

Compare how long it takes to fetch the laantungir.net homepage over five
network paths to the same origin server, to feel the cost of DNS, the Tor
circuit, and the Tor exit node — and to see how the FIPS mesh transport
stacks up.

§Results

Medians, seconds, sorted fastest → slowest. % = median total relative to
the fastest path (fips = 100%). 5 distinct Tor circuits × 10 runs each for
the Tor paths; 10 runs for the others. No warm-up — the cold first fetch is
included. Run: 2026-08-06.

All paths returned the full 135,977-byte payload.

† fips-tor is the same FIPS npub host, but with the FIPS node’s transport
layer switched to Tor. The FIPS daemon (not curl) owns the Tor circuit, so
distinct circuits were sampled by reconnecting the daemon’s link
(fipsctl disconnect/connect) between rounds — 5 circuits × 3 runs. The
FIPS mesh stack (IPv6 → FSP Noise → FMP → Tor circuit) rides on top of the
Tor circuit, which is why it is slower than bare tor-onion despite both
traversing a single Tor circuit. Runner:
scripts/fips-tor-circuits-test.sh ·
raw data:
logs/fips-tor-circuits-20260806T163622Z.txt.

Runner: scripts/tor-speed-test.sh ·
Methodology: plans/tor-speed-comparison.md ·
Raw data: logs/tor-speed-test-20260806T155725Z.txt

§Explanation

FIPS is fastest, and it is fully encrypted. Its tls = 0.000 does not
mean plaintext — it means curl isn’t the one doing the encryption. FIPS
encrypts below the application, inside the daemon, using the Noise protocol
framework (hop-by-hop Noise IK on each link, end-to-end Noise XK between the
two endpoint npubs), settling on ChaCha20-Poly1305 symmetric keys after the
handshake. Crucially, that session is persistent and reused: the
handshake happens once, then every request rides the cached keys. So FIPS’s
0.610 s is almost pure RTT + server processing, with zero per-request crypto
setup.

FIPS over Tor is the slowest path — encryption isn’t free to route.
When the FIPS node’s transport is switched to Tor (fips-tor, 3.949 s), the
same persistent-session advantage no longer dominates, because the whole FIPS
mesh stack — IPv6 packet → FSP Noise-encrypted datagram → FMP link frame →
Tor circuit — rides on top of a Tor circuit instead of a direct link. The
result is ~2.7× slower than bare tor-onion even though both traverse a
single Tor circuit: FIPS adds its encapsulation and routing overhead to Tor’s
latency, and the daemon’s Tor link was itself measuring a high ~550–700 ms
SRTT during the test. The 5-circuit spread was tight (3.45–4.28 s), so this
is a consistent cost, not one bad circuit. The lesson: FIPS’s win comes from
a fast direct link plus session reuse; put it on Tor and it inherits — and
compounds — Tor’s latency.

HTTPS pays a TLS handshake on every request. direct-ip and clearnet
show tls ≈ 0.245–0.300 s because each curl opens a fresh TCP connection
and does a full TLS handshake (cert exchange + validation + key agreement)
before the HTTP request. The only difference between them is DNS
(0.053 s for clearnet, 0.000 for direct-ip) — small relative to TLS.

Tor adds a full circuit on top. tor-exit is the slowest model: it
builds a 3-hop Tor circuit, then does a second TLS handshake to the
clearnet origin through the exit node (tls = 0.627 s). tor-onion skips
the exit node and the clearnet TLS layer entirely (tls = 0.000) — the
onion’s end-to-end crypto shows up under ttfb instead.

The cold-start cost is real, and it’s why we stopped discarding the
warm-up. Every tor-onion circuit’s first run was its slowest
(4.0–4.8 s vs ~1.5–2.3 s steady-state) because the first request pays the
Tor stream-build + rendezvous cost. Including those cold starts pulled
tor-onion’s median up to roughly tie tor-exit (1.444 vs 1.450 s); in a
warm-only run tor-onion was clearly ahead. The honest takeaway: per
request, tor-onion avoids the exit-node TLS tax, but it pays a heavier
one-time circuit-build cost — so which is “faster” depends on whether you
amortize over many requests (onion wins) or measure a single cold fetch
(roughly a wash).

Bottom line: for repeated fetches to the same peer, a persistent
encrypted session over a direct link (FIPS) beats per-connection TLS (HTTPS),
which beats routing through a Tor exit node — and going straight to a
.onion avoids the exit-node tax at the price of a heavier first-connection
build. Layering FIPS on Tor (fips-tor) is the slowest option of all: you
pay FIPS’s mesh encapsulation on top of Tor’s circuit latency.