Skip to main content
WAVIS is built on the principle that the server should never see plaintext — not even momentarily, not even for “necessary computation.” This page explains how that guarantee is achieved cryptographically and operationally.

​
The threat model

WAVIS protects against three classes of adversary:
  1. Honest-but-curious server. The cloud operator is following the protocol correctly but reads logs, snapshots, and process memory. WAVIS guarantees the operator learns nothing about plaintext.
  2. Compromised server. An attacker has root on the WAVIS API server. They can read every byte of every ciphertext, every key in storage, and every request body. WAVIS still guarantees plaintext confidentiality.
  3. Subpoena / legal compulsion. A court orders WAVIS to disclose customer data. WAVIS literally cannot comply — there is no plaintext to hand over.

​
Cryptographic guarantees

WAVIS uses TFHE (Torus Fully Homomorphic Encryption) and CKKS (Cheon-Kim-Kim-Song approximate FHE), both based on the RLWE (Ring Learning With Errors) hardness assumption. 128-bit security means an attacker must perform on the order of 2¹²⁸ ≈ 3.4 × 10³⁸ operations to recover plaintext from ciphertext — beyond the reach of any current or projected adversary, including state-level quantum computers (TFHE/CKKS are post-quantum secure).

​
The three keys

┌─────────────────────────┬──────────────┬────────────────────────────────┐
│ Key                     │ Where it lives│ What it does                   │
├─────────────────────────┼──────────────┼────────────────────────────────┤
│ Secret key (sk)         │ Client only  │ Decrypts ciphertexts           │
│ Public key (pk)         │ Anywhere     │ Encrypts plaintext             │
│ Evaluation key (ek)     │ Server       │ Bootstraps gates on ciphertext │
└─────────────────────────┴──────────────┴────────────────────────────────┘
The secret key never leaves the client. The evaluation key is safe to share publicly — under the RLWE assumption, it is computationally indistinguishable from random.

​
What the server stores

For every active session, the WAVIS API server holds:
  • The evaluation key (~40 MB for standard_128).
  • Ciphertexts the client uploaded (~2 KB each for TLWE, larger for RLWE).
  • Operation metadata (which gate, which session ID, which timestamp).
It does not store, log, or have access to:
  • The secret key.
  • Any plaintext bit, ever.
  • The mapping between ciphertext bits and your data semantics.

​
What POST /api/v1/decrypt returns

501 Not Implemented. By design. The endpoint exists in the OpenAPI spec to make this guarantee unambiguous — the server cannot decrypt because it does not have the secret key. 
curl -X POST https://api.wavis.xyz/api/v1/decrypt \
  -H "Authorization: Bearer wvs_live_..."
# HTTP/1.1 501 Not Implemented
# {"error": "Server cannot decrypt — by design. Decrypt locally with your secret key."}
WAVIS supports two session models. The default and recommended model is FHE-Blind: the client generates the keys and uploads only the evaluation key. 
import wavis_fhe as wv
import requests, base64

# CLIENT — secret key stays here forever
keys = wv.keygen("standard_128")
ek_bytes = keys.eval_key_bytes()

# Upload ONLY the evaluation key
resp = requests.post(
    "https://api.wavis.xyz/api/v1/tfhe/eval-session",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={"eval_key_b64": base64.b64encode(ek_bytes).decode()}
)
session_id = resp.json()["session_id"]
# session is now blind: server has no relation to the secret key
The response confirms blind mode: 
{
  "session_id": "sess_...",
  "preset": "standard_128",
  "is_blind": true
}

​
Network & transport security

  • TLS 1.3 only. TLS 1.2 and below are rejected at the load balancer.
  • HSTS with max-age=63072000 (2 years), preload-eligible.
  • Certificate pinning is supported in both SDKs (optional).
  • No data in URL params. All ciphertexts are POST’d in the request body.
Even if TLS were broken, an attacker on the wire would see only ciphertexts — the same protection as the at-rest model.

​
Operational controls

  • Per-account isolation. Sessions are scoped to the issuing API key. There is no cross-tenant access.
  • Ciphertext eviction. The server’s ciphertext cache uses LRU eviction. Old ciphertexts are deleted on memory pressure (you’ll see them listed in evicted_ciphertext_ids in compute responses — re-upload if needed).
  • Session TTL. Sessions expire after 1 hour by default. Evaluation keys and cached ciphertexts are zeroed on expiry.
  • Audit logs. Every API call is logged with timestamp, account ID, endpoint, and outcome — never with ciphertext bytes or plaintext (which doesn’t exist on the server anyway).

​
Side-channel resistance

The Rust FHE core is built with the following side-channel mitigations:
  • Constant-time comparisons for all secret-dependent branches.
  • No data-dependent memory access in core bootstrapping loops.
  • Modulus switching rounds with rejection sampling to avoid bias-leak.
  • Zeroization on drop for all secret-key material.
Side-channel attacks targeting WAVIS would need to recover the secret key, which lives only on the client. The server has nothing leakable beyond the evaluation key (publicly disclosable by design).

​
Compliance posture

WAVIS is designed to map cleanly to regulatory frameworks:
FrameworkHow WAVIS satisfies it
HIPAAPHI never leaves client perimeter in plaintext form. WAVIS API is not a HIPAA business associate — it never touches PHI.
GDPR Art. 32”State of the art encryption” requirement met via 128-bit RLWE. Server-side breach yields zero personal data.
SOC 2 Type IIAvailable for Enterprise tier. Audit logs, access controls, and incident response procedures documented.
CCPARight to deletion satisfied trivially — no plaintext exists to delete.
Enterprise customers receive a compliance pack on request: contact legal@wavis.xyz.

​
What WAVIS does NOT protect

Be honest with yourself about what FHE does and doesn’t solve:
  • Metadata. WAVIS sees that you sent N gates of type NAND at time T. If the access pattern itself leaks information, you may need oblivious RAM on top of FHE.
  • Output integrity. A malicious server could return garbage instead of the correct gate result. WAVIS does not currently include verifiable computation (zk-SNARKs over FHE) — on the roadmap for 2027.
  • Client-side compromise. If your machine is rooted, the attacker has the secret key. FHE protects against server compromise, not client compromise.

​
Reporting vulnerabilities

We take security reports seriously and respond within 24 hours. 📧 security@wavis.xyz (PGP key on request) Coordinated disclosure: 90 days standard. Bounty program for verified findings — see wavis.xyz/security.

​
Next Steps

Key Management

FHE key lifecycle: generation, rotation, deletion

Performance

Security parameters and their performance trade-offs