🔬 How BareSend Works – Deep Dive

BareSend is a client-side, zero-knowledge secure messaging service designed with simplicity, anonymity, and self-destruction at its core. Here’s an advanced, nerd-level breakdown of how it all works under the hood.

📡 Message Lifecycle (ASCII Edition)

	📨 Message Created:    ─────●──────────────────────────────
	⌛ Expiry Countdown:         ─────────────● (e.g. 6h later)
	🧠 User Decrypts:                   ●
	💣 Self-destruct Trigger:             ● (60s after decrypt)
	🧼 Message Deleted:                   ✖︎

	Legend:
	● = Event
	✖︎ = Permanent deletion (server-side)

1. Message Encryption (Client-Side)

When you type your message into the BareSend web interface and provide an encryption key (password), encryption happens entirely in your browser using the AES-256-GCM algorithm.

The key is processed through PBKDF2 (Password-Based Key Derivation Function 2) with a random salt and 250,000 iterations to derive a secure encryption key.
This derived key is then used to encrypt the message content via AES-GCM, which provides both confidentiality and integrity (authenticated encryption).
The final encrypted payload includes: ciphertext, salt, IV (initialization vector), and GCM auth tag – all base64-encoded and bundled into the message blob.

2. Storage on Server

The encrypted message blob is sent via HTTPS POST to the BareSend backend. At no point does the server receive or log the decryption key. It only stores the encrypted blob, along with:

A timestamp for creation and expiration
A unique ID for lookup (e.g., /view/abcd1234)
An internal access counter to track if it has been read

No user information, metadata, or IP address is stored with the message.

3. Key Transmission Philosophy

BareSend does not include the encryption key in the message URL. The philosophy is: separate the payload from the key. You send the encrypted message link via one channel (e.g., email) and the key via another (e.g., Signal, voice, or a wink across the room).

4. Message Access and Self-Destruction

When a recipient opens a BareSend link (e.g., /view/abcd1234), they see an input field asking for the key. If the correct key is entered:

The ciphertext is decrypted client-side using the AES-GCM and the reconstructed key (from the provided password + stored salt)
If decryption is successful, the server records a read timestamp
From that moment, any future access to the message after 60 seconds will result in the message being deleted by the server — even if the browser was left idle, closed, or refreshed

This guarantees that the 60-second self-destruct window is enforced on the server side, not just the browser. The server always has the final say.

5. Expiration and Security

When creating a message, you define its maximum time-to-live (e.g., 1 hour, 6 hours, 1 day). Even if a message is never read, it will self-destruct on the server side after expiry.

The backend uses periodic cleanup jobs to purge expired messages securely.

6. No Metadata, No Logs, No Games

BareSend does not store cookies, does not log IP addresses, and does not inject tracking pixels or analytics. It operates with zero user identifiers.

As a result, even if our message vault were compromised, attackers would only see encrypted blobs with no key, no context, and no metadata to tie anything together.

7. Tech Stack Overview

Frontend: HTML, Tailwind CSS, Vanilla JS with WebCrypto
Encryption: AES-256-GCM, PBKDF2 with 250k iterations and SHA-256
Backend: Lightweight Node or Python service with keyless message store
Storage: Temporary message blob store with expiry timestamps and read-once logic

8. Philosophy & Design Constraints

BareSend is designed as a minimalist privacy tool. The goal is not just to make surveillance inconvenient — but irrelevant. If we don’t have your data, no one can demand it from us.

It’s zero-knowledge, zero-footprint, and zero-bullshit.

BareSend is not about hiding. It's about choosing when — and with whom — to share.

✉️🔒 Click here to send a message — encrypted and self-destructing