Skip to main content

Where Does My Data Go?

It's the first question any security team asks. Qpher gives you three ways to encrypt, and you choose how much your data touches our servers — from never (client-side encryption) to a single stateless API call.

The short answer

Client-side paths: your plaintext never leaves your environment. Server-side mode: Sent to Qpher over TLS, processed in memory, never stored. Your private keys are generated and used only inside Qpher's isolated key service (KMS-Orchestrator) and are never exported.

1. Client-side encryption — your plaintext never leaves your environment​

This is the strongest mode, and the one the Qpher Vault app itself uses.

  1. Call /kem/encapsulate to get a one-time shared secret plus a Kyber768 (ML-KEM-768) ciphertext.
  2. Encrypt your data locally with AES-256-GCM using that shared secret.
  3. Store the AES ciphertext alongside the Kyber768 ciphertext — wherever you like.
  4. To decrypt, call /kem/decapsulate to recover the shared secret, then decrypt locally.

Your plaintext never reaches Qpher. The one-time shared secret does pass through Qpher: its isolated key service creates it on encapsulate and recovers it on decapsulate, and does not store it. Use this for regulated data or anything you simply don't want to transmit.

2. Server-side KEM-DEM — one call, for payloads up to 1 MB​

When you'd rather not implement local crypto, send your plaintext to /kem/encrypt and Qpher does the work:

  • Kyber768 encapsulation → HKDF-SHA256 → AES-256-GCM, all in memory at Qpher — never stored.
  • The shared secret is ephemeral and never stored.
  • Processing is stateless — Qpher retains neither your plaintext nor the ciphertext.
  • Data is processed in the United States, over TLS.

Best for quick integrations and small payloads (the request limit is 1 MB).

3. Key wrap — large files, still client-side​

For large files, encrypt locally with your own AES key, then protect that key with /kem/key/wrap. Your file's plaintext never touches Qpher; the file key does — key/wrap receives it over TLS and wraps it; Qpher does not store it. Unwrap with /kem/key/unwrap, which returns the file key, when you need to decrypt.

At a glance​

ModePlaintext sent to Qpher?Best for
Client-side encryption (encapsulate)NoRegulated / zero-trust data
Server-side KEM-DEM (encrypt)Yes, ≤ 1 MB, never storedQuick integration, small payloads
Key wrap (key/wrap)No (the file key is sent to be wrapped, never stored)Large files

The values that do cross the network — the shared secret, the file key and, in server-side mode, your plaintext — travel inside TLS. See Threat Model → Trust Boundary 3 for what that means against an attacker who records traffic today.

What about my private keys?​

In every mode, your PQC private keys are generated and used only inside Qpher's isolated key service — they are never returned by any API. In the key service's storage, each private key is encrypted by a key held in Google Cloud KMS; Qpher stores only the ciphertext, and the Cloud KMS key never leaves Cloud KMS. Backup copies made before this scheme was introduced in May 2026 are encrypted with AES-256-GCM under a key kept in Google Secret Manager. See Non-Exportable Keys and Encryption at Rest. The Trust Model states what you are trusting Qpher with.

Data residency

All customer data is stored in the United States; there is no EU or other regional data-residency option today.