Yourchatsareencryptedbeforetheyarestored.
Messages, file names, result links and chat titles are encrypted with AES-256-GCM, with a separate key for every account. This page explains what is protected, what is not, and the standards behind it.
- AES-256-GCM
- Tamper-checked
From your message to the database, in four steps
Reading a chat runs the same path in reverse, and only succeeds if every check passes.
A key is derived for you
One master secret lives only in the server environment. From it, HKDF-SHA256 derives a separate 256-bit key for every account, so one key never protects two people.
Each message is sealed
Before a message or chat title reaches the database, it is encrypted with AES-256-GCM using a fresh random 96-bit IV.
It's pinned to its place
The chat id and message id are bound in as authenticated data. A record copied into another chat, or another message slot, fails to open.
Only ciphertext is stored
The database holds a token shaped v1.iv.tag.ciphertext. A database dump, backup or leaked table shows no readable chat.
What is encrypted, and what stays readable
A few fields must stay readable so chats can be ordered, loaded and deleted. None of them contain your content.
Unreadable at rest
Anyone browsing the chats table, a backup file or a database export sees ciphertext only.
Tamper detection
GCM adds an authentication tag. If a single bit changes, decryption fails instead of returning altered text.
Swap protection
Binding ids as authenticated data stops someone with database access from moving a message into another chat.
Per-account keys
A key derived for one account cannot open another account's records.
Ready for rotation
Every token starts with a version tag (v1). A future v2 key can be added and old records re-encrypted in the background.
Fail closed
Records that are plaintext, damaged or from another chat are dropped on read. Nothing unverified is shown.
Where this sits among the options
Three common ways to protect stored chats, and what each one covers.
| Disk encryption only | Encrypted in the app (ours) | End-to-end | |
|---|---|---|---|
| Protects against stolen backups or dumps | |||
| Protects against a leaked database login | |||
| Server can read your chats | |||
| Detects tampering with a record | |||
| Recoverable if you forget your password | |||
| Works with server-side features such as search |
Disk encryption protects a stolen drive but not a leaked database login. End-to-end gives the strongest privacy, at the cost of features that need the server to read content.
The research behind the choices
We use standard, published building blocks instead of inventing our own scheme.
Design decisions
- Authenticated encryption
- GCM encrypts and authenticates in one step, so altered data is rejected rather than decoded into garbage.
- Random 96-bit IV
- The size GCM is designed around. Per-account keys keep every key far below NIST's limit of about 2^32 random-IV uses.
- HKDF per account
- Key separation limits the damage if one derived key is ever exposed.
- Associated data
- The chat and message ids are authenticated but not hidden, which stops records being moved between chats.
- Version prefix
- The leading v1 lets a new key or algorithm be introduced without breaking existing chats.
Questions people ask
Can the Brandmade.click team read my chats?
No, the chats are stored encrypted.
What if I delete a chat?
The conversation will be removed from brandmade.click memory. Deleting a single question removes its encrypted record and the answer that follows it.
Create with your chats kept private
Your history is encrypted from the first message. Start a new click whenever you're ready.