What zero-knowledge means

In a zero-knowledge architecture, the service provider — QuantPass — never has access to your plaintext data. Your encryption keys are generated on your device and never transmitted. Vault contents are encrypted before they leave your device. QuantPass's servers store only ciphertext: encrypted blobs that are mathematically unreadable without the keys that only you hold.
This is distinct from "encrypted in transit and at rest," which most cloud services offer. In that model, the provider decrypts your data on their servers to process it, even if that decryption is brief. In a zero-knowledge model, the provider never decrypts your data at all — they cannot, because they never have the keys.

How QuantPass implements zero-knowledge

Key generation — When you register a QuantPass identity for a site, a Dilithium2 (ML-DSA-44) keypair is generated client-side: in the browser extension's WebAssembly runtime, or on the mobile device. The private key never leaves the device.
Vault encryption — When a credential is saved, it is encrypted client-side using a key derived from ML-KEM-1024 key encapsulation before the encrypted blob is transmitted to QuantPass's servers. The server receives ciphertext only.
Authentication — When you sign in to a site, QuantPass authenticates you with a Dilithium2 signature: a cryptographic proof that you hold the private key, without revealing the private key itself. The server verifies the signature against the public key registered at enrollment. No password, no private key, and no plaintext credential is transmitted during authentication.
What QuantPass's servers hold — Public keys (by design — these are not secret), encrypted vault blobs, and audit log metadata. No plaintext passwords, no private keys, no decryption capability.

What zero-knowledge protects against

Server-side breach — If QuantPass's servers are compromised, an attacker gains access to encrypted vault blobs and public keys. Without the private keys — which exist only on user devices — the vault contents are unrecoverable. This is fundamentally different from a breach of a traditional password manager where the server holds decryption capability.
Insider threat — No QuantPass employee can access your vault contents. The architecture makes it technically impossible, not just policy-prohibited.
Subpoena and legal compulsion — QuantPass cannot produce your plaintext credentials in response to a legal demand because QuantPass does not have them. We can produce encrypted blobs, public keys, and metadata — not plaintext.
Man-in-the-middle attacks — Because authentication uses post-quantum digital signatures rather than password transmission, intercepting a QuantPass authentication session yields only a one-time signature over a server-issued challenge. Replaying it is impossible; extracting the private key from it is computationally infeasible.

The trust model

Zero-knowledge does not mean you trust nothing. It means the trust boundary is correctly placed. You trust:
  • Your own device (the device holds the private key)
  • The QuantPass client code (the code that runs the cryptography — auditable, open to review)
  • The mathematical hardness of ML-KEM-1024 and ML-DSA-44 (NIST-standardized, publicly reviewed)
You do not need to trust:
  • QuantPass's server infrastructure
  • QuantPass's employees
  • QuantPass's legal and compliance posture
  • Any third party with access to QuantPass's systems
This trust model is materially stronger than traditional password managers, where the security of your vault depends on the security of the vendor's server infrastructure, the integrity of their employees, and their response to legal demands.

Zero-knowledge and enterprise features

A common concern with zero-knowledge architectures is that they conflict with enterprise requirements like admin access, account recovery, and audit logging. QuantPass resolves this without compromising the zero-knowledge property:
Admin access — Enterprise admins manage policies, provisioning, and access control through the admin console. They do not have access to vault contents. Policy enforcement (e.g. requiring FIDO2 hardware unlock) is applied at the authentication layer, not by decrypting vault contents.
Account recovery — Recovery is device-based. Enterprise accounts can be configured with recovery keys that allow re-enrollment from a new device without exposing vault contents to QuantPass's servers.
Audit logging — Every authentication event generates a PQC-signed audit log entry that records who authenticated, when, from where, and with what cryptographic scheme. These logs are available for SIEM integration and SOC 2 compliance without requiring access to vault contents.