H33 Security Parameters Appendix

Serial Dependencies (cannot parallelize):
  BFV Encrypt → FHE Inner Product → Threshold Decrypt → ZKP STARK Lookup → Dilithium
       ↓              ↓              ↓              ↓           ↓
   0.42ms        0.26ms         0.33ms         ~2.2µs      ~106µs
                                                              = ~1.36ms

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)

The STARK verifier (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, 21us 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 2.09ns · 383,000× vs direct ElastiCache · 192 connections

Expected Latency by Network Topology

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

H33 achieves 1.36ms end-to-end post-quantum authentication
(FHE encrypt + H33 ZKP STARK Lookup prove + Dilithium sign/verify),
scaling to 1.1M full cryptographic auths/sec on 192-vCPU
infrastructure. Pre-authenticated session validation via
Cachee delivers 497M 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 H33 ZKP STARK Lookup verify is constant-time (t=2.05, below threshold) — the fix works

• Production auth pipeline breakdown (1.36ms full crypto)
• H33 ZKP STARK Lookup documentation 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)
• H33 ZKP STARK Lookup verifier fuzzing (7 proptest tests)
• H33 ZKP STARK Lookup 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=56 bits, δ=1.004551

2. Run Full Test Suite

cargo test --workspace -- --nocapture
# 1,751 tests passing

3. Verify H33 ZKP STARK Lookup (Production ZK)

cargo bench --bench stark_lookup_bench
# Prove: ~2.0µs, Verify: ~0.2µs (2.09ns Cachee cached)

4. Verify STARK Verifier (Infrastructure)

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