Skip to content
PulsVaultDocs
Get started
PersonalPremiumFamilyTeamBusinessEnterprise

Security invariants

The absolute constraints of PulsVault's zero-knowledge design — ten hard guarantees that hold across every feature, plan, and release.

These are the hard guarantees of the product — absolute constraints of the zero-knowledge design that every feature is built and tested against. They are not configuration defaults or best-effort policies: a change that would violate any of them is rejected by design review and by invariant assertions in the test suite.

The invariants#

Must never be violated
  1. Raw UMK, DEK, and PDS never reach the server. Only their encrypted forms — the wrapped master key and wrapped vault DEKs — are ever stored.
  2. The primary vault is always AES-256-GCM, regardless of any organization encryption policy, and it is never shareable.
  3. A password change only re-wraps the UMK. It never triggers re-encryption of vault items.
  4. The Access Key is unrecoverable by design. Your browser generates it and the server never sees it — only a BCrypt hash of a one-way verifier is stored; if lost, recovery requires the Recovery Key.
  5. Signup blocks until the primary vault DEK is initialized. The client must store the wrapped DEK before registration is considered complete — no user enters the app with an uninitialized primary vault.
  6. A secure link's symmetric key lives only in the URL fragment (#key=…). The HTTP specification guarantees fragments never reach the server.
  7. DEK rotation happens client-side. When shared access is revoked, the owner's device re-encrypts items under a new DEK — the server cannot do this because it holds no keys.
  8. OWNER is never assignable via sharing. The maximum access level a share can grant is EDITOR.
  9. Every AES-GCM encryption uses a unique 12-byte IV. IVs are never reused under the same key.
  10. The server never sees the Access Key or the Recovery Key. Your browser generates both at signup, shows them once, and sends only one-way verifiers; the server stores hashes of those and cannot re-display either key.

Architectural decisions that back them#

The invariants are upheld by a handful of deliberate design choices rather than ad-hoc checks:

Decision Why it protects the invariants
Two-gate session model Vault data is inaccessible without a vault session, even with a valid login JWT (invariant 1)
Per-vault DEK, not per-item One decrypt per vault open, while separate vaults keep independent keys (1, 7)
Sharing by key re-wrapping, not re-encryption The DEK is wrapped per recipient with RSA-2048-OAEP; items are never re-encrypted for a share (1, 8)
Server as opaque blob store Encrypted fields are stored and returned verbatim — the backend has no decrypt path to misuse (1)
Hash-chained audit ledger Entries form a linked chain with HMAC signatures; rows cannot be inserted outside the audit service (see Audit log)

What this means in practice#

  • Support staff cannot read your secrets, reset your vault contents, or bypass the Emergency Kit — there is nothing on the server to decrypt with.
  • Losing both your master password and your Emergency Kit means the data is gone. This is the deliberate price of invariant 1 and 4.
  • Compliance reviewers can verify invariant 9 and the envelope format directly in stored ciphertext, and chain integrity via the audit verification endpoint.
Was this page helpful?