What you’ll build
A program that:- Generates an FHE keypair locally.
- Uploads the evaluation key to
api.wavis.xyz(40 MB). - Encrypts bits locally and sends ciphertexts to the server.
- Calls
/api/v1/tfhe/gateto evaluateNANDon the server. - Receives the result ciphertext and decrypts locally.
Setup
Full program
What just happened
★ symbol marks the secret key. It exists only on the client.
If api.wavis.xyz is breached, an attacker recovers:
- The evaluation key — useful only for forward operations, not decryption.
- Cached ciphertexts — encrypted under the secret key the attacker doesn’t have.
- API access logs — endpoint timestamps, no plaintext.
False and True never existed on the server. There is
nothing the server could leak.
Production checklist
Before deploying an FHE-blind workload to production, verify:- Secret key storage. Where does the client persist the secret key? KMS, Vault, OS keychain, etc.
- Eval-key reuse. Upload once per long session, not per gate. Eval keys are 40 MB.
- Session cleanup. Always
DELETE /tfhe/session/{id}when done. - Idempotency. Add
Idempotency-Keyheaders to allPOST /tfhe/gatecalls so retries don’t double-charge. - Webhooks for long jobs. Use
/api/v1/webhooksinstead of polling for jobs >5 s. - Budget cap. Set
monthly_cap_usdvia/billing/budgetso a runaway loop can’t drain your account. - Rate-limit handling. Implement exponential backoff on
429(the SDKs do this automatically).
Batched server-side calls
For multiple independent gates, use/tfhe/batch — gets a 30% price discount
for ≥32 ops:
Comparing v1 (server-managed) vs. v2 (FHE-blind)
| Aspect | v1 — /tfhe/session | v2 — /tfhe/eval-session |
|---|---|---|
| Server gets secret key? | Briefly (for keygen) | Never |
| Encryption | Server-side via /encrypt | Client-side (this example) |
| Decryption | Server-side via /decrypt | Client-side (this example) |
| Best for | Demos, quick tests | Production |
Next Steps
GPU Batch
Local GPU acceleration for batched workloads
Webhooks
Async events for long-running jobs