H33 vs IBM HElib: Production FHE vs Research Library

When organizations evaluate homomorphic encryption for production workloads, two names surface repeatedly: H33 and IBM HElib. Both work with encrypted data. Both implement lattice-based FHE schemes. But that is where the similarities end. HElib is a research library that provides homomorphic encryption primitives. H33 is a production system that fuses FHE, zero-knowledge proofs, and post-quantum digital signatures into a single pipeline. The difference between the two is the difference between a jet engine on a test stand and a commercial aircraft carrying passengers at altitude.

This comparison is not about which project has better academics behind it. IBM Research has contributed foundational work to the field of homomorphic encryption, and HElib represents years of rigorous mathematical development. What this comparison examines is a practical question: if you need to deploy encrypted computation in production today, what does each option actually give you, and what does it leave you to build yourself?

Architecture: Library vs System

IBM HElib is a C++ library that implements the BGV (Brakerski-Gentry-Vaikuntanathan) and CKKS (Cheon-Kim-Kim-Song) homomorphic encryption schemes. It provides the cryptographic primitives needed for FHE: key generation, encryption, decryption, and homomorphic operations like addition and multiplication on ciphertexts. It is a well-engineered library with support for bootstrapping, which allows computations of arbitrary depth on encrypted data. For researchers building new FHE applications or testing theoretical ideas, HElib is a solid foundation.

H33 is a complete cryptographic pipeline that combines fully homomorphic encryption with zero-knowledge proofs and post-quantum digital signatures in a single API call. When you send data through H33, it gets encrypted using BFV (Brakerski-Fan-Vercauteren) homomorphic encryption, the computation result is verified through a STARK-based zero-knowledge proof, and the entire output is signed with post-quantum digital signatures based on three independent hardness assumptions. The FHE, ZKP, and PQ signing stages are fused into a single pipeline that runs on a single machine without network hops between stages.

This architectural difference matters because real production systems need more than encryption. They need attestation (proof that the computation happened correctly), verification (proof that the result was not tampered with), and quantum-resistant signatures (protection against future quantum computers). With HElib, you get the encryption. Everything else is your problem to solve, integrate, test, and maintain across every deployment and upgrade.

FHE Scheme Support

HElib supports BGV and CKKS. BGV is an integer-arithmetic FHE scheme that works well for exact computations on discrete values. CKKS is an approximate-arithmetic scheme designed for floating-point-like computations, which is useful for machine learning workloads where small rounding errors are acceptable. HElib does not support BFV or TFHE (Torus FHE).

H33 supports BFV, CKKS, and TFHE. BFV is the workhorse for H33's production pipeline, optimized for the batched authentication workload that processes 32 users per ciphertext. H33-CKKS handles floating-point approximate arithmetic for workloads that need it. H33-TFHE provides gate-by-gate encrypted computation for scenarios requiring bit-level operations on encrypted data. All three schemes are implemented from scratch in Rust with no external FHE dependencies, giving H33 full control over performance optimization and security parameters.

The BFV implementation in H33 uses a proprietary number-theoretic transform that is specifically optimized for ARM architectures like AWS Graviton4. This matters because cloud deployments increasingly run on ARM, and H33's pipeline is tuned for the memory hierarchy and instruction set of these processors. HElib's BGV implementation targets x86 architectures and does not have ARM-specific optimizations at the same level of depth.

Performance: Benchmarks That Matter

Raw FHE operation benchmarks are misleading when comparing a library to a system. HElib can perform a homomorphic multiplication in a certain number of milliseconds, and H33 can perform one in a different number of milliseconds, but these numbers do not tell you anything about production throughput. What matters is: how many complete, verified, signed operations can you do per second?

H33's production pipeline on AWS Graviton4 (c8g.metal-48xl, 192 vCPUs) processes over 1.6 million authenticated operations per second in sustained benchmarks. Each operation includes BFV homomorphic encryption of a 32-user batch, STARK-based zero-knowledge proof verification via cached lookup, and post-quantum digital signature generation and verification using ML-DSA (Dilithium). The per-authentication latency is 42 microseconds for the complete pipeline.

