Qpher trust model: policy-enforced
Keys stay in an isolated key service, client-side paths never expose plaintext to Qpher, and Qpher is not zero-knowledge — here is why.
This page is for security engineers and architects reviewing Qpher. It states where your data goes, what Qpher can see and what you are trusting Qpher with, so that a security review does not have to discover it later.
In short
- Qpher is not zero-knowledge. Private keys stay in an isolated key service; on client-side paths (Vault, Organization send, .qpher) Qpher never sees the plaintext; the API's server-side mode receives plaintext over TLS, processes it in memory and does not store it.
- Private keys are generated and used only inside Qpher's isolated key service. No API can export them.
- Qpher's policy decides who may download a document and its wrapped key — the owner and recipients of shares that have not been revoked — and the key service recovers the key for an account that holds the wrapped key under the matching keys. That is policy; it does not make access mathematically impossible for Qpher.
What Qpher is for
If your data is encrypted at rest with AES-256 in your own cloud, that layer is already quantum-safe. You need Qpher when the data has to leave — to a client, a counsel, a family member.
Qpher keeps your documents under your rules after they leave your hands: Qpher Vault, Qpher Legacy and Qpher API share one engine.
An attacker who records encrypted data today can decrypt it later if a quantum computer breaks the RSA or elliptic-curve key exchange or key wrapping that protected it ("harvest now, decrypt later"). Qpher wraps document keys with ML-KEM and signs with ML-DSA, so what Qpher stores does not depend on RSA or elliptic curves alone; values that cross the network depend on the connection's key exchange (What crosses the network).
Where your data goes
Client-side paths — Qpher Vault, and the API's encapsulate and key wrap
| Reaches Qpher? | Stored by Qpher? | |
|---|---|---|
| Document plaintext | No | No |
The one-time shared secret (encapsulate / decapsulate, and Qpher Vault) | Yes — created or recovered by the key service and returned over TLS | No |
A file key you send to key/wrap, or get back from key/unwrap | Yes, over TLS | No |
| The wrapped file key and the encrypted document | API: no — you keep them. Qpher Vault: uploaded to storage in the United States | API: no. Qpher Vault: yes, encrypted |
| A SHA-256 hash of the document's contents | Qpher Vault: yes | Qpher Vault: yes |
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. With key/wrap, your file key is sent to Qpher over TLS and wrapped; Qpher does not store it.
Server-side mode — /kem/encrypt and /kem/decrypt
Server-side mode. Sent to Qpher over TLS, processed in memory, never stored.
Re-wrapping for another account, and .qpher copies
When a Qpher Vault document is shared with someone whose account uses different keys — another organization, or another
personal account — or exported as a .qpher file, Qpher's service recovers the document's file key with the keys of the
owner's account or organization and wraps it for the recipient. Importing a .qpher file re-wraps it again, and a share
to someone who has no account yet is completed the same way when they sign up. The unwrapped key exists only in memory
during that step and is not stored. Members of an organization share inside it with no key re-wrap; admins manage members in Qpher Portal.
What crosses the network
Values that cross the connection to Qpher — your API key, your plaintext in server-side mode, the shared secret returned
by encapsulate and decapsulate, and the file key you send to key/wrap or get back from key/unwrap — are protected
in transit by TLS alone; Qpher Vault's connection carries the shared secret the same way. api.qpher.ai and
api.vault.qpher.ai negotiate the hybrid post-quantum key exchange X25519MLKEM768 with clients that offer it. Against an
attacker who records traffic today, these values are only as safe as the key exchange the client negotiates. Calls between Qpher services also go over HTTPS and are authenticated with a Google-signed identity token checked by Cloud Run, a Qpher service token, or both.
What Qpher can see
- Operations. Cryptographic operations (when they succeed), key management, Qpher Portal sign-ins and the administrative events listed in Audit Logging are recorded in your organization's audit log: which operation, when and the result — not the data. An entry names a user only for actions taken in Qpher Portal; requests made with an API key, and key operations for Qpher Vault, are recorded without one. Each organization's entries form a SHA-256 hash chain; Qpher Vault's per-document access log is separate and is not part of it.
- Qpher Vault metadata. File and folder names, file types, sizes, a SHA-256 hash of each document's contents and who a document is shared with are stored on Qpher's servers. The hash lets whoever holds it check whether a document matches a file they already have. Qpher Legacy encrypts file and folder names on the device; Qpher Vault does not yet. "Qpher never sees the plaintext" refers to document contents only.
Algorithms
| Purpose | Algorithm | Standard |
|---|---|---|
| Key encapsulation | ML-KEM-768, ML-KEM-1024 | NIST FIPS 203 |
| Signatures | ML-DSA-65, ML-DSA-87 | NIST FIPS 204 |
| Hash-based signatures | SLH-DSA | NIST FIPS 205 |
| Symmetric encryption | AES-256-GCM | NIST SP 800-38D |
| Key derivation | HKDF-SHA256 | RFC 5869 |
Qpher offers post-quantum-only and hybrid modes. A hybrid mode pairs a post-quantum algorithm with a classical one, so breaking either one alone is not enough: X-Wing (X25519 + ML-KEM-768), based on an IETF CFRG draft, for key encapsulation, and a composite ECDSA P-256 + ML-DSA-65 signature, based on an IETF LAMPS draft with Qpher's own encoding (verified through Qpher). Qpher Vault wraps each new document key with X-Wing and signs with the composite signature by default. On paid plans, Qpher Vault's signing sheet also offers SLH-DSA and a composite ML-DSA-65 + SLH-DSA-192s signature.
Qpher's post-quantum operations run on liboqs, the Open Quantum Safe project's open-source C library. Validation and audits: see What Qpher does not claim.
Private key custody
- The isolated key service is the KMS-Orchestrator, a separate service; the database stores a handle to each key, never the key bytes.
- In the key service's storage, each private key is encrypted with AES-256-GCM by a key held in Google Cloud KMS (envelope encryption); 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.
- To store a private key, the KMS-Orchestrator sends it to Cloud KMS over TLS and writes the ciphertext it gets back; to use the key, it sends the envelope to Cloud KMS, which returns the private key.
- Encrypt and sign may omit key_version: Qpher uses the active key and returns its version. Decrypt, verify, encapsulate and key wrap always need it.
- Keys move through active → retired → archived. Archiving a key in Qpher Portal deletes its private key file; encrypted copies of that file can remain in our backups. Qpher refuses every operation with an archived key.
- Deleting an account does not yet destroy its PQC private keys; they stay encrypted in the key service.
Who can open a document
Requests to the Qpher API pass a dedicated policy engine before they reach the target service. Requests from the Qpher Vault app are authorized by the Vault service itself.
- The owner, recipients of a share that has not been revoked, and — through an organization's keys — its members, its Qpher Portal users and whoever holds its API key. Which member may download which document is a policy decision, not a separate key.
- Revoke the share and the recipient can no longer open it in Qpher Vault. A copy they already saved stays with them. Share expiry dates are not enforced yet, and after the date the Qpher Vault app hides Revoke — see Share Documents.
- View-only is enforced by the Qpher Vault app, not by cryptography: anyone who can open a document can capture its contents.
- Documents signed inside an organization are signed with the organization's key; the document and its access log record which member signed. If a member joins or leaves the organization after signing, verifying through Qpher may fail. Verifying through Qpher needs the signing key to be active or retired.
- A
.qpherfile moves without Qpher, but opening it always needs Qpher: offline transfer, online decrypt. It is bound to the recipient's keys — for a member of an organization, the organization's — so any member of that organization can import it. Qpher Vault cannot revoke a.qpherfile after you send it.
What Qpher does not claim
- Qpher is not zero-knowledge. The key service holds the private keys. On the API's client-side paths Qpher never receives your encrypted data, so a compromised or legally compelled Qpher could observe a shared secret or file key at the moment of use. Qpher Vault also stores each encrypted document with its wrapped file key, and Qpher's service recovers file keys on its own when it re-wraps a share — including when a recipient signs up — so a compromised or legally compelled Qpher could decrypt stored Qpher Vault documents. Qpher keeps shared secrets and unwrapped file keys in memory only and does not store them; it does not claim that access is mathematically impossible.
- The API's server-side mode exposes plaintext to Qpher in memory, for the length of the request.
- Standards are not audits. Qpher implements NIST FIPS 203, 204 and 205. Our cryptographic module has not been validated by NIST's CMVP, and no SOC 2 audit has been completed.
- Transport is TLS. See What crosses the network.
- No provider-proof option. Qpher does not offer client-held private keys or hardware-attested key isolation today. If your requirement is that the provider must be unable to access your data at all, Qpher is not the right tool.
Compliance and data handling
- All customer data is stored in the United States; there is no EU or other regional data-residency option today.
- Qpher's Privacy Policy describes the personal data we process, our role under the EU General Data Protection Regulation (GDPR) and how to exercise your rights; our Data Processing Agreement is public for every customer. Sub-processor data locations are documented in the Data Processing Agreement.
- Audit logs are retained for the life of your account and for 24 months after the account is deleted; accounts with an armed Legacy policy are exempt from deletion while the policy is armed.
- What deleting an account removes: Compliance & Standards.
- The Trust Center covers security, compliance, data handling and incident response.
Choosing a path
| If you need… | Use | Qpher sees the plaintext? |
|---|---|---|
| Documents you send outside your organization | Qpher Vault | No |
| Encryption inside your own systems, with plaintext kept local | API client-side: encapsulate / decapsulate, or key/wrap / key/unwrap | No |
| One API call, with Qpher in the data path | API server-side: /kem/encrypt / /kem/decrypt | In memory, never stored |
| A provider that cannot access your data at all | Keys you hold yourself | Qpher is not the right tool |
Questions about this trust model: security@qpher.ai.