Your data is encrypted on your device before reaching our servers. We have zero knowledge of your password, encryption keys, or personal information. Even we can't decrypt your data.
Zero-knowledge encryption means we have literally zero knowledge of your password, encryption keys, or decrypted data. Everything is encrypted client-side before reaching our servers.
Instead of sending your password, you use cryptographic signatures to prove you know it without revealing it. Think of it like proving you have a key without showing the key itself.
Password stays on your device, always
Data encrypted client-side before upload
Even we cannot access your encrypted data
Server breach cannot expose your information
What we can and cannot see
Your password (plaintext or encrypted)
Your encryption keys
Your identity details (names, birthdates, addresses)
Your credentials (credit cards, IDs, licenses)
Any decrypted data - everything is encrypted client-side
A cryptographic process that proves your identity without revealing your password
Client requests your unique salt (random bytes) needed to derive encryption keys from your password.
Your device derives a master encryption key from your password using Argon2id, a memory-hard key derivation function (64 MiB of working memory, 3 iterations). The memory cost is what blocks GPU and ASIC attacks: brute-forcing a single password requires gigabytes of RAM per guess, not just CPU cycles.
Your device creates a cryptographic proof using HMAC-SHA256 with your derived key. This proof can only be generated by someone who knows your password.
Server compares your proof hash against the stored hash from registration. If they match, authentication succeeds - all without seeing your password.
Session tokens are stored as HttpOnly cookies, preventing JavaScript access and XSS attacks.
Traditional authentication sends your password (encrypted in transit) to the server where it's checked. If the server is compromised during transmission or storage, passwords are at risk. With zero-knowledge, your password never travels anywhere. Attackers intercepting network traffic or breaching our servers get nothing useful - just cryptographic proof hashes that can't be reversed to reveal your password.
Argon2id with 64 MiB memory cost and 3 iterations
32-byte unique salt per user
Separate keys for auth and encryption
Memory-hard design defeats GPU and ASIC brute-force
HMAC-SHA256 cryptographic proof generation
Zero-knowledge proof verification
SHA-256 hashed proof storage
Timing-safe comparison
AES-256-GCM authenticated encryption
Client-side encryption only
Zero server knowledge of plaintext
Unique IV per operation
Your password derives a master key (Argon2id)
The master key wraps a separate vault key generated per account
All your data is encrypted under the vault key, not the master key
Password changes only re-wrap the vault key, never re-encrypt your data
Inbound SMS, MMS, calls, and voicemail use X25519 elliptic-curve key agreement
Every message generates a fresh ephemeral keypair on the sender side
The ephemeral private key is wiped immediately after sealing
Compromising your private key tomorrow does not decrypt yesterday's messages
How we prevent session hijacking and XSS attacks
Multiple security mechanisms work together to protect your authenticated session:
HttpOnly Cookies
Session tokens stored in HttpOnly cookies cannot be accessed by JavaScript, preventing XSS theft
SameSite Policy
SameSite=Lax prevents cookies from being sent in cross-site requests, blocking CSRF attacks
Secure Flag
Cookies only transmitted over HTTPS, preventing man-in-the-middle interception
CSRF Tokens
State-changing operations require CSRF tokens that cannot be forged by attackers
Session Expiration
Sessions automatically expire after 24 hours, limiting window of compromise
Encrypted Vault Key
Your in-memory vault key (the actual data-encryption key) is held as a non-extractable handle and wiped on logout. The master key is wiped right after it unwraps the vault key on login.
Even if an attacker injects malicious JavaScript into your browser, they cannot access your session tokens because HttpOnly cookies are not exposed to JavaScript.
Attackers cannot trick your browser into making authenticated requests to our API because SameSite cookies and CSRF tokens block cross-site requests.
Multiple layers of protection mean that if one security mechanism fails, others are still in place to protect your session.
HttpOnly flag prevents JavaScript access
Secure flag enforces HTTPS
SameSite=Lax blocks cross-site requests
Explicit domain scoping
Vault key held as a non-extractable WebCrypto handle in memory
AES-256-GCM encryption
Automatic expiration
Secure memory cleanup on logout
Join WIGGWIGG and experience zero-knowledge security firsthand.