Threat model

Threat Model & Security Whitepaper

How hush.chat thinks about attackers, defences, and limits.

1. Overview & Design Goals

Hush Chat is designed as an end-to-end encrypted system where message content and decryption keys never leave user devices. The server sees only ciphertext and minimal metadata required to route messages and run the product.

This document explains what we protect, who we're defending against, and where the boundaries of the system are.

2. Assets We Protect

The security model focuses on protecting the following assets:

Message content: chat text, reactions, message edits.
File attachments: images, documents, and other media shared in rooms.
Room state: membership, room titles, and basic configuration.
Room keys: symmetric encryption keys used to protect each room.
Operator account data: email addresses, subscription status, and auth identifiers.

3. Adversaries & Threats

3.1 Adversaries we design against

Passive network attackers: anyone able to observe traffic between you and Hush.
Server compromise: an attacker gains read access to databases or storage.
Curious insiders: people with legitimate access to infrastructure trying to inspect data.
Malicious room operators: limited by the fact that they have the same access as any other key holder, but not more.

3.2 Adversaries we cannot fully defend against

Compromised participant devices: malware, keyloggers, screen capture, or OS-level backdoors.
Social and physical attacks: someone tricking or coercing a participant into sharing a room link or decrypted content.
Side-channel leaks: people taking screenshots, photos of the screen, or copying text.
Full-room-link compromise: an attacker who obtains the entire invite URL including the embedded key gains the same access as other participants.

4. Cryptographic Architecture (High-Level)

Hush Chat uses industry-standard cryptography in a classic end-to-end design: a per-room symmetric key with authenticated encryption.

Each room uses a unique symmetric key generated on-device.
AES-GCM with 256-bit keys is used for messages and attachments.
Each encrypted message and file uses a fresh initialization vector (IV).
Room keys never leave user devices and are never sent to Hush servers.

The result: servers only handle ciphertext (and limited metadata), which is useless without the corresponding room key.

5. Room Lifecycle, Persistence & Key Management

5.1 Ephemeral vs. persistent rooms

Hush rooms can be configured as:

Ephemeral rooms: expire automatically after a configured lifetime. When they expire, encrypted content and metadata stored on the server are purged.
Persistent rooms: remain active indefinitely so long as the operator chooses to keep them. The operator can delete a persistent room at any time, which destroys the stored encrypted content.

In both modes, Hush cannot recover a room once its server-side data is deleted and participants no longer hold the keys.

5.2 Room keys, sharing & link structure

Room keys are bundled into invite links. The link contains:

A public room identifier used by the server to route data.
A secret key component that never reaches the server, but is read by the client and used to decrypt.

Anyone with the full link (including the secret portion) can decrypt content. Anyone without it cannot, even if they can see server-side data.

5.3 Key regeneration (rotation)

Room operators can regenerate keys to create a cryptographic boundary in the conversation:

New messages are encrypted with the new room key and only accessible to participants who have been given the new link.
Old messages remain encrypted under the previous key, preserving history for participants who still hold that key.
Participants who lose or are not given the new key effectively lose access to future messages.

6. Attachments & Media

Attachments reuse the same per-room symmetric key and AES-GCM encryption:

Files are encrypted locally before upload.
Only encrypted blobs are ever stored by Hush.
Access is mediated via short-lived, signed URLs, preventing long-term public exposure.

7. Metadata, Logging & Privacy

Hush follows a zero-logs, privacy-first model:

No plaintext message logs.
No storage of room keys.
No IP-based room activity tracking.
No advertising or tracking pixels.

We maintain only the minimum metadata required for account operations, abuse prevention, and aggregate analytics.

8. User Responsibilities

End-to-end security is a shared responsibility. Users are responsible for:

Keeping their devices free from malware.
Treating room links as secrets (not sharing them in public channels).
Using strong passwords and safe authentication practices.

9. Security Feedback & Responsible Disclosure

If you have questions about this threat model or believe you've found a security issue, please contact security@hush.chat. We welcome responsible disclosure and aim to respond quickly.