Process sensitive data without ever decrypting it. The decryption step is eliminated entirely. Data enters encrypted, is processed encrypted, and leaves encrypted. The infrastructure never sees plaintext.
Traditional systems follow a four-step pattern: encrypt data for storage, decrypt it when needed, process the plaintext, then re-encrypt the result. The processing step requires decryption. That decryption creates a window where data exists in plaintext — in memory, in cache, in CPU registers, in log files. That window is where every data breach happens.
H33 eliminates step two. Data is encrypted on the client. It is transmitted encrypted. It is processed while still encrypted. The result is returned encrypted. Only the client holds the decryption key. The server infrastructure — H33 or yours — never has access to plaintext data at any point in the pipeline.
Computing on encrypted data is the running of computation over ciphertext without ever decrypting it. That is the single verb owned by the FHE Platform, and this page is a supporting expression of the FHE Platform, which computes on encrypted data. The FHE schemes that make it work (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 rather than owning them.
This is not a security policy. It is a mathematical guarantee. The FHE scheme makes it computationally infeasible for the server to extract plaintext from ciphertext, even with unlimited access to the processing infrastructure. A compromised server, a malicious admin, a supply-chain attack on the hosting provider — none of these produce plaintext because plaintext never exists on the server.
H33 uses the BFV (Brakerski/Fan-Vercauteren) fully homomorphic encryption scheme. BFV is a lattice-based cryptosystem where encryption produces polynomial ciphertexts. Mathematical operations on these polynomials — addition, multiplication, rotation — produce results that, when decrypted, correspond exactly to the same operations on the original plaintext.
The key insight: the algebraic structure of the ciphertext preserves the algebraic structure of the computation. Adding two ciphertexts produces a ciphertext that decrypts to the sum of the original plaintexts. Multiplying produces the product. This is not approximation. It is exact.
| Parameter | Value | Significance |
|---|---|---|
| Polynomial degree (N) | 4096 |
4096 SIMD slots per ciphertext |
| Ciphertext modulus (Q) | 56-bit |
Single modulus, minimal overhead |
| Plaintext modulus (t) | 65537 |
Enables SIMD batching (t = 1 mod 2N) |
| Security level | H33-128 |
128-bit equivalent, NIST lattice hardness |
| Batch capacity | 32 users/CT |
4096 slots / 128 dims per user |
The security of BFV rests on the Ring Learning with Errors (RLWE) problem — the same lattice-based hardness assumption that underpins NIST's post-quantum standards (FIPS 203, 204). There is no known quantum algorithm that efficiently solves RLWE. The encryption is quantum-resistant by construction, not by add-on.
SIMD batching. Each ciphertext contains 4096 slots. With 128 dimensions per biometric template, one ciphertext holds 32 users. A single FHE operation processes 32 users simultaneously. This is why the per-user cost is 35.25 microseconds despite the batch taking ~1.2 milliseconds.
FHE is not limited to simple operations. H33's BFV engine supports the full set of operations required for real-world privacy-preserving workloads:
The key constraint is multiplicative depth. Each multiplication increases noise in the ciphertext. H33's parameter selection and noise management support the depth required for all the operations above within a single set of parameters. For deeper computations, H33-256 provides additional headroom with a larger parameter set.
Benchmarked on Graviton4 (c8g.metal-48xl). 120-second sustained run. Less than 1% variance.
How H33 compares to alternatives:
H33 achieves this through Montgomery-form NTT with Harvey lazy reduction, NTT-domain persistence that eliminates redundant transforms, pre-computed twiddle factors, batch CBD sampling, and NEON-accelerated Galois operations. Every microsecond is accounted for. The engine is written in Rust with zero external FHE dependencies.
FHE alone processes encrypted data. H33 adds proof, attestation, and threat detection in the same call.
Data processing on ciphertext. Inner products, matching, scoring. Never decrypts.
937 µs / batchOperation correctness proof. Verifiable without accessing the data. Post-quantum secure.
0.059 µs cachedPost-quantum digital signature. Tamper-proof attestation. NIST FIPS 204 compliant.
189 µs / batchHarvest detection, side-channel monitoring, and crypto health validation in real time.
2.35 µs totalEvery API call returns an encrypted result, a ZK proof that the computation was performed correctly, and a Dilithium-signed attestation that the result has not been tampered with. The proof and signature are independently verifiable by any third party — an auditor, a regulator, a counterparty — without accessing the underlying data.
Three paths. All encrypt client-side. All return encrypted results. Integration typically takes under an hour.
<!-- Add to your page --> <script src="https://api.h33.ai/v1/sdk.js"></script> <script> const h33 = new H33({ apiKey: 'your_api_key' }); // Data is encrypted in the browser const result = await h33.verify({ template: biometricData, enrolled: enrolledTemplate }); // result.match: boolean // result.proof: ZK-STARK proof // result.attestation: Dilithium signature </script>
import { H33 } from '@h33/sdk'; const client = new H33({ apiKey: process.env.H33_API_KEY, tier: 'h33-128' }); // Encrypt locally, process on H33, decrypt locally const encrypted = await client.encrypt(sensitiveData); const result = await client.compute(encrypted, operation); const plainResult = await client.decrypt(result); // Verify the proof independently const valid = await client.verifyProof(result.proof);
# Encrypt client-side, send ciphertext curl -X POST https://api.h33.ai/v1/compute \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "ciphertext": "BASE64_ENCRYPTED_DATA", "operation": "inner_product", "enrolled": "BASE64_ENCRYPTED_TEMPLATE", "tier": "h33-128" }' # Response includes encrypted result + proof + attestation # { # "result": "BASE64_ENCRYPTED_RESULT", # "proof": { "type": "stark", "data": "..." }, # "attestation": { "type": "dilithium", "sig": "..." }, # "latency_us": 35.25 # }
FHE runs computation over encrypted data (ciphertext) without decrypting it; the ZK Platform proves a statement is true without revealing the underlying data. FHE computes; ZK proves. FHE does not prove a fact while revealing nothing, and ZK does not compute on ciphertext. Separately, computing does not by itself produce portable evidence: FHE computes on encrypted data, while H33-74 produces the portable, offline-verifiable attestation that a computation happened. Neither owns the other.
It runs computation directly over ciphertext without ever decrypting the underlying data, returning an encrypted result that only the key holder can open.
It does not decrypt your data, and it does not prove a statement while revealing nothing — that is zero-knowledge, a separate primitive.
FHE runs computation over encrypted data (ciphertext) without decrypting it; the ZK Platform proves a statement is true without revealing the underlying data.
FHE computes on encrypted data; H33-74 produces the portable, offline-verifiable evidence that the computation happened. Neither owns the other.
When you must compute on data that must stay encrypted the whole time — not when you only need to prove a fact without revealing it (choose ZK for that).
Not with a policy. Not with a promise. With mathematics. Data encrypted end-to-end. Computation on ciphertext. Proof of correctness. One API call.
1,000 free units/month · No credit card required · Zero plaintext exposure