FHE-IQ: Intelligent Encrypted Routing

Fully homomorphic encryption comes in three major flavors: BFV for exact integer arithmetic, CKKS for approximate floating-point arithmetic, and TFHE for boolean circuits and bit-level operations. Each scheme excels at different workloads and performs poorly when mismatched. Using CKKS for a biometric match that requires exact integer comparison introduces accuracy-destroying rounding errors. Using BFV for a neural network inference that requires floating-point operations wastes performance on unnecessary precision. Using TFHE for a bulk vectorized computation that BFV can batch throws away parallelism.

Choosing the right scheme requires deep expertise in FHE theory, noise management, parameter selection, and performance characteristics. Most developers do not have this expertise, and they should not need it. FHE-IQ is H33's solution: an intelligent routing engine that analyzes the workload and automatically selects the optimal scheme, parameters, and execution strategy.

The Three Schemes in Detail

BFV operates on exact integers in polynomial rings. Every addition and multiplication on ciphertexts produces the exact integer result when decrypted. BFV supports SIMD batching where thousands of integers are packed into one ciphertext and processed in parallel. Best for: biometric matching, database queries, financial calculations, counting operations, and any workload requiring exact results. H33's production biometric pipeline uses BFV exclusively.

CKKS operates on approximate complex numbers. It encodes floating-point values with a configurable precision level and performs arithmetic with controlled rounding. CKKS is faster than BFV for workloads that naturally involve floating-point numbers because it avoids the overhead of scaling and re-encoding. Best for: neural network inference, statistical analytics, signal processing, and any workload where small approximation errors are acceptable.

TFHE operates on individual bits or small integers, evaluating boolean gates (AND, OR, XOR, NOT) homomorphically. Each gate operation includes a bootstrapping step that refreshes the ciphertext, preventing noise accumulation. This makes TFHE ideal for deep circuits with many sequential operations. Best for: comparison operations, sorting, conditional logic, encrypted control flow, and any workload requiring bit-precise results with deep computation chains.

How FHE-IQ Decides

FHE-IQ analyzes the computation graph submitted through the H33 API. It examines several dimensions to determine the optimal scheme.

Data types: Integer inputs route to BFV. Floating-point inputs route to CKKS. Boolean or single-bit inputs route to TFHE. Mixed-type computations use scheme-switching or are decomposed into sub-computations each routed to the optimal scheme.

Precision requirements: Exact-result requirements mandate BFV or TFHE. Approximate-result tolerance enables CKKS which is typically faster for floating-point workloads.

Computation depth: Shallow computations (few sequential multiplications) work well in BFV and CKKS. Deep computations (many sequential operations) may benefit from TFHE's per-gate bootstrapping or require BFV modulus switching at specific points in the computation graph.

Parallelism: Workloads with many independent operations benefit from BFV and CKKS batching. Workloads with sequential dependencies benefit from TFHE's gate-by-gate evaluation.

Parameter Selection

Within each scheme, FHE-IQ selects optimal parameters. For BFV, this means choosing the polynomial degree N (security level), the ciphertext modulus chain (noise budget), and the plaintext modulus (value range). Larger N provides more security and more SIMD slots but slower operations. Longer modulus chains support deeper computations but larger ciphertexts. FHE-IQ balances these tradeoffs based on the specific computation being performed.

For H33's production biometric pipeline, FHE-IQ selects N=4096 with a single 56-bit modulus and t=65537. This configuration provides sufficient security (H33-128 level), enough noise budget for the inner-product computation, and 4096 SIMD slots for batching. The parameters were validated through extensive benchmarking and remain fixed for the biometric workload.

Compile-Time, Not Runtime

FHE-IQ makes its routing decision at compile time when the computation graph is first submitted. This means zero runtime overhead: the computation executes at full speed using the selected scheme and parameters. The routing decision is cached, so subsequent invocations of the same computation type reuse the previous selection without re-analysis.

This compile-time approach also enables optimization: FHE-IQ can reorder operations, fuse compatible gates, and schedule modulus switching at optimal points in the computation graph. These optimizations are computed once and applied to all subsequent executions.

Manual Override

Advanced users who understand FHE theory can bypass FHE-IQ and specify the scheme and parameters directly through the API. This is useful for specialized workloads where domain knowledge enables better parameter choices than automated analysis, or for research and benchmarking purposes where specific configurations need to be tested.

FHE-IQ provides intelligent defaults that work well for the vast majority of workloads. Manual override exists for the minority of cases where expert knowledge can improve on the automated selection. The goal is to make FHE accessible to every developer, not just cryptographers.

Real-World Routing Decisions

To understand FHE-IQ in practice, consider several concrete workloads and the routing decisions the engine makes for each.

Biometric face matching: The input is two 512-dimensional integer feature vectors. The computation is an inner product (element-wise multiply and sum). FHE-IQ routes to BFV because the inputs are integers, the computation is a shallow circuit (one multiplication depth), and exact results are required. Parameters: N=4096 (provides 4096 SIMD slots for batching), single 56-bit modulus (sufficient noise budget for one multiplication), t=65537 (covers the feature value range). This is H33's production biometric configuration.

