Matrix E2EE Cheatsheet

Die Begriffe, ohne Nebel.

Matrix trennt sehr stark zwischen Account, Gerät, Nachrichtenschlüssel und Wiederherstellung. Die meisten Probleme kommen daher, dass ein neues Browser-Device nicht automatisch die alten Room Keys besitzt.

Account

Deine Matrix-ID

@tobias:server.tld ist die Identität. Aber sie entschlüsselt nichts allein. Entschlüsseln tun Geräte.

Device

Jeder Login ist ein Gerät

Browser A, Browser B und Handy sind verschiedene Matrix-Devices. Jedes hat eigene Device Keys und eigene lokale Crypto-Daten.

OLM

1:1 Schlüsselkanal

OLM ist der sichere Kanal zwischen zwei Devices. Darüber werden z.B. Room Keys an andere Devices verteilt.

Megolm

Raum-Nachrichten

Megolm verschlüsselt viele Nachrichten in einem Raum effizient mit einer Session. Dieser Session Key ist der Schlüssel zur Historie.

Room Key

Der eigentliche Leseschlüssel

Hat dein Device den passenden Room/Megolm-Key, kann es die Nachricht lesen. Hat es ihn nicht, sieht es nur „Unable to decrypt“.

Secret Storage

Safe im Account

Account-weiter Speicher für Secrets. Der Server speichert nur verschlüsselte Daten; der Recovery Key öffnet sie.

Key Backup

Cloud-Backup für Room Keys

Der Server kann verschlüsselte Kopien deiner Room Keys speichern. Ohne Recovery Key kann er sie im normalen Matrix-Modell nicht lesen.

Recovery Key

Schlüssel zum Backup

Damit entschlüsselt ein neues Device das Key Backup. Verlierst du ihn und alle alten Devices, ist alte E2EE-Historie oft weg.

Cross-Signing

Vertrauen zwischen Geräten

Damit sagst du: „Dieses neue Device gehört wirklich zu mir.“ Hilft bei Warnungen und beim Teilen von Secrets.

Was passiert beim Erstellen eines verschlüsselten Raums?

Die Nachricht selbst liegt auf dem Matrix-Server, aber der Server soll sie nicht lesen können. Lesbar wird sie nur mit dem passenden Room Key.

1

Raum anlegen

Der Client setzt m.room.encryption mit Megolm als Algorithmus.

2

Session starten

Dein Device erzeugt einen Megolm Session Key für diesen Raum.

3

Keys teilen

Der Room Key wird über OLM an berechtigte Devices der Mitglieder verteilt.

4

Nachricht senden

Der Text wird lokal verschlüsselt. Der Server speichert nur Ciphertext.

5

Empfangen

Andere Devices entschlüsseln lokal, sofern sie den passenden Room Key haben.

Warum neue Geräte alte Nachrichten nicht lesen

Login ist nicht gleich Schlüsselbesitz.

Wenn du dich auf einem neuen Browser einloggst, kennt Matrix zwar deinen Account. Aber das neue Device hat noch nicht automatisch die alten Megolm Room Keys. Dafür braucht es ein altes Device, Secret Sharing oder Key Backup + Recovery Key.

Server

verschlüsselte Eventsverschlüsseltes Key Backup

Device A

Room Keyskann lesen

Device B

Login OKbraucht Recovery

Matrix Chat in bestehender Webapp mit Keycloak?

Wenn User sich über eure Webapp identifizieren und teils mit Gästen schreiben, ist die wichtigste Frage nicht „kann man E2EE?“, sondern „welches Trust-Modell wollt ihr wirklich?“

Option A: Klassisches Matrix-E2EE

Maximale Privatsphäre. Server/Organisation kann nicht lesen.

Gut für echte vertrauliche Chats.
Schlecht, wenn Support/Organisation im Ausnahmefall Zugriff braucht.
Browser-Daten weg + kein Backup = alte Nachrichten evtl. weg.

Privatsphäre

Komfort

Org-Zugriff

Option B: Organisations-Key-Escrow

E2EE technisch aktiv, aber die Organisation verwaltet Recovery Keys.

