Related · tier-1 reading. For what a portable artifact actually is, see Portable Artifact.
Fully Homomorphic Encryption lets H33 compute directly on encrypted data. The server never sees your plaintext — because it never needs to.
The H33 FHE Platform is the system that runs computation directly over ciphertext — it never decrypts the data to compute on it. This is the one verb it owns: it computes on encrypted data. Every page in this neighborhood — the platform, the API, FHE-IQ, and the underlying schemes — is a supporting expression of that single capability.
Why it exists: conventional encryption protects data at rest and in transit, but the moment you need to use it, you decrypt — and that decryption window is the exposure. FHE removes the window: the server processes ciphertext and returns an encrypted result that only the key holder can open.
FHE schemes (TFHE, BFV, BGV, CKKS) and libraries (Zama/Concrete, Microsoft SEAL, OpenFHE, HElib, Lattigo) are external, standardized building blocks. H33 implements, uses, and verifies against them; it does not own or claim to have invented them.
Traditional biometric authentication has a fundamental flaw: to compare your biometric against a stored template, the system must decrypt both.
That moment of decryption — even if it lasts only milliseconds — is when biometric data can be intercepted, copied, or stolen. Unlike a password, you cannot change your fingerprint or face.
H33 eliminates the decryption window entirely. Matching happens on ciphertext. Your biometric template is never reconstituted as plaintext on the server.
Four proprietary FHE engines — each optimized for a specific class of encrypted computation. Written from scratch. Zero external FHE dependencies.
Five new modules extend the FHE platform into boolean circuits, real-time streaming, encrypted ML activations, multi-party computation, and unlimited multiplicative depth.
BFV implementations: Lightning 128 · Lightning 256 · Full 128 · Full 256 — the four canonical public BFV libraries of the H33 FHE Platform. (CKKS and TFHE are separate schemes; BFV‑32/BFV‑64 are internal runtime engines.)
From biometric authentication to multi-party computation — every workload stays encrypted end to end.
Process face and fingerprint vectors entirely in ciphertext. 32 users per batch at ~967µs. The server never sees biometric data — not during enrollment, not during matching.
Run aggregations, counts, and statistical queries over encrypted databases. CKKS for float analytics, BFV for integer counts. Results decrypted only by the data owner.
Train or run inference on encrypted features. CKKS dot products for similarity scoring. Model weights are plaintext, input data stays encrypted throughout.
Portfolio risk scoring, fraud detection, and credit assessment on encrypted financial records. FHE ensures the computation platform never sees PII or account data.
HIPAA-compliant computation on encrypted PHI. Eligibility checks, claims scoring, and clinical trial matching — all without exposing patient records.
Use FHE as the encryption layer for MPC protocols. Each party's inputs are FHE-encrypted. The coordinator computes on ciphertexts. No party sees another's data.
A single API call. Four cryptographic stages. Your plaintext never touches the server.
Computation happens entirely in ciphertext space. Only the final yes/no answer is revealed through distributed threshold decryption.
The decryption key is split across multiple independent servers using Shamir secret sharing. No single party can ever reconstruct your data.
Three tiers from development through maximum security. Each tier increases the ring dimension for stronger lattice-based guarantees.
| Tier | Security | Ring Dimension | Latency | Use Case |
|---|---|---|---|---|
| H0 / H1 | ~80–112 bit | N = 1,024 | 356µs | Development and testing |
| H33-128RECOMMENDED | 128-bit (NIST L1–L3) | N = 4,096 | 1.36ms | Production (default) |
| H-256 | 256-bit (NIST L5) | N = 16,384 | 5.98ms | Maximum security |
Production benchmarks on ARM-based cloud infrastructure. February 2026.
| Feature | Microsoft SEAL | Zama | TFHE-rs | H33 |
|---|---|---|---|---|
| Encrypt Speed | Baseline | Slower | Baseline | 2–4x faster |
| Compute Speed | Baseline | Slower | Comparable | 3–4x faster |
| FHE Schemes | BFV + CKKS | TFHE-based | TFHE | BFV + CKKS + |
| CKKS Bootstrapping | Not supported | N/A | N/A | Full support |
| SIMD Batching | Manual | Limited | No | 32 users/ciphertext |
| Threshold Decryption | No | No | No | k-of-n built-in |
| License Fees | Free (MIT) | $100K–$500K+ | Community + Enterprise | API pricing only |
| Full Auth Stack | FHE library only | FHE only | FHE only | FHE + ZK + PQC + Bio |
Encrypted authentication in a few lines of code. No cryptography expertise required.
~35.25 microseconds per authentication, which is fast enough for real-time production use. Most of our customers report that network latency, not FHE computation, is their bottleneck.~35.25 microseconds./pricing for a free API key with 1,000 credits per month. Install the SDK for your language (Rust, Python, JavaScript, or Go). Call POST /v1/fhe/encrypt with your data to get a ciphertext. Call POST /v1/fhe/compute to perform operations on it. Call POST /v1/fhe/decrypt to get the result. The quickstart guide in the docs walks through a complete biometric enrollment and verification flow in under 20 lines of code.