Documentation & security

1. Principles

No traditional vault account: you do not register an email/password with us to unlock the vault. Access depends on what you hold on your device: the master password, an optional wallet for signing and sync, and local storage (browser, extension, or app).

End-to-end encryption (E2EE): vault plaintext is meant to exist only on your device during normal use. Ciphertext is what leaves the device for sync or backup. We do not operate a central database of decrypted vaults.

What stays on the device: derived keys and decrypted vault data while unlocked; cached delegations (see below); import/export files you choose to save locally. Premium or alias flows may involve billing or email identifiers as described in the Privacy Policy—that is separate from vault crypto.

2. Master password & wallet signature

Master password: your secret input to the key-derivation flow. It should be strong and known only to you. We do not receive or store it for vault unlock.

Wallet: proves control of an address via a signature over a fixed message. The signature is combined with the master password in the KDF input for typical payload version 3 vaults (memory-hard Argon2id on the client). The wallet is not a general-purpose encryption oracle: it does not encrypt arbitrary payloads on demand for the server.

Roles: the password supplies entropy you memorize; the wallet ties the vault to an address you control and enables signed operations (e.g. publishing updates). Some clients support a local-only path before a wallet is linked; IPFS sync expects a linked wallet and signed publishes.

Delegations: optional short-lived caching of a signature for unlock or autosave reduces wallet prompts. While active, treat the device as trusted: anyone with access to the unlocked session or malware on the device may abuse those credentials.

3. IPFS & content IDs (CIDs)

The vault blob is encrypted on the client before upload (e.g. AEAD such as XChaCha20-Poly1305 in the core library). IPFS stores and addresses that ciphertext by CID.

Who sees what: gateways and the network can see that a blob exists and can fetch it if they learn the CID. They should not be able to read passwords or notes without your keys. The blob is public in the sense of "reachable if you have the CID"; it is not public in the sense of plaintext exposure.

A separate mapping (e.g. wallet address → latest CID) may exist for convenience; it does not reveal vault contents.

4. Server & APIs

Hosted APIs glue together client workflows without replacing E2EE: for example, accepting an already-encrypted vault payload for pinning or relay, verifying a wallet signature, and recording which CID is current for an address (vault-cid style registries). Exact routes and deployment details may change; this section describes intent, not internal infrastructure secrets.

Other endpoints may serve non-secret metadata (e.g. fragmented-recovery manifests keyed by a hash of a recovery identifier you keep private). Nothing here assumes the server can decrypt your vault.

5. Logs & data

Application layer: sensitive paths are written to avoid logging vault plaintext, master passwords, private keys, or raw signatures.

Honest limits: reverse proxies, hosts, CDNs, and IPFS nodes outside our app code may still emit access or error logs (timestamps, IPs, URLs, HTTP status, sizes). We cannot promise those third-party layers are log-free. Optional "password breach" checks that use k-anonymity send only a hash prefix to a public API, not your full password.

6. Extension & browser

XSS & web surface: extensions interact with untrusted pages. A malicious site cannot read your vault crypto directly from VaultKeepR's isolated storage by normal means, but phishing, fake forms, and UI spoofing remain risks. Prefer confirming fills from the extension UI when a site feels off.

Delegations: as above, cached signatures shorten the signing loop; compromise of the browser profile or extension while unlocked increases blast radius.

Malware: OS-level or browser-level malware can capture keystrokes, screen content, or memory. No password manager can fully defend against a compromised device; keep the OS and browser updated.

7. Import & export

Parsing and transformation run locally in your browser or app. Data does not need to be sent to us in plaintext for import to work.

Supported or common formats include, depending on the client:

• Bitwarden unencrypted JSON export
• Proton Pass JSON
• CSV from major managers (normalized fields)
• 1Password .1pif where implemented
• PGP-wrapped or other wrapped files as offered in-app

Not typically supported in-app: Bitwarden encrypted exports and 1Password .1pux bundles—use unencrypted Bitwarden JSON, CSV, or 1PIF as applicable. Exports you download are as sensitive as the vault; protect them like backup disks.

8. Fragmented recovery (Premium)

Optional Shamir-style splitting lets you define a threshold (e.g. k-of-n): you choose how many shares are required to reconstruct the secret material used in the recovery flow. Shares can be stored on IPFS and/or in other channels you configure in the app.

A recovery ID (separate from your wallet) is a secret identifier you retain; public APIs may reference shares or manifests by a hash of that ID so random callers cannot enumerate your recovery data.

No central reset: we cannot "reset your master password" or decrypt your vault on your behalf. Recovery depends on the shares, the recovery ID, and the parameters you set—not on a support desk backdoor.

Before relying on fragmented recovery for a production vault, do a full dry run with a test vault: distribute shares, confirm the threshold restores access, and verify you can locate the recovery ID—without deleting or overwriting your main vault until you are confident.

Premium also includes features such as TOTP storage and email aliases; see the in-app Premium description.