BenchmarksStack Ranking
H33-VaultH33-ShareH33-ShieldH33-HealthH33-KeyH33-128H33-CKKSH33-256H33-BFV32H33-FHE-IQFHE OverviewZK LookupsBiometricsH33-3-KeyH33-MPCPQC ArchitecturePQ VideoStorage EncryptionAI DetectionEncrypted Search
APIsPricingDocsWhite PaperTokenBlogAboutSecurity Demo
Log InGet API Key
Fully Homomorphic Encryption

Your Data Never
Leaves Encryption

Fully Homomorphic Encryption lets H33 compute directly on encrypted data. The server never sees your plaintext — because it never needs to.

0 bytes
Plaintext Exposure
2.17M/s
Auth Throughput
<1ms
Sub-millisecond Latency
NIST PQC
Post-Quantum Compliant
Get API Key View Documentation

The Decryption Problem

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.

Traditional Authentication
Biometric → Encrypt → DECRYPT → Compare → Result
Plaintext exposed for 2–50ms per auth
H33 FHE Authentication
Biometric → Encrypt → Match on Ciphertext → Threshold Decrypt
Zero plaintext exposure. Ever.
Four FHE Products

Purpose-Built Encryption for Every Workload

Four proprietary FHE engines — each optimized for a specific class of encrypted computation. Written from scratch. Zero external FHE dependencies.

H33 BFV Production Default
Brakerski/Fan-Vercauteren — Integer Arithmetic FHE
The production workhorse for biometric authentication and identity verification. Performs encrypted inner-product matching entirely in ciphertext space — the server never sees your data. SIMD batching packs 32 users into a single ciphertext for extreme throughput.
  • Encrypted biometric matching (face, fingerprint, iris)
  • SIMD batching: 32 users per ciphertext
  • 128-bit to 256-bit security (NIST Level 1 through Level 5)
  • Encrypted database queries and identity matching
~42µs
Per auth (batched)
1.36ms
Single full auth
32
Users per ciphertext
256KB
Per user (128x reduction)
H33 CKKS ML / AI Workloads
Cheon-Kim-Kim-Song — Approximate Arithmetic FHE
Run neural networks, scoring models, and complex analytics entirely on encrypted data. Full bootstrapping enables unlimited computational depth — rescaling manages precision automatically across operations.
  • Encrypted ML inference and neural network evaluation
  • Full bootstrapping for unlimited multiplicative depth
  • Automatic rescaling for precision management
  • Healthcare data processing, financial modeling, analytics
Unlimited
Multiplicative depth
Auto
Precision management
45.2µs
Encode real numbers
Full
CKKS bootstrapping
H33 BFV32 Mobile / Edge
ARM-Native 32-bit FHE — Optimized for Mobile
Purpose-built for phones and edge devices. Uses native ARM NEON SIMD instructions for near-2x faster transforms on Apple Silicon and Snapdragon. Compatible wire format with BFV — mobile encrypts, cloud computes.
  • Native ARM NEON SIMD acceleration
  • Compatible wire format with cloud BFV
  • Designed for iOS and Android on-device encryption
  • Low-power and battery-constrained environments
~2x
Faster on ARM
4-lane
NEON SIMD
Same
Wire format
M1–M4
Apple Silicon native
Explore BFV32 →
H33 FHE-IQ Intelligent Routing
Automatic FHE Backend Selection — Zero Configuration
The unified routing layer above all three FHE engines. Describe your workload — FHE-IQ automatically selects the optimal backend, parameters, and security tier. Sub-microsecond routing decisions with zero configuration required.
  • Sub-microsecond routing decisions (<500ns)
  • Routes between BFV, CKKS, and BFV32 seamlessly
  • Zero configuration required
  • Multi-tenant platforms and mixed workloads
<500ns
Routing decision
3
FHE backends
0
Config required
Auto
Optimization
Use Cases

Encrypted Computation Across Industries

From biometric authentication to multi-party computation — every workload stays encrypted end to end.

🤚

Encrypted Biometric Authentication

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.

BFV · 32 users/CT · ~967µs batch
📊

Privacy-Preserving Analytics

Run aggregations, counts, and statistical queries over encrypted databases. CKKS for float analytics, BFV for integer counts. Results decrypted only by the data owner.

CKKS + BFV · Owner-only decrypt
🧠

Confidential Machine Learning

Train or run inference on encrypted features. CKKS dot products for similarity scoring. Model weights are plaintext, input data stays encrypted throughout.

CKKS · Encrypted inference · Plaintext weights
🏦

Encrypted Financial Computation

Portfolio risk scoring, fraud detection, and credit assessment on encrypted financial records. FHE ensures the computation platform never sees PII or account data.

BFV + CKKS · Zero PII exposure
🩺

Healthcare Data Processing

