Fully homomorphic biometric matching. Templates are encrypted client-side, stored encrypted, and matched in the encrypted domain. 42µs per authentication. The server literally cannot see your face, fingerprint, or voice.
From capture to match decision, your biometric template never exists as plaintext on the server. Every step is cryptographically protected.
Every traditional biometric system has the same fundamental flaw: the server must decrypt your data to match it. That window of exposure is a window of vulnerability.
FHE means the server provably never sees the biometric. There is no plaintext to steal, no decryption window to exploit, and no raw biometric data to regulate — because it never exists on the server.
Encrypted biometric matching at speeds that make plaintext systems look slow. Measured on AWS Graviton4 with 96 workers.
Four endpoints. Encrypt, match, attest. All operating on ciphertexts — the server never touches plaintext biometrics.
# Match an encrypted biometric probe against stored template curl -X POST https://api.h33.ai/v1/fhe/h33-128/biometric-match \ -H "Authorization: Bearer h33_sk_..." \ -H "Content-Type: application/json" \ -d '{ "probe_ciphertext": "<base64-encoded FHE ciphertext>", "template_id": "usr_8f2a...c41b", "threshold": 0.85 }' # Response { "match": true, "confidence": "above_threshold", "latency_us": 48, "batch_id": "batch_a9f3...e712", "plaintext_exposed": false, "fhe_params": { "scheme": "BFV", "n": 4096, "t": 65537, "batch_size": 32 } }
Also available on H33-256 (/v1/fhe/h33-256/*) for NIST Level 5 security.
Not just "encrypted in transit" or "encrypted at rest." Encrypted during computation. Provably.
Any application handling biometric data can eliminate its highest-risk liability with a single API integration.
Your model extracts the embedding. H33 encrypts and matches it. Pre-built adapters for popular open-source models, plus a generic adapter for any model producing float vectors.
21 attack types detected. Liveness checks run before FHE matching — spoofs never waste compute. Challenge-response verification with configurable risk levels.
If liveness fails, the FHE verification is never executed. Zero compute wasted on attack attempts. Configurable risk levels (low/medium/high) control challenge difficulty.
FHE biometrics satisfy the strictest biometric privacy laws by mathematical guarantee, not by policy promise. The server provably cannot access the biometric data it processes.
unenroll() API with Dilithium-signed deletion receipt. H33 as service provider stores only BFV ciphertexts.Every major biometric provider processes your data in plaintext. H33 is the only platform where biometric data is never decrypted at any stage.
| Feature | H33 Biometrics | AWS Rekognition | Azure Face | Jumio | iProov |
|---|---|---|---|---|---|
| Encryption | FHE (never decrypted) | Plaintext processing | Plaintext processing | Plaintext processing | Plaintext processing |
| Template storage | Encrypted (256KB) | Plaintext vectors | Plaintext vectors | Plaintext images | Plaintext |
| Matching method | FHE inner product | Cosine similarity | Cosine similarity | Neural network | Liveness + match |
| Post-quantum | ML-DSA-65 attestation | No | No | No | No |
| ZKP verification | STARK proofs | No | No | No | No |
| Biometric data exposure | Zero (never leaves CT) | Full exposure to AWS | Full exposure to Azure | Full exposure to Jumio | Full exposure |
| BIPA/GDPR compliant | By architecture | Policy-dependent | Policy-dependent | Policy-dependent | Policy-dependent |
| Batch throughput | 32 users/batch (~967µs) | ~200ms/face | ~200ms/face | ~2-5s/check | ~3-8s/check |
| On-premise option | REST API (any infra) | AWS only | Azure only | Cloud only | Cloud only |
Every competitor processes biometric data in plaintext on their servers. H33 performs matching entirely on FHE ciphertexts. The server provably cannot access the biometric data it processes.
POST /v1/biometric/enroll. The encrypted template is stored in NTT form for fast subsequent matching. Enrollment is a one-time operation per user per biometric modality. Templates can be updated by re-enrolling.~1 KB per user. Compare this to plaintext embeddings (512 bytes) and the overhead is roughly 2x per user when batched. For a million users, total encrypted storage is approximately 1 GB. Templates are stored in NTT form for instant matching without preprocessing.POST /v1/biometric/enroll again with the same user ID and a fresh encrypted template. The old template is overwritten. There is no need to decrypt the old template first. For gradual template aging (biometric drift over time), you can implement a rolling update strategy where each successful authentication also refreshes the stored template. Re-enrollment requires client-side biometric capture and encryption.One API call. Zero biometric exposure. Post-quantum secure. Drop-in integration with any biometric pipeline.