Architektur, animiert
Eine Nachricht in TalX macht immer dieselben fünf Schritte auf dem eigenen Gerät – und sucht sich danach den ersten Weg, der trägt. Die Grafik zeigt beides. Wähle oben einen Zustellweg aus, um zu sehen, wann er greift.
1 NearbyBluetooth + WLAN-Direct, ganz ohne Internet
Google Nearby Connections spannt ein P2P_CLUSTER-Mesh auf. Zwei Geräte in Funkreichweite tauschen Chunks direkt aus – ohne Router, ohne Mobilfunk, ohne Server. Auch die Anruf-Signalisierung läuft über diesen Weg.
- kein Internet nötig
- Reichweite ≈ Bluetooth/WLAN-Direct
- derselbe Ciphertext wie überall
2 Lokales NetzmDNS-Discovery und direkte TCP-Verbindung
Im selben (W)LAN kündigt sich jedes Gerät per mDNS/NSD an und die Gegenstelle verbindet sich direkt per TCP. Längenpräfixierte Frames, 512-KB-Deckel pro Frame, ein HELLO nur zur Zuordnung. Zustellung in Sekunden, komplett serverlos – Sprach- und Videoanrufe eingeschlossen.
- serverlos im Heimnetz
- Anrufe ohne Relay
- Zustellung in Sekunden
3 WebRTC P2PDirekte Internetverbindung zwischen den Geräten
Über das Internet baut TalX einen WebRTC-DataChannel direkt zwischen beiden Geräten auf (DTLS). Der Relay vermittelt dafür nur die Verbindungsdaten – und die sind selbst bereits Ende-zu-Ende-verschlüsselt. Die Nutzdaten nehmen den direkten Weg.
- direkt Gerät zu Gerät
- DTLS zusätzlich zur E2E-Schicht
- TURN nur hinter striktem NAT
4 RelayRückfall mit Store-and-Forward, wenn nichts anderes greift
Ist der Kontakt offline, nimmt der Relay den Ciphertext an, hält ihn bis zu sieben Tage und stellt ihn beim nächsten Verbinden zu. Er sieht ausschließlich Ciphertext – lesen oder verändern kann er nichts. Optional weckt ein Push-Signal ohne Inhalt das Zielgerät.
- sieht nur Ciphertext
- Puffer max. 7 Tage
- selbst betreibbar
Alle Wege gleichzeitig so entscheidet TalX in der Praxis
TalX probiert die Wege der Reihe nach: erst Nearby, dann das lokale Netz, dann eine direkte WebRTC-Verbindung, zuletzt den Relay. Der erste Weg, der trägt, gewinnt – und genau dieser Weg steht später als kleines Symbol an der zugestellten Nachricht. Gelingt gar nichts, bleibt der Inhalt in der verschlüsselten Outbox liegen und wird bei jeder neuen Verbindung erneut versucht.
- Reihenfolge: Nearby → LAN → WebRTC → Relay
- Zugestellt heißt: ACK zurück, nicht „abgeschickt“
- Der genutzte Weg ist an jeder Nachricht ablesbar
Die Schicht, die sich nie ändert
Abschnitt betitelt „Die Schicht, die sich nie ändert“Egal welcher Weg gewählt wird: Was das Gerät verlässt, ist bereits fertiger Ciphertext. Kein Transport kennt einen Schlüssel, keiner kann etwas lesen, keiner kann etwas unbemerkt verändern.
-
Klartext entsteht in der App. Text, Foto, Video, Datei, Sprachnachricht – alles wird zu einem Inhalts-Umschlag zusammengefasst. Dateien stecken darin als Base64.
-
Komprimieren, und zwar vorher. DEFLATE läuft vor der Verschlüsselung, denn Ciphertext ist zufällig und lässt sich nicht mehr packen. Das spart bei Texten 60–80 % und bei Medien rund 25 % Funkvolumen. Was durch Komprimieren größer würde, geht unkomprimiert raus und ist entsprechend markiert.
-
Schlüssel ableiten. Für 1:1-Chats liefert der Double Ratchet einen frischen Message-Key – für jede einzelne Nachricht einen neuen. In Gruppen kommt er aus der Sender-Key-Kette des Absenders. In den Wurzelschlüssel ist zusätzlich ein ML-KEM-1024-Geheimnis eingemischt.
-
AES-256-GCM. Verschlüsseln und authentifizieren in einem Zug. Ein einziges verändertes Bit lässt die Prüfung fehlschlagen – die Nachricht wird dann verworfen, nicht etwa halb angezeigt.
-
In Stücke schneiden und in die Outbox. Der Ciphertext wandert in Chunks von rund 18 KB über den Funk – höchstens 8192 Stück je Übertragung, was den Empfangspuffer nach oben deckelt. Der Eintrag bleibt in der verschlüsselten Outbox liegen, bis eine Bestätigung des Empfängers zurückkommt.
Was „zugestellt“ tatsächlich heißt
Abschnitt betitelt „Was „zugestellt“ tatsächlich heißt“Der Haken an der eigenen Nachricht erscheint nicht beim Absenden, sondern erst, wenn das Gerät der Gegenseite den Empfang bestätigt hat. Bis dahin steht dort „Wartet auf Zustellung“ – auch dann, wenn die Bytes den Funk längst verlassen haben.
In Gruppen liegt pro Empfänger ein eigener Warteschlangen-Eintrag. Der Haken kommt erst, wenn kein Eintrag mehr offen ist, also alle bestätigt haben. Das ist bewusst so: Vorher setzte schon die erste Bestätigung irgendeines Mitglieds den Haken – das sah aus wie „alle haben es“ und verdeckte damit echte Verluste.
Der Relay – und was er sieht
Abschnitt betitelt „Der Relay – und was er sieht“Der Relay ist der letzte Rückfall. Er nimmt Nachrichten auch dann an, wenn der Empfänger gerade offline ist, hält sie bis zu sieben Tage und stellt sie beim nächsten Verbinden zu. Ohne ihn müssten beide Geräte gleichzeitig online sein.
| Was der Relay bekommt | Was er damit anfangen kann |
|---|---|
| Ciphertext (AES-256-GCM) | nichts – kein Schlüssel, kein Lesen, kein unbemerktes Ändern |
| Absender-Marker im Chunk | wechselt pro Übertragung – zwei Nachrichten desselben Absenders sind für Dritte nicht als zusammengehörig erkennbar |
| Registrierte Verbindung | der Betreiber sieht, welche Kennungen wann miteinander kommunizieren |
| Push-Weckruf | enthält keinen Inhalt – die App holt die Nachricht selbst verschlüsselt ab |
Der Absender-Marker ist ein HMAC über die Übertragungskennung, gebildet mit dem gemeinsamen Schlüssel. Zuordnen kann ihn nur der gemeinte Empfänger. Das schützt gegen Dritte – ein fremdes Gerät in Funkreichweite, jemand, der die Nutzlast beim Relay ausliest.
Gegenüber dem Betreiber des Relays hilft es nicht: Um überhaupt Nachrichten zu empfangen, muss ein Gerät dort registriert sein, und jede Zustellung ist dieser Registrierung zugeordnet. Wer auch das ausschließen will, betreibt den Relay selbst oder nutzt TalX rein offline über die Nahfunk-Wege.
Was wo im Ruhezustand liegt
Abschnitt betitelt „Was wo im Ruhezustand liegt“| Ort | Schutz |
|---|---|
| Nachrichten, Kontakte, Gruppen | SQLCipher (AES-256); die Passphrase liegt nur im Android-Keystore |
| Anhänge im App-Speicher | AES-256-GCM, eigener Schlüssel |
| Identität, Prekeys, ML-KEM-Paar | abgeleitet aus einem hardwaregewickelten Hauptgeheimnis |
| Hauptgeheimnis | Android-Keystore, StrongBox bevorzugt, sonst TEE |
| Cloud-Backup | AES-256-GCM, Schlüssel per Argon2id aus der Passphrase, zweiter Faktor beim Zurückholen |
Ein kopierter Datenordner, ein Backup oder ein gestohlenes ausgeschaltetes Gerät bleiben damit wertlos: Ohne das Secure Element genau dieses Geräts lässt sich das Hauptgeheimnis nicht auspacken – und ohne dieses kein einziges der übrigen.
Warum genau ein Hauptgeheimnis
Abschnitt betitelt „Warum genau ein Hauptgeheimnis“Ursprünglich lagen acht Geheimnisse einzeln im Hardware-Keystore. Auf StrongBox-Geräten kostet ein einziger Keystore-Vorgang rund zwei Sekunden; allein die beiden beim Start unvermeidbaren summierten sich auf etwa 4,4 Sekunden eines 7,8-Sekunden-Kaltstarts.
Heute bleibt genau ein Hauptgeheimnis hardwaregewickelt. Alle übrigen werden daraus per HKDF abgeleitet und in Software gewickelt – ein StrongBox-Vorgang pro Prozess statt einem pro Geheimnis. Die Hardwarebindung bleibt dabei vollständig erhalten: Wer den Wickel-Schlüssel im Keystore aufrufen konnte, konnte vorher ohnehin schon jedes einzelne Geheimnis öffnen.
Rückwärtskompatibilität als Zusage
Abschnitt betitelt „Rückwärtskompatibilität als Zusage“Jeder Chunk trägt die Protokollversion seines Absenders. TalX merkt sich pro Kontakt die zuletzt gesehene Version der Gegenseite und entscheidet daran, welche Funktionen benutzt werden dürfen. Solange die Version unbekannt ist, wird konservativ im ältesten Format gesendet.
Die Zusage: Senden und Empfangen bleiben über mindestens zehn App-Versionen hinweg kompatibel. Neue Funktionen stehen nur zwischen Geräten zur Verfügung, die sie beide kennen; ältere Gegenstellen bekommen automatisch die Variante, die sie lesen können. Unbekannte Inhaltstypen werden beim Empfang still ignoriert statt als leere Nachricht angezeigt.