Options

Configure your Wasabi preferences and message delivery settings.

Your Identity

Message Settings

Default Expiry

Set the default message self-destruct period

Notify Recipient Immediately

Email the recipient right after the message is stored

Confirm Before Destroy

Show a confirmation step before permanently deleting

Security

Require Access Code

Always require a code to unlock messages

Minimum Code Length

Enforce a minimum access code character count

Frequency & Limits

Send Rate Limit

Maximum messages you can send per 5-minute window

Max Message Size

Maximum encrypted payload the server will accept

Contacts

Recipients are saved automatically when you send a message. Add, edit, or import contacts manually.

No Contacts Yet

Recipients are saved automatically after you send your first message, or add them manually.

End-to-End Encryption

How Wasabi keeps your messages completely private — even from us.

🔒 XChaCha20-Poly1305 🔑 Argon2id KDF 🧹 Zero-Knowledge 💥 Self-Destruct 🚫 No Server Logs

🛡️ How It Works

Wasabi uses true end-to-end encryption. Your message is encrypted entirely in your browser before it ever leaves your device. The Wasabi server stores only an opaque blob of ciphertext — it is mathematically impossible for the server to read your message.

🔐 The Encryption Process

Key Derivation (Argon2id)
Your access code is never sent to the server. Instead, it is combined with a cryptographically random 128-bit salt using Argon2id (RFC 9106) — the gold standard in memory-hard key derivation — to produce a strong 256-bit encryption key, entirely on your device.

Encryption (XChaCha20-Poly1305)
Your message is encrypted with the derived key using XChaCha20-Poly1305 authenticated encryption (AEAD). This simultaneously provides confidentiality and integrity — any tampering is cryptographically detected and rejected before decryption.

What Wasabi Servers See
Only the encrypted ciphertext, a random nonce, a random salt, and the recipient's email address are sent to our servers. We have zero knowledge of your plaintext message or access code. We could not read your message even under legal compulsion.

Decryption & Self-Destruct
When the recipient enters the access code, decryption happens entirely in their browser. A cryptographic "consume proof" (a keyed BLAKE2b hash of the message ID) is then sent to the server, which verifies it matches before permanently deleting the ciphertext. After one read, the message is gone forever — it cannot be recovered.

🚫 What Wasabi Never Sees

• Your plaintext message content
• Your access code or any derived encryption keys
• Message read time or recipient behaviour
• Any decrypted data at any point in the process

🔁 End-to-End Flow

🧑‍💻

Sender's Browser

📝 Plaintext message

🔑 Access code → Argon2id → 256-bit key

🔒 XChaCha20 encrypt

Key never leaves device

Ciphertext only

🖥️

Wasabi Server

🔐 Encrypted blob

🎲 Random salt + nonce

✕ No plaintext

✕ No access code

Ciphertext bundle

👩‍💻

Recipient's Browser

🔑 Access code → Argon2id → key

🔓 XChaCha20 decrypt

📖 Plaintext revealed

💥 Server deletes blob

The server is a blind relay — it stores only ciphertext it mathematically cannot read.

🔬 Open & Auditable

Wasabi uses only well-audited, open-source cryptographic primitives via libsodium. No proprietary algorithms, no secret key escrow. The entire encryption and decryption logic runs client-side and can be inspected in your browser's developer tools at any time.

Hosted at wasabi.rocheston.com

🔑 Argon2id Key Derivation

Inputs

🔑 Access Code + 🎲 128-bit Random Salt

Access code never leaves your device — salt stored alongside the encrypted message

Key Derivation Function

🧮 Argon2id RFC 9106

Memory: 64 MB Iterations: 3 Parallelism: 1 Output: 256 bits

Prohibitively expensive for GPU & ASIC attacks

Resistant to time–memory trade-offs

Output

🔐 256-bit Symmetric Key

Lives in RAM only — never stored, never transmitted

🔐 XChaCha20-Poly1305 AEAD

Inputs

📝 Plaintext 🔑 Key 🎲 Nonce (192-bit) 🏷️ AAD

AAD: "rocheston-wasabi|v1|{message_id}"

AEAD Cipher

🔐 XChaCha20-Poly1305-IETF

XChaCha20 — stream cipher ensuring confidentiality

