Loading... 0%
Email was designed for a different era. Today, it’s a high-risk channel for sensitive information because it creates permanent copies across multiple systems: sender mailbox, recipient mailbox, mail servers, backups, compliance archives, and more.
Even when you “delete” an email, it may still exist in provider backups, corporate journaling systems, or eDiscovery archives. Email also leaks metadata by default: who contacted whom, when, and from where. In short, email is great for convenience, but terrible for confidentiality.
Modern email is broken for privacy because it was not designed as end-to-end encrypted by default. Providers can scan content, index it, and route it through detection engines. Organizations often deploy mail gateways that inspect every message for policy enforcement.
This is not “evil”—it’s how modern email security works—but it means confidentiality is not guaranteed. On top of that, forwarding and screenshots turn sensitive mail into permanent exposure. Even “encrypted email” solutions often rely on server-side keys or portals that the provider can still access.
Wasabi does not try to “fix email.” Instead, it removes email from the trust boundary. Email becomes a notification channel only, not the content channel. The message content is encrypted client-side and stored as an unreadable blob.
The email you send contains a link to retrieve the encrypted blob, not the message itself. The access code is never sent to the server. Without the code, the blob is useless ciphertext. This design sharply reduces the harm of mailbox compromise and provider scanning.
Wasabi uses true client-side end-to-end encryption. The message is encrypted in the sender’s browser before upload. The recipient decrypts in their browser after download.
There is no server-side decryption, no server-side key escrow, and no “portal that can be compelled to decrypt.” If the server database is leaked, attackers get only ciphertext, salt, and nonce—still not enough to decrypt without the unique access code.
Wasabi is built with modern, widely reviewed cryptographic primitives used in high-security systems:
Wasabi is designed so the server never learns your secret. The access code never leaves your device. The derived key never leaves your device. The plaintext never leaves your device.
Wasabi servers store an opaque ciphertext blob and deliver it to the recipient when requested. This keeps the platform aligned with a simple principle: if we don’t have it, we can’t leak it.
Wasabi messages are designed for one-time consumption. After the recipient successfully decrypts, the browser sends a one-time consume proof to the server.
If the proof matches what was stored for that message, the server deletes the ciphertext blob. This reduces long-term exposure. Instead of a permanent email thread living for years, the sensitive content exists only long enough to be delivered and read once.
| The Server Sees | The Server NEVER Sees |
|---|---|
| Encrypted ciphertext blob | Plaintext message |
| Salt and Nonce | Access code or Derived key |
| Message ID | Decrypted content |
| Routing fields (Recipient email) | The identity of the "key" |
Wasabi is built to stay secure even when the environment is hostile:
Wasabi is for situations where email is too risky and permanence is unacceptable:
Wasabi is designed for real workflows: fast compose, fast deliver, and a simple read flow. It fits incident response, executive comms, and legal handoffs perfectly.
It also fits everyday people who simply want private communication without trusting a mail provider’s storage forever. It is built for privacy-first teams who understand that email is for talking, but Wasabi is for secrets.
For auditors and engineers, the process is transparent:
Wasabi is built around guarantees you can actually reason about:
Wasabi uses transparent client-side models. Encryption and decryption run inside the browser, making the workflow inspectable.
Security teams can verify that keys are derived client-side and that plaintext is not transmitted by reviewing network calls. Wasabi avoids proprietary “mystery crypto” and hidden server-side decryption steps.
Traditional “secure email” often still relies on server-side portals or stored keys. Wasabi removes the mail system from the content path entirely.
Email is just the alert; the encrypted content lives as a ciphertext blob that only the access code can open. Fewer moving parts means fewer trust assumptions and fewer permanent copies.
To use Wasabi safely:
Wasabi is hosted at wasabi.rocheston.com.
Compose your message, set an access code, send the link, and let Wasabi handle the rest. No plugins, no complicated key exchange—just secure delivery.
Traditional email is replicated across systems you do not control. It exists in laptop caches, phone apps, smart watches, and cloud backups. Even if you delete it, the forensic footprint often remains in sync logs and backup snapshots.
Wasabi avoids this entire problem. Because the content is never delivered to the mail server, it is never synced into mail apps or indexed by search engines. The encrypted blob is fetched only when needed and deleted once read, dramatically reducing forensic residue.
Because Rocheston does not possess the access code or the derived key, we cannot decrypt your messages. The message is encrypted before it ever reaches us.
If law enforcement or a third party serves a court order, we can only provide what we have: ciphertext and metadata. Without your access code, that data remains unreadable. We don’t have a "master key," because we designed the system so that only you hold the key.
Gmail protects the "pipe" (TLS), but the provider still has access to the stored content for scanning and safety. Wasabi ensures the provider is "blind" to the content from the moment it is created.
iMessage is excellent for E2EE within Apple's ecosystem, but cloud backups can change the exposure risk. Wasabi is built specifically for one-time secret delivery outside of any permanent ecosystem.
Microsoft Purview is a compliance tool that often allows organizational oversight. Wasabi is a zero-knowledge tool where not even the organization or the service provider can see the content.
Gmail’s default model is designed for safety and usability at scale: spam filtering, malware detection, indexing, search, and policy controls. That ecosystem works because messages are processed and stored in a readable form somewhere in the provider stack (even if they are protected in transit). Google’s own documentation focuses on transport encryption (TLS) as the standard protection for email delivery, which is not the same as end-to-end encryption by default.
Gmail Confidential Mode is primarily about restricting sharing actions (for example, no forward/copy/print/download) and adding expiry controls. It is not a guarantee of end-to-end encryption where only endpoints can decrypt. Google’s admin guidance describes these sharing restrictions; it is a control layer, not a cryptographic endpoint-only guarantee.
Google Workspace has been rolling out client-side encryption features branded as “end-to-end encryption” for business workflows, where encryption keys can be controlled by the customer. This is important progress, but it is not the default reality for typical Gmail use, and in some rollouts recipients may be directed through special viewing flows (for example guest access) depending on the recipient environment. If your audience is general Gmail users, it’s safest to assume Gmail is not end-to-end encrypted by default.
Email naturally creates durable artifacts: mailbox copies, device sync caches, retention systems, backups, and activity history. This is why email is valuable in investigations and eDiscovery—because it creates a trail. Forensic writeups specifically discuss Gmail history records and mailbox activity artifacts as sources of investigative evidence.
Wasabi removes email from the content path. The message is encrypted inside the sender’s browser using a key derived from the access code (Argon2id), then encrypted and authenticated (XChaCha20-Poly1305). The server stores only ciphertext plus required transport metadata. The recipient downloads ciphertext and decrypts in the browser using the access code. Email providers and gateways see only a link notification pointing to ciphertext, not the secret itself.
Gmail messages can persist across mailboxes, devices, and retention layers for long periods. Wasabi is designed for one-time retrieval: after a successful read, the ciphertext blob is designed to be deleted, reducing the long-term exposure window. This is the core difference for secrets: Wasabi tries to minimize how long sensitive content exists as stored data in any mailbox-like system.
With Gmail-only messaging, you are trusting the provider and associated scanning/retention ecosystem with message content handling as part of normal operations. With Wasabi, you are trusting your email provider only to deliver a notification link, while confidentiality depends on client-side cryptography and the access code. If a Gmail account is compromised, an attacker may see the link notification, but cannot decrypt the Wasabi ciphertext without the access code.
Use Gmail for everyday communication, collaboration, and discussions that benefit from searchable threads and long-term history. Use Wasabi when permanence is unacceptable: passwords and recovery codes, API keys and SSH keys, private configuration values, incident-response details, legal or HR-sensitive handoffs, partner confidential messages, and any secret you do not want replicated across multiple mailboxes and devices.
People often assume “secure messaging” and “secure email” are the same. They are not. Some systems use true end-to-end encryption (only endpoints can decrypt). Others use encryption in transit and at rest, where the provider can still access readable content during processing or account recovery. Wasabi is designed as a zero-knowledge, client-side encrypted secret delivery system: the server stores ciphertext only and does not hold the access code or derived key.
Wasabi encrypts the message in the sender’s browser before upload and decrypts only in the recipient’s browser after download. The access code never goes to the server. The server stores ciphertext plus required transport metadata. This is the core “zero-knowledge” idea: the service can deliver the message without possessing the key required to decrypt it.
Apple documents that iMessage protects messages and attachments with end-to-end encryption so only the sender and receiver can access the contents. Apple also states it does not store message content or attachments in a readable form on its servers because iMessage content is end-to-end encrypted.
iMessage is end-to-end encrypted in transit between devices, but backups are a separate topic. Apple explains that certain iCloud data categories are always end-to-end encrypted, and Advanced Data Protection (an optional setting) expands end-to-end encryption to additional categories such as iCloud Backup and Messages backup. This matters because cloud backups can change who can access content under account recovery or lawful access scenarios.
Microsoft describes Microsoft 365 encryption as layered protection including encryption in transit and at rest (TLS/SSL, AES, etc.). This is strong protection for enterprise platforms, but it is not the same as automatic end-to-end encryption of email content between endpoints in all cases.
Microsoft Purview Message Encryption (often called OME) is designed to help organizations send encrypted emails inside and outside their org. It improves confidentiality for recipients, but it is typically part of an enterprise security and compliance model rather than a “server knows nothing” zero-knowledge design. In many deployments, encryption and policy enforcement are managed by the organization’s Microsoft 365 environment.
S/MIME is a classic email end-to-end encryption approach where recipients decrypt using certificates. Microsoft provides guidance for configuring S/MIME in Outlook and describes how encrypted mail is opened using available certificates/keystore. This can achieve true end-to-end encryption in email, but it requires certificate management, user setup, and PKI operational overhead.
At a high level: 1. Wasabi (Secret Delivery): client-side encryption + zero-knowledge server storage + one-time retrieval design. 2. Apple iMessage (Messaging): end-to-end encryption for iMessage content within Apple’s ecosystem; backup settings can affect long-term access. 3. Microsoft 365 / Purview (Enterprise Email): strong encryption in transit and at rest plus policy enforcement; can be very secure, but often not “server blind.” 4. S/MIME (Email E2EE): true email end-to-end encryption possible, but complex certificate lifecycle management. If your goal is “send a secret and do not leave it living forever in mailboxes,” Wasabi’s design choice is to keep the secret out of email entirely.
Wasabi is ideal when you want: * no secret content stored in mailboxes * minimal long-term retention of sensitive content * simple user flow without certificates or enterprise setup * strong client-side cryptography with a server that cannot decrypt stored content without the access code Use email encryption (Purview/S/MIME) when: * you must keep content in email systems for business workflows, compliance, or archiving * you need organization-managed controls, DLP, or governance Use iMessage when: * both parties are in the Apple ecosystem and messaging is the right channel.
Keywords: Rocheston Wasabi, end-to-end encrypted messaging, client-side encryption, zero-knowledge messaging, one-time secret sharing, self-destruct messages, XChaCha20-Poly1305, Argon2id RFC 9106, secure message delivery, encrypted message link, confidential email alternative, privacy-first messaging.
Answers to common questions about Rocheston Wasabi, encryption, privacy, and one-time message delivery.
Rocheston Wasabi is a secure message delivery system for sending sensitive information without turning it into a permanent email message. Your secret is encrypted in your browser before upload, stored only as ciphertext on the server, and shared through a link notification. The recipient decrypts in their browser using the access code.
Yes. Encryption happens on the sender’s device (in the browser) and decryption happens on the recipient’s device (in the browser). The server stores only ciphertext and does not perform decryption.
No. The access code is never sent to the server. It is used locally in your browser to derive an encryption key, and that derived key is not uploaded or stored.
The server stores an encrypted ciphertext blob plus the minimum metadata required to deliver and retrieve it, such as the random salt and nonce needed for decryption, a message identifier, and routing fields for notification delivery. It does not store plaintext or your access code.
Wasabi is designed for one-time delivery. After a successful read, the service is designed to delete the stored ciphertext blob. Once deleted, it is not intended to be recoverable through the Wasabi application.
The link only points to encrypted ciphertext. Without the access code, the content is designed to remain unreadable. If you suspect the link was exposed, do not share the access code and send a new Wasabi message with a new access code.
If the access code is weak, guessing becomes easier. Wasabi uses a memory-hard key derivation function to make guessing expensive per attempt, but your strongest defense is choosing a long passphrase. Use unique access codes and avoid short or reused codes.
No. Confidential Mode is a sharing-control feature for email. Wasabi removes the secret from email entirely by encrypting it client-side and storing only ciphertext. With Wasabi, email is only a notification link, not the message content.
No system can fully prevent a recipient from recording what they can see (screenshots, photos, copying text). Wasabi’s goal is to prevent automatic replication and long-term storage in email systems by keeping the secret out of the mailbox and encrypting it end-to-end.
Use long passphrases as access codes. Share the access code out-of-band when needed (call, in-person, separate channel). Use one message per secret. Never reuse the same access code across many messages. Send only to trusted recipients.
Wasabi uses modern, widely reviewed primitives: Argon2id for deriving a strong encryption key from your access code (with a random salt), and XChaCha20-Poly1305 authenticated encryption to protect confidentiality and detect tampering. The design binds encryption context to message identifiers so blobs cannot be swapped without detection.
Wasabi is designed so the server does not have your access code or derived key, and it stores only ciphertext. Without the access code, the server cannot decrypt the stored ciphertext. Under legal compulsion, the server can only provide the encrypted data and associated non-secret metadata it has stored.