HElib does not have an equivalent benchmark because it is not a pipeline. You would need to combine HElib with a ZKP library, a post-quantum signature library, a caching layer, and an orchestration layer, and then benchmark the result. The integration overhead alone typically adds significant latency because each component communicates through serialization boundaries. H33 avoids this entirely by keeping everything in-process with shared memory and zero serialization between pipeline stages.

Post-Quantum Security

HElib's underlying security is based on the hardness of lattice problems, which are believed to be quantum-resistant. This means the encryption itself should survive a quantum computer. But HElib does not provide digital signatures. If you use HElib in a system that signs results with RSA or ECDSA, those signatures are vulnerable to quantum attack. Your encrypted data is safe, but your attestation layer is completely broken.

H33 provides post-quantum security across the entire pipeline. The FHE layer uses lattice-based BFV (quantum-resistant). The signature layer uses a three-key signer combining ML-DSA (based on MLWE lattices), FALCON (based on NTRU lattices), and SLH-DSA (based on stateless hash functions). These three families rest on three independent hardness assumptions. An attacker would need to break all three simultaneously to forge a signature. This is defense in depth at the cryptographic level, not merely at the implementation level.

The H33-74 substrate distills the entire attestation down to 74 bytes: 32 bytes on-chain and 42 bytes in Cachee. This is not compression in the traditional sense. It is distillation, a process that preserves the cryptographic guarantees of the full signature bundle while reducing the storage and bandwidth requirements by orders of magnitude. HElib has no equivalent concept because it does not operate at the attestation layer at all.

Zero-Knowledge Proofs

HElib does not include any zero-knowledge proof system. If you need to prove that a computation on encrypted data was performed correctly without revealing the data or the intermediate steps, you must integrate a separate ZKP library. This is non-trivial. ZKP systems have their own parameter selection requirements, their own trusted setup considerations (for SNARK-based systems), and their own performance characteristics that must be tuned to work with your FHE parameters.

H33 includes a STARK-based ZKP system that is integrated directly into the pipeline. STARK proofs do not require a trusted setup, which eliminates a significant operational and security burden. The ZKP verification in H33 uses cached lookups through the CacheeEngine, which brings the ZKP verification step down to sub-microsecond latency. This is possible because H33 controls both the proof generation and the caching layer, allowing optimizations that would be impossible with separate components communicating across process or network boundaries.

Deployment and Operations

Deploying HElib in production requires significant engineering effort. You need to compile the C++ library for your target platform, integrate it with your application code, manage memory carefully (FHE operations are memory-intensive), handle serialization of ciphertexts for storage and transmission, and build monitoring around all of it. HElib provides the cryptographic building blocks but none of the operational infrastructure that a production system requires.

H33 deploys as a Rust binary with a REST API. You send data in, you get encrypted, verified, signed results back. The entire pipeline runs in a single process, which simplifies deployment, monitoring, and scaling. There is no need to manage separate services for FHE, ZKP, and signing. The system allocator is used instead of custom allocators because extensive benchmarking showed that the default glibc malloc on ARM is already optimized for the tight FHE computation loops that H33 runs with 192 concurrent workers.

For organizations that need to integrate H33 into existing systems, the API-first approach means you can add post-quantum encrypted computation to any application that can make HTTP calls. HElib requires native C++ integration or building your own service wrapper around the library, which is a substantial engineering undertaking on its own.

Language and Memory Safety

HElib is written in C++. This gives it access to mature tooling and a large developer ecosystem, but it also means dealing with C++ build systems, memory management complexities, and the security implications of a language without memory safety guarantees. Buffer overflows in cryptographic code are not merely bugs; they are potential attack vectors that can lead to key leakage or complete system compromise.