Poly1305 — MAC tag ensuring message integrity

Any tampering causes authentication failure — decryption rejected

Output

📦 Encrypted Blob

Ciphertext + 16-byte auth tag — base64-encoded, stored on server

♻️ Full Message Lifecycle

①

Sender's Browser

▸Compose message & set access code

▸Argon2id(code, random_salt) → 256-bit key

▸XChaCha20 encrypt(msg, key, nonce)

▸Compute: BLAKE2b(key, "consume|{mid}")

▸POST { ciphertext, salt, nonce, proof } to server

②

Wasabi Server (Blind Relay)

▸Saves encrypted blob & metadata to disk

▸Sends email notification with link — no plaintext

▸At rest: { ct, salt, nonce, proof_hash }

▸Cannot decrypt — has no key, ever

③

Recipient's Browser

▸Opens link, enters access code

▸Argon2id(code, salt) → key (derived locally)

▸XChaCha20 decrypt(ct, key, nonce) → plaintext

▸MAC failure = wrong code — max 5 attempts then lockout

④

Consume & Destroy

▸Browser sends consume_proof to server

▸Server verifies: BLAKE2b(key, "consume|{mid}") == stored_hash

▸Match → DELETE message files permanently

▸Message is irrecoverable — gone forever

🛡️ Threat Model

Threat

Protection

Server compromise

Only unreadable ciphertext stored — no keys, no plaintext

Network interception

TLS + ciphertext — two independent layers of protection

Legal compulsion / subpoena

Zero plaintext or keys to hand over — mathematically impossible

Brute-force access code

Argon2id requires 64 MB RAM per attempt + 5-attempt lockout (24 h)

Replay attack

One-time consume-proof — message deleted on first read

Message tampering

Poly1305 MAC — any tampering causes decryption failure

Long-term data exposure

Self-destruct — permanently deleted after first read

Key compromise after read

Key never stored — derived ephemerally, wiped from RAM after use

📋 Technical Specifications

Encryption

XChaCha20-Poly1305-IETF (AEAD)

Key size

256 bits (32 bytes)

Nonce size

192 bits (24 bytes, random per message)

KDF

Argon2id (RFC 9106)

KDF salt

128 bits (16 bytes, random per message)

KDF memory

65,536 KB (64 MB)

KDF iterations

KDF output

256 bits

Consume proof

BLAKE2b-256 keyed hash (key + "consume|{mid}")

Message ID

160-bit random hex (40 chars)

AAD format

"rocheston-wasabi|v1|{message_id}"

Library

libsodium (WebAssembly)

Runtime

100% client-side browser JavaScript

Storage

JSON files — ciphertext & metadata only

Wasabi

Secure • Private • Self-Destructing

v2.0 • wasabi.rocheston.com

Built with 💛 by Haja Mo

🔒

End-to-End Encrypted

XChaCha20-Poly1305 encryption runs entirely in your browser — zero server knowledge.

💥

Self-Destructing

Messages are permanently and irrecoverably deleted the moment they are read.

🧹

Zero-Knowledge

The server never sees your message content or access code — ever.

🔑

Argon2id KDF

Memory-hard key derivation resistant to GPU and brute-force attacks.

Wasabi is a secure, privacy-first messaging tool.
wasabi.rocheston.com

Rocheston

Wasabi

Wasabi uses true end-to-end encryption. Your message is encrypted entirely in your browser before it ever leaves your device. The server never sees your message or access code. Once read, the message is gone forever.

Profile

Your signed-in identity used when sending messages.

👤

Not Signed In

Sent

Messages you have sent. Message content is always shown as Encrypted — only the recipient can decrypt it.

📤

Sign In Required

Activity

A timeline of your account events.

📊

Sign In Required

Templates

Pre-written message templates. Click Use Template to insert a template into the compose editor.

Loading…

Compose

Sending as: Not signed in — Sign in with Google to send

Recipient Email

Recipient Name (Optional)

Access Code

Access Code Hint (Optional)

Message

😊 😂 ❤️ 👍 🎉 🔥 ✨ 💯 😍 🤔 😎 👏 💪 🙏 ✅ ⭐ 💡 🎯 🚀 💼 📱 💻 📧 🔒