LeaRain: [decryptoparty] - Unabled to stay encrypted

Summary

Lea Rain presents an introductory, user-focused explanation of why Matrix clients may show “Unable to decrypt” and how she recovered a large history of encrypted messages. The talk is not a comprehensive cryptographic or security audit; it uses her recovery experience to explain aspects of Matrix encryption and key management.

How Matrix Encryption Works

• Matrix is a decentralized real-time communication protocol. Conversations, including one-to-one chats, are organized into rooms, and servers federate to exchange events.
• Room messages are stored on home servers as ciphertext. Decryption requires keys held by clients; keys may also be synchronized or backed up.
• Matrix uses Olm and Megolm for encrypted communication. The talk also covers the Double Ratchet concept, per-message keys, key exchange, and forward secrecy as background.
• A Matrix client session is associated with a device ID. Multiple keys are used for encryption, room sessions, and signatures. If a required key is missing, delayed, or unavailable on a particular device, messages may be undecryptable there.
• Message metadata—such as the sender, timestamps, room and event IDs, and device-related identifiers—is not encrypted in the same way as message content. It may reveal information about communication even when the ciphertext remains protected.
• The speaker describes sender keys as useful for checking whether messages are consistent with a sender or device. She notes that sender key and device ID are deprecated in favor of a Session ID, though they were still present in the data she examined. Decrypted content alone does not prove sender authenticity.

Message-Recovery Workflow

The speaker’s usual client export struggled with very large histories—potentially hundreds of thousands of messages—because fetching and decrypting them through the client-server API was slow, resource-intensive, and sometimes incomplete. Some older devices still had active sessions and keys, so she exported keys from a client that had continued receiving messages.

Her successful approach used access to the home server’s database:

1. Export the session keys from a Matrix client or key backup.
2. Decrypt the exported key file with Matrix Utilities, using its password-protected export.
3. Get the room ID from a message’s raw data in the Matrix UI.
4. Extract the room’s encrypted events from the home-server database using the room ID.
5. Decrypt the events with the exported keys using the Rust tool Matrix Message Decrypter.
6. Process the resulting JSON, for example with jq, to filter messages, format timestamps, or prepare a more readable or machine-readable export.

The recovered output can be used to read old messages, reconstruct a timeline, or analyze message histories. Recovery may still be incomplete if some keys are missing.

Practical Guidance and Limitations

• Keep key backups. The speaker recommends periodically exporting session keys and storing them in an encrypted backup.
• Protect decrypted keys carefully. Once exported and decrypted, the keys can be used to read messages, so they should not be left exposed on disk.
• Keep keys and encrypted message data separate where possible, rather than storing both together.
• Old devices or sessions may retain keys that newer devices lack, but relying on devices that were never logged out is not a dependable backup strategy.
• The database method requires access to the relevant home-server data. It is most practical with a self-hosted or local instance, or with help from a trusted administrator, and may not be available on a large hosted service.
• A possible alternative is a lightweight custom client that retrieves historical events through Matrix’s client-server API. The speaker presents this as an idea, not a tested solution.
• The speaker briefly suggests that Matrix reactions may not be encrypted, based on a pull request she found, but advises listeners to verify this.

Tools and Resources

The talk mentions Matrix Message Decrypter (Rust), Matrix Utilities, Matrix documentation, jq, and a paper on Matrix security failures that the speaker recommends for further reading.

Main speaker: Lea Rain. The talk also references Matrix documentation, the Matrix Message Decrypter project and its documentation, and an external paper on Matrix security.