Zero Knowledge Architecture: How VaultKeepR Keeps Your Data Private

The Trust Problem in Password Management

Client-side encryption is common among password managers. For example, LastPass documents local vault encryption and decryption, rather than routine server-side decryption. VaultKeepR's differences concern identity, storage, recovery and their trust boundaries.

This article focuses on separating confidentiality from availability. A service can store only ciphertext and still affect whether you can retrieve it. Stolen ciphertext also remains subject to offline guessing, especially when the unlocking secret is weak.

How Zero Knowledge Architecture Works

Zero knowledge means the server knows nothing about your data content. Three components make this possible:

Client-Side Encryption: Your data gets encrypted on your device before leaving it. The server only sees encrypted blobs.

Key Derivation: Encryption keys derive from your master password using functions like Argon2id. The server never receives these keys.

Encrypted Transport: All communication uses TLS, but the payload is already encrypted before transmission.

User Device                    Server
┌─────────────┐               ┌──────────────┐
│ Raw Data    │               │              │
│     ↓       │               │              │
│ Encrypt     │──── TLS ─────▶│ Store Blob   │
│ (local key) │               │              │
└─────────────┘               └──────────────┘

VaultKeepR's Zero Knowledge Implementation

VaultKeepR builds zero knowledge architecture on three layers:

Layer 1: Client-Side Encryption

XChaCha20-Poly1305 encrypts your vault locally. Your master password feeds into Argon2id key derivation with a random salt. This produces the encryption key that never leaves your device.

const salt = crypto.getRandomValues(new Uint8Array(32));
const key = await argon2id(masterPassword, salt, {
  memory: 65536,
  iterations: 3,
  parallelism: 4
});

const encryptedVault = await xchacha20poly1305.encrypt(
  vaultData, 
  key
);

Layer 2: Shamir Secret Sharing Recovery

VaultKeepR Premium uses Shamir 3-of-5 recovery for the vault encryption key. The five configured channels are the device, remote storage, a trusted contact or QR handoff, a smart contract, and the API. Any three valid fragments can reconstruct the key; losing too many fragments or the recovery identifier can prevent recovery. See the current SDK defaults, channel distribution, and recovery guide. This recovers a vault key, not a hardware passkey or each seed phrase stored in the vault.

Layer 3: IPFS Distribution

The client encrypts vault snapshots before upload. Storage can involve IPFS gateways, pinning services, hosted APIs and S3-compatible backends. These services handle ciphertext, while timing, size, CIDs and on-chain activity may remain observable. IPFS content addressing does not guarantee persistence: retain an independent encrypted backup and test retrieval. The sync documentation and threat model describe those dependencies.

Real-World Security Benefits

Storage services are not intended to hold the keys needed to read a vault. A copied encrypted snapshot therefore does not automatically become readable. However, endpoint compromise, a malicious client or weak password-derived secrets remain relevant. Metadata may be observable.

Legal requests and storage outages can still affect ciphertext or records. The threat model documents those limits; encryption does not place infrastructure outside legal or operational control.

Performance Trade-offs

Zero knowledge architecture comes with costs:

Initial Sync Time: First-time vault downloads require decryption on your device, which takes longer than server-side processing.

Computational Overhead: Key derivation and encryption/decryption happen locally, consuming battery and CPU cycles.

Recovery Complexity: Shamir Secret Sharing recovery requires more steps than simple password resets.

VaultKeepR optimizes these trade-offs through efficient algorithms and progressive sync strategies.

Implementation in Modern Browsers

WebCrypto API makes zero knowledge architecture feasible in browsers:

// Generate vault encryption key
const keyMaterial = await window.crypto.subtle.importKey(
  'raw',
  derivedKey,
  { name: 'HKDF' },
  false,
  ['deriveKey']
);

const vaultKey = await window.crypto.subtle.deriveKey(
  {
    name: 'HKDF',
    info: new TextEncoder().encode('vault-encryption'),
    salt: vaultSalt,
    hash: 'SHA-256'
  },
  keyMaterial,
  { name: 'AES-GCM', length: 256 },
  false,
  ['encrypt', 'decrypt']
);

This runs natively in browsers without plugins or extensions.

Building Your Own Zero Knowledge System

If you're implementing zero knowledge architecture:

1. Choose Strong Primitives: Use Argon2id for key derivation, XChaCha20-Poly1305 or AES-GCM for encryption
2. Salt Everything: Random salts prevent rainbow table attacks on password hashes
3. Audit Cryptographic Code: Have security experts review your implementation
4. Test Recovery Flows: Ensure users can actually recover their data when things go wrong
5. Document Threat Models: Be explicit about what attacks your system prevents and which it doesn't

The Future of Zero Knowledge

Zero knowledge proofs will expand beyond simple encryption. ZK-SNARKs and ZK-STARKs enable proving knowledge without revealing information. This could allow password managers to verify login attempts without exposing credentials.

Homomorphic encryption might enable server-side operations on encrypted data, combining zero knowledge privacy with cloud computing convenience.

Start Using Zero Knowledge Today

The public clients are the Chrome and Firefox extensions and the iOS and Android apps, available from Download. Creating a vault does not require an email address or an external wallet such as MetaMask. The passkey and smart-account flow is described in the passkey documentation; available unlock methods depend on the client and authenticator.

Test recovery and maintain an independent encrypted backup before relying on any design for critical credentials.