FHE-IQ: The First Two-Phase
Policy Router for FHE

The Problem No One Else Has

Most FHE libraries ship a single implementation. Microsoft SEAL gives you BFV and CKKS but you choose manually. Zama gives you TFHE. OpenFHE gives you everything but you're responsible for configuration. None of them route for you — because none of them need to.

H33 has three distinct FHE implementations because they serve fundamentally different workloads. These aren't parameter variations of the same library. They are different implementations at the polynomial arithmetic level — different coefficient widths, different NTT strategies, different SIMD instruction sets. And their ciphertexts are mutually incompatible: you cannot add a BFV-64 ciphertext to a CKKS ciphertext. The backend decision is permanent for the lifetime of a session.

Three FHE Engines

Two-Phase Architecture: A New Routing Paradigm

FHE-IQ's router is a pure function with zero I/O that makes its decision in under 500 nanoseconds. It operates in two mathematically distinct phases:

Routing Flow

Four Scoring Dimensions

Latency Fit (40%)

Compares each backend's observed p99 latency (rolling 256-sample window) against the caller's latency budget. A backend delivering 1,200µs when you budgeted 5,000µs scores higher than one delivering 4,800µs — more headroom for downstream ZK proofs and Dilithium attestation.

Security Margin (25%)

Maps every configuration to estimated security bits via SecurityTier. Request 128-bit (NIST Level 1) and a backend offering 128 bits scores 1.0. Excess security above the requirement is valued but discounted. Prevents the router from always selecting maximum-security parameters.

Hardware Affinity (20%)

FHE-IQ detects the platform at startup and applies a hardware affinity matrix based on actual ISA capabilities. This is where the routing gets novel:

Health Signal (15%)

Three native Rust AI agents — Harvest Detection (0.69µs), Side-Channel Detection (1.14µs), and Crypto Health (0.52µs) — continuously monitor each backend. The health score:

// AI-adaptive health scoring
let health = (1.0 - error_rate * 10.0).clamp(0.0, 1.0);

// 0% errors → 1.0 | 5% errors → 0.5 | 10%+ errors → 0.0
// At 10%+ the router routes AROUND the backend entirely

// Weights themselves are adaptive:
pub struct AdaptiveWeights {
    latency_fit:      f64,  // default 0.40
    security_margin:  f64,  // default 0.25
    hardware_affinity: f64, // default 0.20
    health_signal:    f64,  // default 0.15
}
// AI agents can shift health_signal to 0.40 during attack scenarios

Session Stickiness & Opaque Handles

Once FHE-IQ selects a backend, that decision is locked for the session lifetime. Every subsequent operation routes to the same backend. This is a correctness requirement: FHE ciphertexts are parameterized by (N, Q, t) and polynomial rings must match for any homomorphic operation to be mathematically defined.

The API: From 14 Lines to 4

// Before FHE-IQ: manual everything (14 lines)
let tier = ProductTier::H33;
let config = tier.resolve();
let ctx = BfvContext::new(config.poly_degree, &config.coeff_moduli, config.plain_modulus);
let keygen = KeyGenerator::new(&ctx);
let (pk, sk) = (keygen.public_key(), keygen.secret_key());
let encoder = BatchEncoder::new(&ctx);
let encryptor = Encryptor::new(&ctx, &pk);
let decryptor = Decryptor::new(&ctx, &sk);
let evaluator = Evaluator::new(&ctx);
let pt = encoder.encode(&values)?;
let ct = encryptor.encrypt(&pt)?;
// And you still need to know which scheme to pick

// After FHE-IQ: describe what you need (4 lines)
let fabric = FabricSessionStore::new(Default::default());
let session = fabric.create_session(RoutingRequest {
    data_type: DataType::Integer,
    product_tier: ProductTier::H33,
    security_tier: SecurityTier::Q128,
    ..Default::default()
}, "user-42")?;
let ct = fabric.encrypt(&session.session_id, &[42, 100, 7, 255])?;

REST Endpoints

FHE-IQ exposes routing intelligence through REST under /api/v1/fhe/fabric/*. Coexists with existing endpoints — zero breaking changes.

Where FHE-IQ Fits in the Pipeline

FHE-IQ is the compute layer in H33's fully post-quantum authentication pipeline. A single API call flows through three cryptographic stages:

Why This Architecture Is New

• Two-phase routing with mathematical disqualification — no existing FHE library has a router that first eliminates backends via formal type/capability constraints, then scores survivors with weighted optimization.
• Hardware affinity matrix based on ISA analysis — routing decisions that factor in whether vmull_u32 vs vmull_u64 exists in the target instruction set.
• AI-adaptive scoring weights — three sub-microsecond Rust agents feeding real-time error rates and latency signals into the router's AdaptiveWeights.
• Opaque CiphertextHandle pattern — server-side ciphertext storage with zeroize-on-drop, eliminating multi-MB wire payloads and client-side key management.
• Stateless /recommend endpoint — preview routing decisions before committing resources. No session created, no keys generated.

No prior art exists because the prerequisite — operating multiple independent, production-grade FHE backends with incompatible ciphertext formats — has never existed before H33.