Kryptografie im Detail

Grundsatz: Es gibt keinen selbstgebauten Chiffren-Code. Alle Primitive stammen aus etablierten, geprüften Bibliotheken.

Eingesetzte Verfahren

Zweck	Verfahren	Parameter
Asymmetrischer Schlüssel / DH	X25519	Curve25519
Schlüsselableitung	HKDF-SHA256	32-Byte-Ausgaben, eigene Domänen-Labels
Symmetrische AEAD	AES-256-GCM	96-Bit-Nonce, 128-Bit-Tag
Kettenschlüssel im Ratchet	HMAC-SHA256	Signal-Konstanten
Post-Quanten-KEM	ML-KEM-1024 (FIPS 203)	Kategorie 5, 32-Byte-Geheimnis
Passwort-Kopplung	J-PAKE (RFC 8236)	NIST-3072-Gruppe
Passwort-KDF Kopplung	Argon2id	32 MB, 3 Durchläufe
Passwort-KDF Backup	Argon2id	64 MB, 4 Durchläufe, Parameter im Dateikopf
Zweiter Faktor	TOTP (RFC 6238) oder Biometrie	6 Ziffern, 30 s, ±1 Fenster
Datenbank im Ruhezustand	SQLCipher (AES-256)	Passphrase nur im Keystore
Schlüssel-Wrapping	AES-256-GCM im Android-Keystore	StrongBox bevorzugt, TEE als Rückfall

Schlüssel-Hierarchie

Jedes Gerät besitzt ein X25519-Identitätsschlüsselpaar. Der private Teil ist AES-256-GCM-verschlüsselt gespeichert; der Wickel-Schlüssel liegt im Hardware-Keystore (StrongBox bevorzugt).

Daraus abgeleitet:

• pro Kontakt ein statischer Sitzungsschlüssel (ECDH → HKDF) für Bootstrap- und Steuerverkehr sowie den Post-Quanten-Austausch,
• der initiale Ratchet-Wurzelschlüssel je Kontakt, in den das ML-KEM-Geheimnis eingemischt wird,
• pro Nachricht ein flüchtiger Message-Key (Ratchet) beziehungsweise ein Einmal-Subkey auf den statischen Pfaden.

Datenbank-Passphrase und Anhang-Schlüssel sind unabhängige Zufallsschlüssel, ebenfalls gewickelt.

Über den statischen Sitzungsschlüssel laufen die häufigsten Nachrichten überhaupt – Präsenz, Bestätigungen, Profilangaben, der Post-Quanten-Austausch und die gesamte Anruf-Signalisierung. Sein Diffie-Hellman-Anteil wird deshalb prozessweit zwischengespeichert, gedeckelt auf 256 Einträge und bei einem Identitätswechsel geleert. Das bringt kein zusätzliches Geheimnis in den Speicher: Der Wert hängt allein am eigenen privaten Identitätsschlüssel, der ohnehin im Prozess liegt, und am öffentlichen Schlüssel der Gegenseite. Wechselt die Gegenseite ihren, entsteht ein neuer Eintrag – ein überholter wird nie benutzt.

Genau ein Hauptgeheimnis bleibt hardwaregewickelt; alle übrigen werden daraus per HKDF abgeleitet und in Software gewickelt. Das spart auf StrongBox-Geräten mehrere Sekunden Kaltstart, ohne die Hardwarebindung aufzugeben: Ohne das Secure Element dieses Geräts lässt sich das Hauptgeheimnis nicht auspacken, und ohne dieses kein einziges der übrigen.

Double Ratchet für 1:1-Nachrichten

Signal-konform: DH-Ratchet bei jedem Richtungswechsel, frischer Message-Key je Nachricht, Aufbewahrung übersprungener Schlüssel mit hartem Deckel (200). Ergebnis: Forward Secrecy und Post-Compromise-Security.

Der Ratchet-Zustand wird erst nach erfolgreicher Authentifizierung gespeichert; Zugriffe darauf sind serialisiert. Aufbewahrte Message-Keys verfallen nach sieben Tagen – vorher lagen sie unbegrenzt; aufgeräumt wird höchstens stündlich, damit die Prüfung nichts kostet.

Selbstheilung

Sitzungen können aus dem Tritt geraten: Eine Seite installiert neu, ein Backup wird zurückgespielt, ein Schlüssel wechselt. Dafür gibt es drei Mechanismen:

• Empfangsseitig werden für die erste Sendekette einer Sitzung auch bei bereits bestehender Sitzung Bootstrap-Kandidaten geprüft. Das ist sicher, weil jeder Kandidat authentifiziert entschlüsselt werden muss – Fremde können keine Sitzung unterschieben.
• Sendeseitig wird nach vielen unbestätigten Versuchen gedrosselt neu aufgebaut.
• Liegt der Absender mehr als 200 Schritte voraus, wird kontrolliert vorgespult – gedeckelt bei 25 000 Schritten, damit eine absurde Angabe keine Rechenlast erzeugt.