Neural network inference: The input is a 224x224 floating-point image. The computation involves multiple layers of convolution, activation, and pooling. FHE-IQ routes to CKKS because the inputs are floating-point, the computation involves many sequential operations, and small approximation errors are acceptable in the prediction output. Parameters are selected based on the network depth: deeper networks require larger modulus chains (more noise budget) and higher polynomial degrees (more computation capacity).

Encrypted comparison: The input is two encrypted integers. The computation determines which is larger without revealing either value. FHE-IQ routes to TFHE because the comparison operation is naturally expressed as a boolean circuit (bit-by-bit comparison from most significant to least significant bit). TFHE's per-gate bootstrapping prevents noise accumulation through the sequential bit comparisons.

Encrypted SQL query: The query involves a WHERE clause (comparison), a SUM aggregate (addition), and a COUNT (addition). FHE-IQ decomposes this into sub-computations: the WHERE clause routes to TFHE for the comparison, and the aggregation routes to BFV for the exact integer arithmetic. The results are composed through a scheme-switching step that converts the TFHE comparison result into a BFV plaintext mask applied to the aggregation input.

Scheme Switching

Some computations naturally span multiple FHE schemes. A biometric enrollment might use BFV for template storage and matching, CKKS for quality score computation (which involves floating-point statistics), and TFHE for threshold comparison. FHE-IQ handles scheme switching transparently, converting ciphertexts between schemes at the optimal points in the computation graph.

Scheme switching has a cost: it typically requires a round trip to the client (which holds the decryption key) to decrypt in one scheme and re-encrypt in another. FHE-IQ minimizes the number of scheme switches by analyzing the full computation graph and grouping compatible operations together. In many cases, the computation can be restructured to avoid scheme switching entirely by expressing all operations in a single scheme, even if some operations are slightly less efficient than they would be in the optimal scheme.

Continuous Optimization

FHE-IQ improves over time through performance telemetry. Each computation reports its actual latency, noise consumption, and resource utilization back to the routing engine. FHE-IQ uses this data to refine its parameter selection heuristics, identifying cases where tighter parameters would have been sufficient (reducing overhead) or where more conservative parameters are needed (preventing noise budget exhaustion).

This feedback loop means that FHE-IQ's routing decisions improve with usage. Early deployments may use slightly conservative parameters that waste some performance headroom. As the engine accumulates data on actual workload characteristics, it tightens the parameters toward optimal values. Organizations benefit from this optimization without any manual tuning or cryptographic expertise.

FHE-IQ represents the conviction that FHE should be accessible to every developer, not just those with doctoral degrees in cryptography. The engine handles the hard decisions about scheme selection, parameter tuning, and computation planning so that developers can focus on building applications rather than studying lattice theory. The result is encrypted computation that is as easy to use as plaintext computation, with the privacy guarantees that only FHE can provide.

The Developer Experience

FHE-IQ's primary design goal is to make FHE accessible to developers who are not cryptographers. The typical interaction with FHE-IQ requires no cryptographic knowledge. The developer submits a computation through the H33 API: "match these two biometric templates," "run this query on this encrypted database," "compute the mean of this encrypted dataset." FHE-IQ analyzes the computation, selects the optimal scheme and parameters, and executes the computation. The developer receives the encrypted result and decrypts it locally. At no point does the developer need to know what BFV, CKKS, or TFHE are, what a noise budget is, or how to select polynomial degrees.

For developers who want visibility into FHE-IQ's decisions, the API provides a dry-run mode that returns the routing decision without executing the computation. This includes the selected scheme, the parameter set, the estimated noise consumption, and the expected latency. Advanced developers can use this information to understand the performance characteristics of their workloads and to identify opportunities for restructuring computations to improve efficiency.

The documentation includes a decision tree that explains FHE-IQ's routing logic in plain language. For each decision point (integer vs float, exact vs approximate, shallow vs deep), the documentation explains why one scheme is preferred over another and what performance implications the choice has. This educational resource helps developers build intuition about FHE scheme selection even if they rely on FHE-IQ for the actual decision in production.

Benchmarks and Validation

FHE-IQ's routing decisions are validated against benchmarks for each supported workload type. The validation compares FHE-IQ's selected scheme and parameters against expert-tuned configurations for the same workload, measuring both correctness (does the computation produce the right result?) and efficiency (how close is the performance to the expert configuration?). In benchmarks across H33's supported workload types, FHE-IQ's automatic selection achieves within 15% of expert-tuned performance, and in most cases within 5%. The cases where FHE-IQ underperforms the expert configuration are typically workloads with unusual characteristics that benefit from domain-specific knowledge that the general-purpose routing algorithm does not have.

These benchmarks are run continuously as part of H33's CI/CD pipeline. Any change to FHE-IQ's routing logic is validated against the benchmark suite before deployment, ensuring that improvements to one workload type do not degrade performance for others. The benchmark results are published quarterly in H33's performance reports, providing transparency into the routing engine's decision quality over time.