H33 Security Parameters Appendix

Serial Dependencies (cannot parallelize):
  BFV Encrypt → FHE Distance → PLOOKUP Prove → Dilithium Sign
       ↓              ↓              ↓              ↓
   128.5µs        48.1µs         23.8µs        123.1µs
                                                   = 323.5µs minimum

Why Auth+Cache ×64 only gets 1.3× speedup:
  • Single auth is already fast (~330µs)
  • Serial pipeline — no intra-request parallelism
  • Rayon spawn overhead (~100µs) eats gains on sub-ms tasks
  • Cache SET is serial per connection

Where parallelism wins:
  • Request-level: 192 independent auths running concurrently
  • Batch encrypt: 15.4× speedup at batch-64 (17.1K/sec)
  • Biometric 512-D: 6.0× speedup (46K/sec)

Circle STARK (34/34 tests passing) exists in the codebase as infrastructure for future use cases requiring general-purpose verifiable computation. It is NOT in the production authentication pipeline. The benchmarks in previous appendix versions (3.5ms prove, 21µs verify, 14KB proof) were accurate for that system but irrelevant to production auth performance.

Enroll: embedding → normalize → quantize → BFV encrypt → store ciphertext; secret key → Shamir split → distribute k-of-n shares
Verify: embedding → BFV encrypt → homomorphic inner product (encrypted space) → k partial decrypts → Lagrange combine → threshold compare → SHA3 transcript attestation

Cachee stats: 100% hit rate (5.28M hits, 2 misses) · L1 16.4µs · 14× vs direct ElastiCache · 192 connections

Expected Latency by Network Topology

What the "63ns / 52.2M/sec" Benchmark Actually Times

H33 achieves 780µs end-to-end post-quantum authentication
(FHE encrypt + PLOOKUP prove + Dilithium sign/verify),
scaling to 528K full cryptographic auths/sec on 192-vCPU
infrastructure. Pre-authenticated session validation via
Cachee delivers 418K verifications/sec with sub-26µs latency.

Key Findings

• src/fhe/arena.rs has 22 unsafe items — complex but sound (atomic flags + UnsafeCell)
• All 22 transmutes are NEON uint64x2_t ↔ [u64; 2] — layout-guaranteed on aarch64
• src/biometric_auth/ confirmed zero unsafe blocks
• No critical issues found

Root cause: DetachedSignature::from_bytes() performs non-constant-time validation before cryptographic verification. When a signature byte is flipped, the early rejection path is measurably faster than the full verification path.

Our code is clean — the leak is in the upstream mldsa65 crate, not in src/pqc/dilithium.rs.

Mitigations

1. cargo update pqcrypto-mldsa to check for a patched version
2. Report upstream with the t=34.6 DudeCT methodology
3. Long-term: evaluate liboqs-rust or constant-time ML-DSA alternatives
4. Our PLOOKUP verify is constant-time (t=2.05, below threshold) — the fix works

• Production auth pipeline breakdown (780µs full crypto)
• PLOOKUP vs Circle STARK clarification
• 52.2M/sec claim investigation — NOT real crypto
• BFV/CKKS batch scaling
• Biometric 512-D parallel
• Cache pipeline throughput
• Pipeline serial dependency analysis
• ElastiCache latency (direct, same-AZ, cross-AZ projections)
• Dudect constant-time verification (3/4 PASS, 1 upstream leak)
• PLOOKUP verifier fuzzing (7 proptest tests)
• PLOOKUP timing vulnerability fix (constant_time_eq)
• Memory safety audit (163 unsafe blocks reviewed)
• Precision mode n=8192 benchmark (1,974µs auth, 507/sec)
• CVE fix: bytes 1.11.0 → 1.11.1

1. Verify FHE Parameters

cargo test test_standard_params_security -- --nocapture
# Expected: n=4096, q=109 bits, δ=1.004551

2. Run Full Test Suite

cargo test --workspace -- --nocapture
# 1,479+ tests passing

3. Verify PLOOKUP (Production ZK)

cargo bench --bench plookup_bench
# Prove: ~23.8µs, Verify: ~715ns, Proof: 97 bytes

4. Verify Circle STARK (Infrastructure)

cargo test --lib -- stark --nocapture
# STARK tests passing (NOTE: not used in production auth)