Gut für „neues Device soll automatisch alles lesen“.
Passt, wenn Compliance/Support Zugriff haben darf.
Kein klassisches Zero-Knowledge-E2EE mehr.

Privatsphäre

Komfort

Org-Zugriff

„Ich logge mich neu ein und kann alles automatisch lesen“

Das geht für euren expliziten Fall, aber nicht magisch durch den Matrix-Server. Ihr baut bewusst eine Escrow-Schicht: euer Backend kennt oder verwaltet den Recovery Key und gibt ihn nach App-Auth wieder an den Client.

1

Login per Keycloak/App

Die Webapp weiß: dieser Nutzer ist Tobias. Matrix-Login erfolgt per Mapping/Token/Passwort-Flow.

2

Backend holt Recovery

Nach erfolgreicher App-Auth fragt der Client euer Backend nach dem hinterlegten Recovery Key.

3

Client restored Keys

Der Browser lädt Matrix Key Backup und entschlüsselt lokal die Room Keys.

4

Historie lesbar

Nach Restore kann das neue Device alte Nachrichten lesen, sofern sie im Backup waren.

Wichtig: Dann muss die UI ehrlich sein: „Organisationsverwaltete E2EE / Recovery“. Wenn das Backend Recovery Keys herausgeben kann, kann die Organisation im Ausnahmefall auch Nachrichten wiederherstellen.

Empfehlung für eure Webapp

Nicht so tun, als wäre es pure E2EE

Wenn Gäste, Browserwechsel, verlorene Browserdaten und Organisationszugriff normale Fälle sind, dann ist klassisches Matrix-E2EE ohne Escrow wahrscheinlich zu frustrierend. Besser: bewusstes Organisations-Recovery mit Audit Log, Zugriffskontrolle und klarer Nutzerkommunikation.

Technische Checkliste

Für automatisches Lesen auf neuem Device

Key Backup beim ersten Device automatisch einrichten.
Recovery Key serverseitig pro User/Device oder pro Account speichern.
Backend-Zugriff über App-/Keycloak-Session absichern.
Beim Login automatisch Recovery Key holen und restoreKeyBackup() ausführen.
Admin-Zugriffe auditieren.

Glossar

Alle Begriffe auf einen Blick.

Kurze Übersetzungen der wichtigsten Matrix-, E2EE- und Organisations-Recovery-Begriffe, die auf dieser Seite vorkommen.

