H33 vs IBM HElib:
Production FHE in 36µs

What Is IBM HElib?

HElib is an open-source C++ library for fully homomorphic encryption developed at IBM Research, originally by Shai Halevi and Victor Shoup. First released in 2013, it is one of the earliest practical FHE implementations and played a foundational role in demonstrating that computing on encrypted data was more than a theoretical curiosity.

HElib implements the Brakerski-Gentry-Vaikuntanathan (BGV) scheme and, more recently, the CKKS scheme for approximate arithmetic on encrypted floating-point values. It introduced key innovations including the Smart-Vercauteren ciphertext-packing technique that maps multiple plaintext values into a single ciphertext via the Chinese Remainder Theorem, and it was among the first libraries to implement FHE bootstrapping -- the process of refreshing a ciphertext to support unlimited computation depth.

HElib remains an active open-source project under the Apache 2.0 license, maintained by IBM Research. It is part of IBM's broader confidential computing strategy, though HElib itself is positioned as a low-level cryptographic toolkit rather than an application-layer product.

Where HElib Falls Short for Production

Despite its pioneering status, HElib was designed as a research vehicle, and that origin is visible in every layer of the stack. For teams evaluating FHE for production workloads -- authentication, biometric matching, real-time fraud detection -- several structural limitations become blockers.

Performance at Scale

HElib's bootstrapping operation -- necessary for deep circuits -- runs in the hundreds-of-milliseconds to multi-second range depending on parameter selection and circuit depth. A single BGV multiplication followed by relinearization typically lands between 10ms and 100ms. For research workflows that process batches overnight, this is acceptable. For an API that must return in under a millisecond, it is not.

The library is single-threaded by default. While NTL (the underlying number-theory library) supports thread pools, achieving meaningful parallelism requires significant manual orchestration. There is no built-in worker model, no batch pipeline, and no SIMD-aware scheduling for multi-user workloads.

API Complexity

HElib exposes the full complexity of FHE parameter selection to the developer. Choosing polynomial degree, modulus chain depth, plaintext modulus, number of columns in key-switching matrices, and bootstrapping parameters requires deep familiarity with the noise budget mathematics of BGV. The documentation is sparse -- primarily academic papers and a small set of examples. For a team without a dedicated cryptographer, the learning curve is measured in months.

No Authentication Pipeline

HElib is a primitive library. It provides encrypt, decrypt, add, multiply, and rotate. It does not provide biometric template matching, zero-knowledge proof generation, post-quantum digital signatures, or any form of authentication workflow. Building an auth system on HElib means writing thousands of lines of application code on top of a low-level API, then optimizing it yourself.

No Post-Quantum Signatures or ZKP

HElib's lattice-based encryption is inherently quantum-resistant -- BGV and CKKS rest on the Ring Learning With Errors (RLWE) problem. However, HElib provides no signature scheme, no attestation layer, and no zero-knowledge proofs. An authentication system requires all three: encrypted matching (FHE), proof of correctness (ZKP), and tamper-evident signing (signatures). HElib covers one of the three.

H33's Production Approach

H33 was designed from the ground up as a production authentication pipeline, not a cryptographic toolkit. Every architectural decision -- from the BFV scheme selection to the Montgomery NTT kernel to the in-process ZKP cache -- serves a single goal: deliver FHE-encrypted biometric authentication at API-call speed.

The H33 pipeline processes a complete authentication in three stages within a single API call:

1. FHE Batch (BFV) -- Encrypted inner-product matching for 32 users packed via SIMD into a single ciphertext. 967µs per batch on Graviton4. Montgomery radix-4 NTT with Harvey lazy reduction eliminates all division from the hot path.
2. ZKP Verification -- In-process DashMap lookup confirms proof validity in 0.062µs. No TCP round-trips, no serialization overhead.
3. Post-Quantum Attestation -- SHA3-256 prefix hash plus a single CRYSTALS-Dilithium sign-and-verify cycle, batched across 32 users. 191µs per batch, NIST FIPS 204 compliant.

Total pipeline latency: ~1,160µs for 32 users. That is 36µs per authentication, including FHE, ZKP, and post-quantum signature -- end to end.

Head-to-Head Comparison

The comparison is asymmetric by design. HElib is a general-purpose FHE library that supports arbitrary circuits of arbitrary depth. H33 is a purpose-built authentication engine that constrains its FHE workload to shallow, fixed-structure inner products -- and then fuses ZKP and post-quantum signatures into the same pipeline. These are fundamentally different products solving fundamentally different problems, which is precisely why the performance gap is so large.

When to Use Each

Choose IBM HElib If:

• You are conducting FHE research -- HElib's BGV bootstrapping implementation is one of the most complete in the ecosystem. If your work involves deep arithmetic circuits, novel circuit constructions, or academic benchmarking, HElib gives you low-level control that no production API can match.
• You need arbitrary-depth computation -- Applications like private ML inference on encrypted neural networks with dozens of layers may require bootstrapping. HElib supports this; H33's shallow-circuit design does not target it.
• Your team has cryptographic expertise -- If you have PhD-level cryptographers who understand noise budgets, modulus chains, and key-switching dimensions, HElib provides the flexibility to build bespoke FHE applications.

Choose H33 If:

• You need production authentication -- FHE-encrypted biometric matching, zero-knowledge verification, and post-quantum attestation in a single API call at microsecond latency. This is what H33 was built for.
• Throughput matters -- 2.15M auth/sec on a single instance. No external dependencies, no message queues, no microservice meshes. One binary, one API.
• You need NIST compliance -- H33 implements FIPS 203 (ML-KEM / Kyber) and FIPS 204 (ML-DSA / Dilithium) natively. HElib provides no signature or key-exchange primitives.
• Your team does not have dedicated cryptographers -- H33 abstracts away polynomial degree selection, NTT kernel optimization, noise management, and SIMD packing. You call an API. The engine handles the rest.

Why the Performance Gap Exists

The 13,888x difference is not a quality judgment on HElib's code. It reflects a design philosophy gap. HElib optimizes for generality: support every circuit, every depth, every parameter set. H33 optimizes for one workload -- biometric inner products -- and then eliminates every unnecessary operation:

• No bootstrapping -- H33's BFV parameters (N=4096, single 56-bit modulus, t=65537) are tuned so that the entire authentication circuit completes within the initial noise budget. No ciphertext refresh is ever needed.
• Montgomery NTT domain persistence -- Twiddle factors and enrolled templates remain in Montgomery/NTT form permanently. The hot path executes zero forward NTTs and only one final inverse NTT per batch.
• SIMD batching at the ciphertext level -- 4,096 polynomial slots divided by 128 biometric dimensions packs 32 users into a single ciphertext. One encrypt, one multiply, one decrypt serves 32 users.
• In-process ZKP cache -- DashMap lookups at 0.062µs eliminate the TCP serialization bottleneck that would otherwise dominate the pipeline.
• Batch attestation -- One Dilithium sign-and-verify per 32-user batch instead of 32 individual operations. A 31x reduction in signature overhead.

HElib cannot make these trade-offs because it is a general-purpose library. The performance difference is the cost of generality, and for HElib's intended audience -- researchers pushing the boundaries of what FHE can compute -- that cost is worth paying.

Related Comparisons