perf: yip-wire SipHash header-auth is ~9% of receiver CPU under load — investigate/optimize

[vxfemboy]

The post-4a perf re-profile (bulk traffic, 1-core AMD EPYC target box) surfaced the yip-wire coverage-auth SipHash (Sip24) as ~9% of receiver CPU — a surprising userspace hotspot, second only to the kernel TUN-write path (~20%) and well above AEAD decrypt (~4.4%) and RS FEC decode (~1.6%).

See crates/yip-bench/RESULTS.md (the 4b re-profile section) for the profile.

Investigate

• Is the SipHash recomputed redundantly (e.g. over more bytes than necessary, or more than once per packet)?
• Can the hashed region be reduced (auth only the header, not the full covered payload, if the AEAD tag already covers the payload)?
• Is Sip24 (24 rounds) needed, or would SipHash-1-3 / a keyed-BLAKE2s-short / an AES-NI-based one-block MAC be materially cheaper at equal security for a per-packet keyed header tag?
• Measure the candidate on the target box before committing (spike-first, like the throughput levers).

Constraints

• The header-auth is load-bearing for the anti-DPI wire design (keyed header protection, no fixed bytes). Any change must preserve the security property and the "no fixed signature" goal.

[vxfemboy]

Investigation (2026-07-12): traced the pipeline — SipHash-2-4 auth_tag runs over the full ~1400-byte FEC symbol per packet (~9% receiver CPU). It is NOT redundant with the AEAD: order is encrypt → FEC-encode ciphertext → per-symbol SipHash; on receive deframe(verify SipHash) → FEC-decode → AEAD-decrypt. The SipHash authenticates each FEC symbol before the decoder, keeping forged/corrupted symbols out of reassembly (load-bearing for loss recovery) + cheap-reject + anti-DPI. So we can't shrink it to the header — a faster MAC over the same bytes is the only lever. Options: SipHash-1-3 (~2×, minor margin cut), keyed BLAKE3 (SIMD, constant-time, no AES-NI). AES-NI MAC rejected on principle (reintroduces the AES-NI dependency + software-AES timing side channel that yip chose ChaCha20 to avoid). Parked as low-yield on current hardware: ~4.5% best-case CPU saving that does NOT move end-to-end throughput on the RTT/window-capped target boxes (same lesson as 4b), for a wire-format change to security-critical code. Revisit if/when a box is genuinely MAC-bound.