Encryption on Matrix

Matrix conversations on nether.im are end-to-end encrypted. This page explains what that actually buys you, what it costs you if you’re careless, and what it does not protect. No cryptography background needed.

What end-to-end encryption means

In most chat platforms, the server can read every message you send — the operator chooses not to look (you hope). With end-to-end encryption (E2EE), messages are encrypted on your device and only decrypted on the recipients’ devices. The server relays sealed envelopes it cannot open. Not us, not any other homeserver your conversation federates with.

The flip side: if the keys only exist on your devices, then losing your devices means losing your keys — and with them, the ability to read your own message history. Matrix solves this with the recovery key.

The recovery key

When you set up your first Matrix client, you’ll be prompted to set up recovery (sometimes called a security key or key backup). This generates a recovery key: a long string of letters and numbers that looks something like EsTc XKzB 7DZQ ....

This key is what lets a brand-new login — a new phone, a fresh laptop, a reinstall — decrypt your old messages. It is the master key to your encrypted history.

Three things to internalize:

• Your password is not your recovery key. Your password proves who you are to the server. The recovery key unlocks your encrypted messages. They are separate, and resetting your password does not recover lost encryption keys.
• If you lose the recovery key and all your signed-in devices, your encrypted history is gone. Not “contact an admin” gone — mathematically gone. Nobody on the mod team can restore it, because nobody but you ever had it. That’s the whole point.
• Anyone who has your recovery key can read your encrypted messages. Store it somewhere private, not in a screenshot in your camera roll.

Where to keep it

Put it in a password manager — Bitwarden is free and works everywhere; KeePassXC is a fine offline choice. Create an entry called “Matrix recovery key” and paste it in. A piece of paper in a drawer at home also genuinely works.

Wherever you put it, do it at signup, when the client shows it to you — not later. Later never comes, and the day you need the key is the day your phone is already at the bottom of a lake.

Device verification

Each device you sign in from (phone, laptop, browser) is a separate session with its own keys. When you sign in somewhere new, your client will ask you to verify the new session — usually by comparing a short list of emoji on both devices, or by entering your recovery key.

Verification is how your devices prove to each other (and to the people you talk to) that they’re really yours and not someone who stole your password. Unverified sessions may be locked out of encrypted history, and other people’s clients will mark them with a warning. Get in the habit: sign in, verify, then chat.

What encryption does not hide

We’d rather be straight with you than let you assume more protection than exists:

• Metadata is not encrypted. The server necessarily knows which accounts are in which rooms, who sent a message to whom, and when. E2EE protects the content of messages, not the shape of the conversation.
• Not every room is encrypted. Encryption is a per-room setting. Large public rooms are often unencrypted by design (so new joiners can read history). Your client shows a shield icon on encrypted rooms — if you don’t see one, treat the room like a public forum.
• Encryption doesn’t protect you from the people in the room. Anyone in an encrypted room can screenshot it. Trust is a social problem; see the Code of Conduct on privacy.
• Your devices are the weak point. E2EE is only as strong as the unlocked phone you leave on the bar.

“Unable to decrypt this message”

Sooner or later you’ll see a message that renders as “unable to decrypt”. It’s the most common Matrix headache and it’s almost never data loss. Usual causes and fixes:

• New, unverified session. You signed in somewhere new and skipped verification. Verify the session (with another device or your recovery key) and history will backfill.
• Keys still syncing. Just verified? Give it a minute, or reopen the room.
• The message predates you. In some encrypted rooms, messages sent before you joined are simply not decryptable by you. That’s intended behaviour, not a bug.
• Sender-side glitch. Occasionally the sender’s client fails to share keys with one of your sessions. Ask them to resend, or ask in help if it keeps happening.

The pattern worth remembering: nearly every decryption problem traces back to an unverified session or a lost recovery key. Verify your sessions, keep the key in your password manager, and you will likely never see this page again.