HIPAA-compliant computation on encrypted PHI. Eligibility checks, claims scoring, and clinical trial matching — all without exposing patient records.

HIPAA · Encrypted PHI · Zero exposure
🔗

Multi-Party Computation Bridge

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.

FHE + MPC · N-party privacy
How It Works

Authentication Without Decryption

A single API call. Four cryptographic stages. Your plaintext never touches the server.

1
Capture
User's device captures biometric data (fingerprint, face, or iris)
→
2
Encrypt
Client-side FHE encryption transforms data into ciphertext on the device
→
3
Compute
Server processes entirely in encrypted space — never decrypts your data
→
4
Result
Encrypted result returned. Threshold decryption reveals only: verified or not
The server NEVER sees your plaintext.

Computation happens entirely in ciphertext space. Only the final yes/no answer is revealed through distributed threshold decryption.

Threshold Decryption

No Single Server Holds the Key

The decryption key is split across multiple independent servers using Shamir secret sharing. No single party can ever reconstruct your data.

S1
S2
S3
S4
S5
3-of-5 threshold reached — result decrypted
Each server computes a partial decryption (noisy share).
Lagrange interpolation combines shares into the final result.
  • 🔑 k-of-n Shamir Secret Sharing
    The decryption key is mathematically split so that any k shares can reconstruct it, but fewer than k reveal nothing.
  • 🛡 No Single Point of Failure
    Default configuration is 3-of-5. Even if two servers are compromised, your data remains protected.
  • 🔒 Post-Quantum Secure
    Key shares are lattice-based. The threshold scheme itself is quantum-resistant.
  • 📜 Attested Partial Decryptions
    Each partial decryption includes a cryptographic attestation hash, providing verifiable proof of correct computation.
Security Tiers

Choose Your Security Level

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
Performance Benchmarks

Verified on AWS Graviton4

Production benchmarks on ARM-based cloud infrastructure. February 2026.

2.17M auth/sec sustained · ~42µs per auth (batched) · 32 users per ciphertext
2.17M
Auth/sec sustained
~42µs
Per-auth latency (batched)
1.36ms
Single full auth pipeline
32
Users per ciphertext

Competitive Comparison

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 + BFV32
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
Developer Experience

One API Call. Full Encryption.

Encrypted authentication in a few lines of code. No cryptography expertise required.

javascript
// Encrypt and authenticate — one API call const result = await h33.authenticate({ biometric: capturedTemplate, securityLevel: 'h33-128', mode: 'standard' }); // result.verified: true/false // result.attestation: Dilithium-signed proof // Your biometric was NEVER decrypted on our servers
Compliance & Certifications

Enterprise-Grade Security Posture

🛡
NIST FIPS 203/204
Compliant implementation
🔐
NIST Post-Quantum
ML-KEM & ML-DSA standards
📋
SOC 2 Ready
Security & availability controls
🩺
HIPAA Compatible
Encrypted PHI processing
✅
1,751 Tests Passing
Continuous validation
🔍
External Crypto Review
View results →

Frequently Asked Questions

