H33 vs OpenFHE: Production System vs Academic Framework

OpenFHE is the most comprehensive open-source homomorphic encryption library available today. Born from the PALISADE project and developed primarily by Duality Technologies and academic partners, OpenFHE supports BGV, BFV, CKKS, and TFHE under a single API. It is the Swiss Army knife of FHE libraries, offering more scheme coverage than any competitor. For academic research and prototyping, it is arguably the best tool available in any language or ecosystem.

H33 takes a different approach entirely. Rather than offering maximum FHE flexibility, H33 provides a production-ready pipeline that combines FHE with STARK-based zero-knowledge proofs and post-quantum digital signatures. The question facing organizations evaluating these two options is not which one does more FHE, but which one gets encrypted computation into production faster and with stronger end-to-end security guarantees that span encryption, verification, and attestation.

The PALISADE Heritage

OpenFHE evolved from the PALISADE library, which was originally developed under DARPA's SafeWare program. This heritage gives OpenFHE a strong academic foundation and a focus on correctness and generality over raw performance. The library supports multiple FHE schemes, multiple security parameter sets, and multiple optimization strategies. It is designed to be a reference implementation that researchers can use to compare different approaches to homomorphic encryption on equal footing, with consistent APIs across scheme families.

This academic heritage is both a strength and a limitation. The strength is thoroughness: OpenFHE implements features like scheme switching (converting between BGV and CKKS mid-computation) and proxy re-encryption that few other libraries offer. The limitation is that the codebase prioritizes generality over specialization, which means performance for any specific use case is typically not as optimized as a purpose-built implementation that can make assumptions about its workload and target hardware.

Scheme Coverage Comparison

OpenFHE supports four FHE scheme families: BGV for exact integer arithmetic, BFV for exact integer arithmetic with a different noise management approach, CKKS for approximate floating-point arithmetic, and TFHE (through the FHEW integration) for Boolean circuit evaluation. It also supports advanced features like multi-party computation protocols, threshold FHE, and scheme switching between families during computation.

H33 supports three FHE scheme families: BFV for the core authentication pipeline, CKKS for floating-point workloads, and TFHE for bit-level encrypted operations. H33 does not support BGV as a separate scheme (BFV and BGV are closely related, and H33 chose BFV for its more natural handling of the plaintext modulus). H33 also does not currently support scheme switching or threshold FHE, as these features are not required for its target workloads in authentication, compliance, and AI auditing.

On pure scheme coverage, OpenFHE wins clearly. It supports more schemes and more advanced features within each scheme. But scheme coverage is only one dimension of a production deployment. The other dimensions including verification, signing, caching, API design, deployment, and monitoring are where H33 provides capabilities that OpenFHE does not attempt to address because they are outside the scope of an FHE library.

The Pipeline Gap

The fundamental architectural difference is that OpenFHE is a library and H33 is a system. When you use OpenFHE, you get FHE operations and nothing else. When you use H33, you get FHE operations plus STARK-based zero-knowledge proof verification plus post-quantum digital signatures, all in a single API call with no integration required on your end. This is not a minor distinction. It represents the difference between having a component and having a deployable solution that works end to end.

Consider what happens when you process a biometric authentication through each system. With OpenFHE, you encrypt the biometric vector, perform the inner product comparison homomorphically, and decrypt the result. You now have a match or no-match answer, but you have no proof that the computation was performed correctly, no quantum-resistant signature attesting to the result, and no compact representation suitable for on-chain anchoring or long-term archival verification.

With H33, the same biometric authentication is encrypted via BFV in a batch of 32 users, the result is verified through a STARK-based zero-knowledge proof (cached for sub-microsecond lookup), and the batch is signed with a three-key post-quantum signer based on three independent hardness assumptions. The output includes the authentication result, the verification proof, and a quantum-resistant attestation that will remain valid for decades. The entire pipeline completes in 42 microseconds per authentication on Graviton4 hardware.

Performance Architecture

OpenFHE is written in C++ and targets general-purpose hardware. It uses hardware acceleration where available (HEXL for Intel processors, for example) and provides a flexible backend architecture that allows swapping in different implementations for different platforms. The generality of the codebase means that performance tuning typically happens at the application level rather than the library level. Users select parameters, choose optimization strategies, and manage the computation pipeline themselves based on their specific requirements.

H33 is written in Rust and is specifically optimized for AWS Graviton4 (ARM64) hardware. The number-theoretic transform uses Montgomery arithmetic with radix-4 operations tuned for the ARM cache hierarchy. The system allocator is used because extensive benchmarking showed that glibc's malloc on ARM outperforms custom allocators like jemalloc for the tight FHE computation loops that dominate the workload at 192 concurrent workers. The CacheeEngine provides in-process caching with constant 512 KiB memory overhead through a Count-Min Sketch admission policy and CacheeLFU eviction.

On Graviton4 (c8g.metal-48xl, 192 vCPUs), H33 sustains over 1.6 million full-pipeline authentications per second. Each authentication includes FHE encryption in a 32-user batch, STARK verification via cached lookup, and post-quantum signing with the three-key signer. The batch latency is approximately 1,345 microseconds for 32 users, broken down as 943 microseconds for FHE, 391 microseconds for batch attestation, and sub-microsecond for cached ZKP lookup. These numbers reflect the complete pipeline with all three stages, not isolated FHE operations.

Post-Quantum Signatures

OpenFHE does not include any digital signature functionality whatsoever. The security of the FHE operations is quantum-resistant because it is based on lattice assumptions, but there is no built-in mechanism for signing outputs or attesting to computation results. If you need post-quantum signatures on your FHE results, you must integrate a separate library, handle key management yourself, and ensure the signature covers exactly the right data with no gaps or mismatches between the FHE output and the signed content.