Ein zweiter Fall, der real auftrat: Jeder Zustellversuch verschlüsselte früher neu und verbrauchte dabei einen frischen Message-Key. Nach Stunden ohne Verbindung lag der Sender hunderte Schritte vor dem Empfänger, dessen Skip-Limit dann jede weitere Nachricht unlesbar machte. Heute senden Wiederholungen denselben Ciphertext erneut.

X3DH-lite: Forward Secrecy ab der ersten Nachricht

Ohne Prekey-Server wäre der erste Wurzelschlüssel einer Sitzung deterministisch aus den beiden Identitäten abgeleitet – und damit für jedes Kontaktpaar konstant, bis der Ratchet einen Schritt macht. Wer später einen privaten Identitätsschlüssel erbeutet, könnte die ersten Nachrichten rückwirkend entschlüsseln.

TalX löst das serverlos: Der Sender bootstrappt den Ratchet gegen einen rotierenden Prekey des Empfängers, der über dessen Profil verteilt wird. Rotiert wird alle 30 Tage; der vorige Prekey bleibt noch eine Runde liegen, damit unterwegs befindliche Nachrichten nicht ins Leere laufen – zusammen ein Kulanzfenster von rund 60 Tagen. Danach ist der private Teil gelöscht. Damit hat bereits die erste Nachricht Forward Secrecy.

Hybrider Post-Quanten-Austausch

Nach dem Verbinden handeln beide Seiten ein ML-KEM-1024-Geheimnis aus. Wer Initiator und wer Responder ist, ergibt sich deterministisch aus den Fingerprints; die Kapsel ist idempotent.

Das Geheimnis wird zusätzlich zum klassischen X25519-Anteil in den Wurzelschlüssel gemischt (HKDF über beides, mit eigenem Label). Klassisch bleibt damit gesetzt – der Post-Quanten-Anteil kommt obendrauf und kann nichts verschlechtern.

Ein wichtiger Konstruktionspunkt: Der Austausch selbst läuft über den statischen Sitzungsschlüssel, nicht über den Ratchet, den er erst etabliert. Andernfalls entsteht ein Henne-Ei-Problem – genau das trat auf und ist als Befund F-15 dokumentiert.

Statische Pfade und Einmal-Subkeys

Steuerverkehr (Präsenz, Profil, Synchronisation, Bestätigungen, Anrufsignale, der Post-Quanten-Austausch, Gruppen-Rückfälle), Anhänge im Ruhezustand und die WebRTC-Verbindungsdaten nutzen je Nachricht, Datei oder Block einen Einmal-Subkey: HKDF(statischer Schlüssel, 16-Byte-Salz, Label), wobei das Salz im Kopf mitgeführt wird.

Damit ist jede Kombination aus Schlüssel und Nonce unabhängig, und eine Nonce-Wiederholung wäre folgenlos.

Gruppen: Sender-Keys

Jedes Mitglied hat eine eigene Kette, verteilt über den 1:1-Ratchet. Rotiert wird nach 100 eigenen Nachrichten, zusätzlich zeitbasiert – eine ruhige Gruppe darf ihre Kette nicht monatelang stehen lassen – und verpflichtend bei jedem Mitgliederwechsel. Nach einer Rotation bleiben noch 16 Schlüssel der alten Kette gültig, damit umsortierte Nachrichten, die schon unterwegs sind, nicht verloren gehen. Auch übersprungene Gruppenschlüssel sind auf 200 gedeckelt.

Sicherheitsnummer

Aus beiden öffentlichen Identitäten wird eine vergleichbare Zahlenfolge gebildet. Sie ist geräteunabhängig identisch – ein früherer Fehler, bei dem sie je nach Spracheinstellung unterschiedlich ausfiel und dadurch einen falschen Alarm auslöste, ist behoben.

Was auf dem Draht steht

Jeder Chunk trägt die Protokollversion des Absenders – aktuell 13. Statt der Absenderkennung steht seit Protokollversion 13 ein pro Übertragung wechselnder Marker im Chunk: HMAC(gemeinsamer Schlüssel, Übertragungskennung). Zuordnen kann ihn nur der gemeinte Empfänger; zwei Nachrichten desselben Absenders sind von außen nicht als zusammengehörig erkennbar.

Das schützt gegen Dritte – ein fremdes Gerät in Funkreichweite, jemand, der die Nutzlast beim Relay ausliest. Gegenüber dem Relay-Betreiber hilft es nicht; er ordnet jede Zustellung der registrierten Verbindung zu.