H33 is written in Rust, which provides memory safety guarantees at compile time without garbage collection overhead. In a system that processes millions of cryptographic operations per second, memory safety is not a nice-to-have; it is an absolute requirement. Rust's ownership system prevents entire categories of bugs that could lead to key leakage or ciphertext corruption. The performance characteristics of Rust are comparable to C++, so there is no meaningful tradeoff in choosing memory safety for this workload.

Use Case Alignment

HElib is ideal for researchers who want to experiment with BGV or CKKS homomorphic encryption, prototype new FHE applications, or study the performance characteristics of different parameter sets. It is a research tool, and it excels in that role. If you are writing a paper about a new FHE technique, HElib is a reasonable choice as a baseline implementation to compare against.

H33 is designed for organizations that need to deploy encrypted computation in production. Healthcare companies that must process patient data without exposing it to compute infrastructure. Financial institutions that need to run compliance checks on encrypted transactions. AI companies that want to audit models without seeing training data. Government agencies that need post-quantum-secure authentication at scale. These are workloads where you cannot afford to assemble your own cryptographic pipeline from research libraries and hope that the integration holds under production load.

Integration Complexity

Building a production-grade encrypted computation system on top of HElib requires integrating at least four separate components: the FHE library itself, a zero-knowledge proof system, a post-quantum signature library, and a caching or performance layer. Each component must be separately evaluated for security, separately benchmarked for performance, and separately maintained for updates and patches. The integration surface between these components is where bugs hide and where attackers look first. Serialization mismatches, parameter inconsistencies, and timing side channels at component boundaries are difficult to audit and easy to miss.

H33 eliminates this integration complexity by providing a single, audited pipeline. The FHE parameters, ZKP circuits, and signature schemes are co-designed to work together. The caching layer is built into the pipeline. The entire system is benchmarked as a unit, not as individual components. This matters because the performance of a cryptographic system is often dominated by the integration overhead rather than the raw speed of individual operations.

Maintenance and Long-Term Support

HElib is maintained by IBM Research as an open-source project. Development activity has varied over the years, with periods of active development followed by quieter periods. As with any open-source research project, long-term support depends on continued interest from the research team and the broader community. There is no SLA or guaranteed response time for security issues, and production users must monitor the cryptographic literature themselves.

H33 is a commercial product with a dedicated engineering team, security response processes, and a contractual obligation to maintain the system for production customers. When NIST finalizes new post-quantum standards or when new attacks against FHE schemes are published, H33 customers receive updated binaries. The response time is bounded by SLA, not by the availability of volunteer contributors.

Cost Considerations

HElib is free and open source under the Apache 2.0 license. The cost of using HElib is entirely in engineering time: the time to learn the library, integrate it into your system, build the surrounding infrastructure, optimize performance, and maintain everything over time. For a well-funded research lab, this is reasonable and expected. For a product team with delivery deadlines, this engineering cost is substantial and ongoing with no guaranteed endpoint.

H33 is a commercial service with API-based pricing. You pay per operation, but you get a complete pipeline that is already optimized, already integrated, and already maintained by specialists. The total cost of ownership calculation depends on your team's expertise, your timeline, and the criticality of the workload. For most production deployments, the commercial approach has a lower total cost because the engineering time saved exceeds the API cost by a wide margin.

The Bottom Line

IBM HElib is a respected research library that has advanced the field of homomorphic encryption. H33 is a production system that takes FHE and combines it with ZKP and post-quantum signatures into a single, deployable pipeline. If you are researching new FHE techniques, HElib gives you a solid foundation. If you are building a product that needs encrypted computation with attestation and quantum resistance, H33 gives you a complete system that works today at the scale of 1.6 million operations per second.

The gap between a library and a system is not something you can close quickly. Building a production-grade cryptographic pipeline requires years of engineering, extensive security auditing, and deep expertise in multiple domains of cryptography. That is what H33 provides, and what HElib, by design, does not attempt to provide. The question is not which one is technically superior. It is whether your goal is research or production.