H33 includes a three-key post-quantum signer that combines ML-DSA (NIST FIPS 204), FALCON, and SLH-DSA. These three signature schemes rest on three independent hardness assumptions: MLWE lattices, NTRU lattices, and stateless hash functions. An attacker must break all three simultaneously to forge a signature. This defense-in-depth approach means that if one mathematical family is eventually weakened by new cryptanalysis, the other two families maintain the security of every attestation ever issued through the system.

The H33-74 substrate distills the full three-key attestation into just 74 bytes: 32 bytes on-chain and 42 bytes in Cachee. This distillation is not compression in the traditional sense. It is a cryptographic distillation process that preserves the full security guarantees of the original multi-kilobyte signature bundle while making on-chain anchoring economically practical. OpenFHE has no equivalent concept because attestation is entirely outside its design scope.

Zero-Knowledge Verification

OpenFHE does not include zero-knowledge proof capabilities. If you need to prove that an FHE computation was performed correctly without revealing the plaintext data, you must design and implement your own ZKP circuit that mirrors the FHE operations. This is an extremely challenging undertaking that requires expertise in both FHE parameter selection and ZKP circuit design, two fields that have very few practitioners at the intersection.

H33 uses STARK-based zero-knowledge proofs with no trusted setup requirement. The proofs are generated as part of the pipeline and verified through cached lookups in the CacheeEngine. The CacheeEngine uses a CacheeLFU eviction policy with a Count-Min Sketch admission filter, which keeps memory usage constant at 512 KiB regardless of the number of entries being tracked. This design allows ZKP verification to add sub-microsecond latency to the pipeline, making it effectively free from a performance perspective.

Language Safety and Security

OpenFHE is written in C++. While the codebase follows modern C++ practices and has been reviewed extensively by the academic community, C++ fundamentally allows memory safety violations that can lead to security vulnerabilities in any codebase regardless of developer skill. Buffer overflows, use-after-free, and double-free bugs are possible in any C++ program, and cryptographic code is a high-value target for attackers looking to exploit such vulnerabilities for key extraction or ciphertext manipulation.

H33 is written in Rust, which enforces memory safety at compile time through its ownership and borrowing system. This eliminates entire categories of vulnerabilities without runtime overhead or garbage collection pauses. For a system that processes millions of cryptographic operations per second handling sensitive biometric and authentication data, memory safety is a critical requirement that cannot be achieved through testing or code review alone no matter how thorough those processes are.

Advanced FHE Features

OpenFHE excels in advanced FHE features that H33 does not currently offer. Scheme switching allows converting between BGV and CKKS mid-computation, which is useful for applications that need both exact and approximate arithmetic in a single pipeline. Threshold FHE distributes the decryption key among multiple parties so that no single party can decrypt alone, enabling secure multi-party computation on encrypted data. Proxy re-encryption allows converting a ciphertext encrypted under one key to be decryptable under a different key without intermediate decryption.

H33 focuses on the features needed for its target use cases: encrypted authentication, encrypted search, encrypted compliance checks, and encrypted AI auditing. For these workloads, BFV with batched processing, STARK verification, and PQ signing cover the requirements completely. The tradeoff is clear: if you need scheme switching or threshold FHE for a multi-party research application, OpenFHE is the right choice. If you need a production pipeline that processes encrypted data at scale with verification and quantum-resistant attestation, H33 is the right choice.

Deployment Models

OpenFHE is a shared library that you link into your application. It supports Linux, macOS, and Windows, and can be compiled for various architectures including x86 and ARM. The deployment model is entirely up to you: you build your application with OpenFHE as a dependency and deploy it however your organization deploys software. This flexibility is valuable for research labs but places the entire operational burden on your engineering team for production deployments.

H33 deploys as a single Rust binary with a REST API. There are no external dependencies beyond the operating system. The binary can run on any ARM64 or x86_64 Linux system, with optimal performance on AWS Graviton4 instances. The single-process architecture eliminates distributed system complexity: there are no message queues to manage, no inter-service communication protocols to debug, and no container orchestration required for the core pipeline to function correctly under load.

Community and Support Models

OpenFHE has an active academic community with regular contributions from multiple universities and research labs around the world. The project benefits from DARPA funding and institutional support from Duality Technologies. Documentation is extensive, with tutorials, API references, and example applications covering each scheme family and many advanced features. For researchers, this community is invaluable for understanding the state of the art.

H33 provides commercial support with defined SLAs, security incident response, and a dedicated engineering team focused on production reliability rather than research flexibility. When a new vulnerability is discovered in a cryptographic primitive or when NIST updates a post-quantum standard, H33 customers receive patches directly rather than having to monitor the cryptographic literature and apply fixes themselves on their own timeline.

The Right Choice Depends on Your Goals

If you are conducting FHE research, evaluating different scheme tradeoffs, or building a novel application that requires advanced features like scheme switching or threshold FHE, OpenFHE is the best tool available. It offers unmatched flexibility and scheme coverage, backed by a strong academic community and DARPA heritage that gives it credibility in research contexts.

If you are deploying encrypted computation in production and need verification, post-quantum signing, high throughput, and operational simplicity, H33 is designed for exactly that purpose and that context. The pipeline approach eliminates the integration complexity that makes production FHE deployments so challenging to build and maintain, and the post-quantum signing ensures your attestation layer survives the quantum transition that is now clearly on the horizon for the next decade.

The two projects serve different points on the research-to-production spectrum. Understanding where your project sits on that spectrum, and being honest about your team's cryptographic engineering depth, is the key to making the right choice for your organization, your timeline, and your users.