Security architecture
Zero-knowledge design
Encryption keys are embedded in the URL fragment (#key=...). Per the HTTP specification, URL fragments are never sent to the server. The browser strips the fragment before making any request.
This means the server never sees encryption keys: not in request URLs, not in headers, not in logs, nowhere. Even with full server access (root shell, database dump, memory inspection), conversations remain unreadable.
"We can't hand over what we don't have."
What we encrypt
Text messages
Encrypted client-side using NaCl secretbox (xsalsa20-poly1305). Each message uses a unique random nonce. The server only stores ciphertext blobs.
Algorithm: XSalsa20-Poly1305
Key size: 256-bit
Library: TweetNaCl
Nonce: Random, unique per message
Voice and video
Encrypted using LiveKit E2EE with PBKDF2 key derivation. All audio and video frames are encrypted before leaving your device.
Protocol: LiveKit E2EE (SFrame)
Key derivation: PBKDF2
Media server: Self-hosted (not cloud)
Recording: Impossible (keys never on server)
WHY IT'S SECURE
- ✓ Text: NaCl secretbox (xsalsa20-poly1305), authenticated encryption, 256-bit key, audited TweetNaCl implementation
- ✓ Voice and video: every frame encrypted before leaving your device
- ✓ Self-hosted media server, no third-party cloud processes your streams
What we don't store
WHY IT'S SECURE
- ✓ Nothing to steal, even a full database breach yields zero usable data
- ✓ No user accounts means no credential databases to target
- ✓ No IP logging means no connection between rooms and identities
If compelled by law
If Hushroom receives a valid legal request (court order, subpoena, law enforcement request), here is a transparent breakdown of what we can and cannot provide:
We CAN confirm
- ●That someone requested a verification code through email (we don't store which email was used)
- ●Approximate timestamp of room creation
- ●That a room existed (not its contents)
- ●Number of participants (not their identities)
We CANNOT provide
- ●Message content (E2EE, never stored in plaintext)
- ●Voice or video recordings (never recorded)
- ●Encryption keys (never reach server)
- ●The email used to create a room (not stored, only a one-way hash)
- ●Participant identities (anonymous by design)
- ●IP addresses (not logged)
- ●Historical data (auto-deleted, no backups)
WHY IT'S SECURE
- ✓ Technical limitations, not policy promises. We cannot provide what we don't possess
- ✓ Minimal metadata footprint, only what's strictly necessary for abuse prevention
- ✓ Even metadata auto-deletes after room TTL, no historical records
EU "Chat Control" (CSA Regulation) and Hushroom
The EU is negotiating a regulation on detecting child sexual abuse material (often called "Chat Control"). A temporary, voluntary-scanning regime applies from August 2026; the permanent regulation is still being negotiated and, as reported from the trilogues, is expected to protect end-to-end encryption.
Whatever the final text, Hushroom's design leaves nothing to scan on our side: there are no user accounts, rooms are ephemeral, message content is end-to-end encrypted in your browser, and the server only ever holds ciphertext that is deleted when the room expires. We cannot read, retain or hand over content, and we will not build a back door into the product. If legislation ever required one, we would say so here, openly, before changing anything.
We follow the CSA Regulation negotiations and update this section when the legal situation changes (last reviewed 2026-08-23).
Auto-delete
All encrypted room data is held in Redis with a strict TTL and lives only in RAM. Nothing is written to disk (RDB and AOF persistence are disabled), and when the TTL expires or the process stops, it is gone.
Rooms expire at the creator-chosen time limit (15 min to 4 hours). Deletion is automatic, not a cleanup job someone has to remember to run.
No backups. No replicas. No recovery.
When data is deleted, it's gone. There is no way to recover an expired room, even if we wanted to.
WHY IT'S SECURE
- ✓ RAM-only storage, if the power goes off the memory is cleared instantly
- ✓ No disk persistence (RDB/AOF disabled), nothing written to disk, ever
- ✓ Automatic TTL expiry, deletion is guaranteed, not optional
Email handling
Email addresses are only collected for room creators, not participants. The purpose is abuse prevention: rate limiting room creation per identity.
- You enter your email to create a room
- We send a 6-digit verification code (via Lettermint)
- After verification, the email is SHA-256 hashed and the original is discarded
- Only the hash is stored in the JWT token and used for rate limiting
- We cannot recover your email from the hash, it is a one-way function
Participants (people who join via link) provide no email, only a display name that exists in memory for the duration of the session.
Abuse prevention
Rate limiting: Redis-backed rate limiting on all endpoints. Auth endpoints: 5 req/15 min per IP. Room creation: 10/hour per verified email.
Host controls: Room creators can kick participants and lock rooms to prevent new joins.
Reporting: In-room abuse reporting. Reports stored for 90 days (room ID and report type only, no message content).
Ban system: Persistent bans using email hashes. Banned users cannot create rooms, and because only the hash is stored, even the ban list contains no email addresses.
Infrastructure
Self-hosted in Sweden (EU)
HTTPS + WSS (TLS 1.3)
Self-hosted LiveKit (not cloud)
Self-hosted (UDP 3478, TLS 5349)
Redis (RAM only, no disk persistence)
Swedish law (EU GDPR)
Questions about the security model?
Read how rooms work, or write to us. We answer security questions in detail.