What is FHE in simple terms?
Fully homomorphic encryption (FHE) lets you perform computations on encrypted data without decrypting it first. Think of it like a glove box in a chemistry lab: you manipulate the contents through sealed gloves without ever opening the box. H33 uses FHE to match biometrics, run searches, and perform analytics on your data while it stays encrypted the entire time. The server doing the computation never sees the plaintext.
What is the difference between BFV and CKKS?
BFV (Brakerski/Fan-Vercauteren) performs exact integer arithmetic on encrypted data. Results are bit-perfect. Best for biometric matching, encrypted search, and anything where numerical precision matters. CKKS (Cheon-Kim-Kim-Song) performs approximate floating-point arithmetic. Results have small rounding error (like floating-point in regular code). Best for machine learning inference, statistical analysis, and neural network evaluation where approximate results are acceptable.
When should I use which FHE engine?
Use H33-128 (BFV-64) for server-side biometric authentication, encrypted database queries, and exact integer computation. Use H33-CKKS for ML inference on encrypted data, encrypted analytics, and floating-point workloads. Use H33-BFV32 for on-device mobile encryption before sending to the cloud. Use FHE-IQ when you are unsure, as it automatically selects the optimal engine based on your workload characteristics.
Does FHE slow everything down?
Traditional FHE implementations are 10,000 to 1,000,000x slower than plaintext computation. H33 reduces this to practical levels through extensive optimization: Montgomery NTT, Harvey lazy reduction, SIMD batching (32 users per ciphertext), NTT-domain persistence, and batch attestation. The result is ~38 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.
How does threshold decryption work?
Instead of one server holding the complete secret key, the key is split into shares distributed across multiple independent nodes using Shamir's secret sharing. To decrypt a result, a minimum threshold of nodes (for example, 3 out of 5) must each contribute a partial decryption. The partial decryptions are combined to produce the final plaintext. No single node ever has enough information to decrypt on its own, even if it is compromised.
What does "no single server holds the key" actually mean?
It means there is no single point of compromise. In traditional encryption, whoever holds the secret key can decrypt everything. With H33's threshold decryption, the secret key is mathematically split so that no individual server, employee, or attacker can reconstruct it alone. You would need to simultaneously compromise a majority of geographically distributed, independently operated key-share holders. This is the strongest key management architecture available.
Can FHE work with existing databases?
Yes. Encrypted data is stored as BFV or CKKS ciphertexts, which are binary blobs that can be stored in any database (PostgreSQL, MySQL, MongoDB, S3, etc.). You store ciphertexts in a BLOB or BYTEA column alongside user identifiers. Queries are performed by loading ciphertexts and running FHE operations on them. H33's encrypted search product adds an index layer that enables efficient lookup without decryption. No database modifications are needed.
Is FHE mathematically proven secure?
Yes. BFV and CKKS security is based on the Ring Learning With Errors (RLWE) problem, which is a well-studied lattice problem believed to be hard for both classical and quantum computers. NIST selected lattice-based schemes (ML-KEM, ML-DSA) as their post-quantum standards based on the same hardness assumptions. The security proof reduces to: breaking the encryption requires solving RLWE, and no known algorithm (classical or quantum) can solve RLWE efficiently at the parameters H33 uses.
What do NIST security levels mean for FHE?
NIST defines 5 security levels based on the computational effort to break the scheme. Level 1 (equivalent to AES-128) is the baseline for most applications. Level 3 (equivalent to AES-192) is for sensitive government and financial data. Level 5 (equivalent to AES-256) is for classified and long-term archival. H33 offers all three: H33-128 at Level 1, H33-192 at Level 3, and H33-256 at Level 5. Higher levels increase ciphertext size and computation time proportionally.
How does FHE compare to traditional encryption like AES?
AES encrypts data for storage and transit, but you must decrypt before computing. Every computation requires exposing plaintext in memory, creating an attack surface. FHE encrypts data for computation. You never decrypt until the final result is needed. The tradeoff is performance: AES encryption/decryption takes nanoseconds, while FHE operations take microseconds to milliseconds. H33 makes this tradeoff practical for production workloads through aggressive optimization.
Can I do machine learning on encrypted data?
Yes. H33-CKKS is specifically designed for ML inference on encrypted inputs. You can evaluate neural network layers (matrix multiplications, polynomial activations) on encrypted data. The model weights can be in plaintext (the data stays encrypted) or both can be encrypted. Practical applications include encrypted medical diagnosis, private credit scoring, and confidential recommendation engines. Training on encrypted data is more limited but possible for simple models.
How large are FHE keys and ciphertexts?
For H33-128 (BFV, N=4096, single modulus): public key is ~64 KB, secret key is ~32 KB, and a single ciphertext is ~32 KB. For H33-256 (N=16384, multiple moduli): sizes are roughly 16x larger. CKKS ciphertexts are similar in size to BFV at the same polynomial degree. These sizes are compact compared to early FHE implementations (which were megabytes per ciphertext) and practical for network transmission and database storage.
How does H33 make FHE practical?
Through 15+ production-verified optimizations: Montgomery NTT (no division in the hot path), Harvey lazy reduction (deferred modular reduction between butterfly stages), SIMD batching (32 users per ciphertext), NTT-domain persistence (skip forward/inverse transforms), pre-NTT public keys, batch CBD sampling, fused INTT post-processing, pre-computed delta*m in encrypt, and batch Dilithium attestation (1 sign per 32 users). Together these bring per-auth latency from milliseconds to ~38 microseconds.
What is FHE-IQ and how does auto-selection work?
FHE-IQ is H33's intelligent routing layer that analyzes your workload and automatically selects the optimal FHE engine. It examines the data type (integer vs floating-point), required precision, multiplicative depth, target latency, and security level. For a biometric match, it routes to BFV. For an ML inference, it routes to CKKS. For a mobile client, it routes to BFV32. You call a single unified endpoint and FHE-IQ handles engine selection, parameter tuning, and batching strategy.
How do I get started with H33 FHE?
Sign up at /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.

Deploy Encrypted Authentication Today

One API call. Full post-quantum security. Your data never decrypted.
Get API Key Read Documentation
1,000 free authentications. No credit card required.

Related Resources

FHE
What Is Fully Homomorphic Encryption?
FHE
BFV vs CKKS: Choosing the Right FHE Scheme
Performance
FHE Performance Optimization
Deep Dive
NTT Deep Dive: Number Theoretic Transform
Verify It Yourself