Begriff	Einfach gesagt	Warum wichtig?
Matrix	Offenes Chat-Protokoll.	Regelt Räume, Nutzer, Nachrichten, Geräte und Verschlüsselung unabhängig von einem einzelnen Anbieter.
Homeserver	Der Matrix-Server eines Nutzers oder einer Organisation.	Speichert Accounts, Räume, Events und verschlüsselte Backups; im Normalmodell nicht die Klartext-Nachrichten.
Matrix-ID	Die Adresse eines Nutzers, z.B. `@name:server.tld`.	Identifiziert den Account, ist aber nicht automatisch ein Entschlüsselungs-Schlüssel.
Account	Das Nutzerkonto auf dem Homeserver.	Ein Account kann mehrere Devices haben; jedes Device hat eigene Kryptodaten.
Device	Ein konkreter Login: Browser, Handy, Desktop-App.	Neue Logins sind neue Devices und besitzen alte Room Keys nicht automatisch.
Device Keys	Langfristige Identitäts-Schlüssel eines Devices.	Damit erkennen andere Geräte, ob sie wirklich mit dem richtigen Device sprechen.
OLM	Verschlüsselter 1:1-Kanal zwischen zwei Devices.	Wird genutzt, um Room Keys sicher an einzelne Devices zu schicken.
Megolm	Gruppen-/Raum-Verschlüsselung für viele Nachrichten.	Effizient für Chats; ein Megolm Session Key kann viele Nachrichten einer Session entschlüsseln.
Room	Ein Chatraum: DM, Gruppe oder Kanal.	Nachrichten liegen als Events in Rooms.
DM	Direktnachricht zwischen Personen.	Technisch meist auch ein Matrix-Raum, nur mit kleinem Teilnehmerkreis.
Event	Ein Eintrag im Raum: Nachricht, Einladung, Name, Verschlüsselungs-Setting.	Matrix speichert fast alles als Events.
Ciphertext	Verschlüsselter Text.	Das sieht der Server bei E2EE statt Klartext.
Plaintext / Klartext	Die lesbare Nachricht vor oder nach der Verschlüsselung.	Soll bei klassischem E2EE nur auf berechtigten Devices sichtbar sein.
Room Key	Der Schlüssel zum Lesen einer Megolm-Session.	Fehlt er, erscheinen alte Nachrichten als „Unable to decrypt“.
Megolm Session	Eine laufende Schlüsselperiode in einem Raum.	Nachrichten aus dieser Periode brauchen genau den passenden Session Key.
Secret Storage	Verschlüsselter Account-Speicher für geheime Schlüssel.	Hilft, Recovery- und Cross-Signing-Secrets zwischen Devices wiederherzustellen.
Key Backup	Verschlüsseltes Backup der Room Keys auf dem Server.	Ermöglicht neuen Devices, alte Nachrichten zu lesen — wenn der Recovery Key vorhanden ist.
Recovery Key	Der Schlüssel zum Entsperren von Secret Storage / Key Backup.	Ohne ihn kann ein neues Device alte Backups nicht entschlüsseln.
Security Phrase	Merksatz/Passphrase statt rohem Recovery Key.	Nutzerfreundlichere Art, denselben Wiederherstellungszweck zu erfüllen.
Cross-Signing	Vertrauenssystem zwischen den eigenen Devices.	Hilft zu bestätigen, dass ein neues Device wirklich zum Nutzer gehört.
Device Verification	Aktives Bestätigen eines neuen Devices.	Reduziert Risiko, dass fremde Devices unbemerkt Zugriff bekommen.
Secret Sharing	Ein altes Device teilt Secrets mit einem neuen Device.	Alternative zur manuellen Recovery-Key-Eingabe.
E2EE	Ende-zu-Ende-Verschlüsselung.	Nachrichten sind zwischen Devices verschlüsselt; Server sieht im klassischen Modell keinen Klartext.
Zero-Knowledge	Server/Anbieter kann Inhalte nicht lesen.	Das ist der stärkste Datenschutzmodus, aber weniger bequem bei Recovery und Support.
Escrow	Hinterlegung eines Schlüssels bei einer dritten Stelle.	Bei Organisations-Escrow kann die Organisation Recovery Keys abrufen und damit Nachrichten wiederherstellen.
Key Escrow	Speichern von Recovery Keys durch Backend/Organisation.	Macht neues Device Recovery automatisch, schwächt aber das klassische E2EE-Vertrauensmodell.
Compliance Recovery	Organisationszugriff für definierte Ausnahmefälle.	Nützlich für Support, gesetzliche Pflichten oder Business-Kontinuität; braucht Audit und klare Regeln.
Audit Log	Protokoll, wer wann etwas abgerufen hat.	Pflichtnah bei Escrow, damit Schlüsselzugriffe nachvollziehbar sind.
Keycloak	Identity-/Login-System für Webapps.	Kann App-Login und Matrix-Account-Mapping steuern, ersetzt aber nicht automatisch Matrix-Krypto.
WASM / WebAssembly	Binärformat, das im Browser läuft.	Matrix Rust Crypto nutzt WASM; das Asset muss korrekt ausgeliefert werden.
IndexedDB	Browser-Datenbank.	Matrix speichert dort lokale Crypto-Stores und Room Keys; Browserdaten löschen kann Keys entfernen.
Crypto Store	Lokale Datenbank für Matrix-Kryptozustand.	Muss pro Device getrennt sein, sonst kollidieren Logins und Device-IDs.
`restoreKeyBackup()`	SDK-Funktion zum Wiederherstellen der gesicherten Room Keys.	Der praktische Schritt, der nach Recovery-Key-Eingabe alte Schlüssel ins neue Device lädt.
„Unable to decrypt“	Das Device hat den passenden Room Key nicht.	Nicht automatisch ein Serverfehler; meist fehlt Backup, Recovery oder Key Sharing.