Ready to Experience True Privacy?
Join WIGGWIGG and experience zero-knowledge security firsthand.
Your vault, identity data and contacts are encrypted on your device before they reach our servers. We do not have your password or the plaintext private keys that open that data. For communications protected by our current method, the stored copy is sealed to the account communication key; a small private-beta set remains readable by our servers until a separate re-sealing process.
Zero-knowledge encryption means we have zero knowledge of your password and hold no plaintext private key that opens your vault, identity data or contacts. For communications protected by our current method, we keep no key that can open the sealed copy. It is a scoped promise, not a blanket one: a small private-beta set of communications remains readable by our servers, phone numbers, billing and some optional features are readable to us so the service can run, and picture messages are checked for known illegal material before they are stored.
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
We hold no key to your vault, identities or contacts
A copy of stored server data cannot by itself open your vault, identities or contacts when authentic, untampered client code encrypted them
What we can and cannot see
Your password (plaintext or encrypted)
Your plaintext private encryption keys
Your identity details (names, birthdates, addresses)
Your credentials (credit cards, IDs, licenses)
Your vault, identity data and contacts, which are encrypted on your device
Type anything below. It's encrypted on your device with a key only you hold. Watch what actually reaches our servers.
Key derived here · never sent
All we ever receive
…
We don't have your key; you do. If our servers were breached tomorrow, this is all an attacker would find of your vault: gibberish.
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; the server sends a single-use login challenge along with it.
Your device derives a master encryption key from your password using Argon2id, a memory-hard key derivation function (128 MiB of working memory, 3 iterations). The memory cost is what blocks GPU and ASIC attacks: brute-forcing a single password requires 128 MiB of RAM per guess, not just CPU cycles.
For an account using challenge-response login, your device derives an Ed25519 signing key from your master key (HKDF) and signs the single-use challenge sent by the server. Only someone who knows your password can produce that signature.
For that account, the server stores the public key and verifies the signature. If it checks out, you're in, without the server ever seeing your password. The stored public key cannot be replayed to log in. Some private-beta accounts still retain a static login verifier until a successful sign-in with an up-to-date WIGGWIGG client. If that verifier leaks, someone else could sign in to the account.
Session tokens are stored as HttpOnly cookies so JavaScript cannot read the cookie directly. This limits token theft but does not make injected code harmless.
Traditional authentication sends your password (encrypted in transit) to the server where it's checked. With WIGGWIGG, your password never travels anywhere. For accounts using challenge-response login, the server keeps a public key and receives single-use signatures, not replayable login material. Some private-beta accounts still retain a static login verifier until a successful sign-in with an up-to-date WIGGWIGG client. If that verifier leaks, someone else could sign in to the account, although the verifier does not reveal the password or vault key. A copy of stored server data cannot by itself open your vault, identity data, contacts or communications sealed by our current method when authentic, untampered client code encrypted them. This protection does not cover an active compromise that changes the client code delivered to you. A small set of communications retained from the private beta remains readable by our servers. The You and WIGGWIGG tier, including phone numbers, routing settings and billing, is also readable by our servers because they need it to run your lines.
Argon2id with 128 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
Ed25519 signing key derived from your master key (HKDF)
Single-use server challenge signed on your device
For challenge-response accounts, the server stores the public key and verifies the signature
For those accounts, the stored public key cannot be replayed to log in
Some private-beta accounts still retain a static login verifier until a successful sign-in with an up-to-date WIGGWIGG client. If that verifier leaks, someone else could sign in to the account
AES-256-GCM authenticated encryption
Client-side encryption for vault, identity and contact data
For communications protected by our current method, no server-held key opens the stored content; a small private-beta set remains readable until a separate re-sealing process
Unique IV per operation
Your password derives a master key (Argon2id)
The master key wraps a separate vault key generated per account
Your vault, identity and contact data are encrypted under the vault key, not the master key
Password changes only re-wrap the vault key, never re-encrypt your data
Under our current method, inbound content is sealed to the account communication key, which a supported client opens after sign-in and unlock; some private-beta data still awaits a separate re-sealing process
We never record your conversations
Under our current method, we discard our copy of the sealing key the instant a message is stored
For a sealed message we keep no key that can read it: not at rest, not later, not under a warrant. Named exceptions our servers can read: voicemail while Listen-by-phone is on or when the account has no usable communication key, the other party's number in a call log when the account has no usable key or key lookup fails, the intros your callers record, automatic-reply text, the text and audio of your voicemail greeting, of the announcement we play to you on pickup, and of the prompt your callers hear before they identify themselves, and the personal number you verify for call forwarding. Separately, a message you send passes through us in the clear on its way to the carrier, and we check picture messages against known-illegal-image databases before storing them, keeping the picture when it matches
How we reduce session hijacking, cross-site request and script-injection risks
Multiple security mechanisms work together to protect your authenticated session:
HttpOnly Cookies
Session tokens stored in HttpOnly cookies cannot be read directly by JavaScript, limiting cookie theft through injected code
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
Origin Check
Every state-changing request must pass a strict origin check on top of SameSite cookies, so a foreign site cannot forge it
Session Expiration
Sessions lapse after 30 days of inactivity and are hard-capped at 90 days; you can shorten this to 1 day in Security settings
Encrypted Vault Key
Your vault key (the actual data-encryption key) is held as a non-extractable key handle for the active session (kept across page refreshes unless you choose Maximum Security) and wiped on lock or logout. The master key is wiped right after it unwraps the vault key on login.
Injected JavaScript cannot read an HttpOnly session cookie directly. It may still act within the live page, so HttpOnly is one layer rather than complete protection from script injection.
Attackers cannot trick your browser into making authenticated requests to our API because SameSite cookies plus a strict origin check on every state-changing request 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 key handle for the active session (kept across page refreshes unless you choose Maximum Security)
AES-256-GCM encryption
Automatic expiration
Wiped on lock or logout
Join WIGGWIGG and experience zero-knowledge security firsthand.