Sicherheitsmodell und Grenzen

Nachrichtentexte und Anhänge werden auf dem Endgerät mit AES-256-GCM verschlüsselt. Signaturschlüssel entstehen über WebCrypto und bleiben nicht exportierbar. Austauschschlüssel werden bevorzugt als nicht exportierbare CryptoKey-Objekte persistiert; auf iOS/WebKit existiert ein dokumentierter JWK-Rückfall, solange persistente CryptoKey-Handles nicht zuverlässig unterstützt werden.

Conversation-Schlüssel werden pro berechtigtem Gerät über ECDH und HKDF verpackt. Im Fassung-3-Pfad kombiniert der Sitzungsaufbau X25519 mit ML-KEM-1024; der Server transportiert Schlüsselmaterial und Chiffrate, soll aber keinen Inhaltsschlüssel besitzen.

Profilbilder fallen nicht unter diesen E2EE-Claim: Ihr Abruf verlangt eine Anmeldung und ihre Speicherung ist ruhend geschützt, sie bleiben aber für den Dienst lesbar. Eine bestehende Kommunikationsbeziehung wird bei Auflösung einer exakten Kontokennung nicht vorausgesetzt.

• X25519 + ML-KEM-1024 für hybrides PQXDH in Fassung 3
• Versionierte Schlüsselumschläge je Gerät
• Verschlüsselte Bearbeitung von Nachrichten
• Lokale Entschlüsselung kurzlebiger Datei-URLs

Seit dem 6. September 2026 ist der kontrollierte Fassung-3-Pfad produktiv aktiv. Für fähige Geräte baut er Sitzungen hybrid über PQXDH mit X25519 und ML-KEM-1024 auf; das abgeleitete Geheimnis wird ausschließlich Wurzelschlüssel des anschließenden Double Ratchet. Signierte und einmalige PreKeys sowie eine Sperre je Gerätepaar verhindern stilles Zurückfallen, nachdem das Paar Fassung 3 verwendet hat.

Der aktuelle Schutz ist bewusst begrenzt: Der Post-Quantum-Anteil betrifft den neuen Sitzungsaufbau, nicht einen durchgehend post-quanten-sicheren Ratchet. Unterhaltungen mit noch nicht fähigen Geräten nutzen einen dokumentierten, versionierten Kompatibilitätspfad. Die Architektur ist von öffentlich beschriebenen Signal-Protokollprinzipien inspiriert, aber eigenständig implementiert, nicht Signal-kompatibel und nicht libsignal.

Öffentlich werden Architektur, Algorithmen, Rolloutgrenze und bekannte Einschränkungen benannt. Detaillierte Protokollzuordnungen, Testvektoren, Bruchproben und Implementierungsnachweise bleiben kontrollierte Prüfunterlagen und werden nur in einem ausdrücklich vereinbarten Review- oder Auditumfang unter Vertraulichkeit zugänglich gemacht. Diese Zugriffsbeschränkung ersetzt keinen unabhängigen Sicherheitsnachweis.

Am 9. September 2026 wurde der aktuelle Stand mit 308 zugeordneten Bruchproben, 19 realen Browser-Durchgängen und 189 Browser-Prüfungen erneut nachgefahren. Mehrgeräte-, Parallelitäts-, Downgrade-, Wiederanlauf-, Widerrufs-, Zeitstempel- und Schema-Migrations-Pfade waren im ausführbaren Umfang grün.

Seit dem Metadaten-Ausbau speichern Nachrichten keine senderId mehr; signierte Autorenschaft liegt im verschlüsselten Inhalt. Direktchat-Paarwerte sind HMAC-abgeleitet, Schlüsselumschläge verwenden opake Empfängermarken und Reaktionen, Favoriten sowie Mentions unterhaltungsbezogene Mitgliedsreferenzen. Neue Lesestände werden über die Mitgliedschaftssequenz abgebildet statt über neue Receipt-Zeilen; alte Zeilen laufen in der 30-Tage-Aufbewahrung aus.

Verdeckte Mitgliedskennungen sind an kryptografische Besitznachweise gebunden. Im aktuellen Quell-/Prüfstand stellt der Client beim Kaltstart das Kennungsverzeichnis aus dem verschlüsselten Kontozustand her und zählt den Nachweis erst, wenn tatsächlich ein Beweis gesendet wurde. Verlaufsübergaben verwenden dort eine einmal berechnete opake Zielmarke und überspringen ältere unmarkierte Umschläge, statt eine Zuordnung zu erraten. Für die live signierte Laufzeit bleibt dafür ein eigener App-Release samt Migration erforderlich.

Betroffene Zeitfelder werden auf Minutenebene begrenzt. Realtime-Ausgaben werden auf die ausdrücklich vorgesehenen Vertragsfelder reduziert; lokale Entwürfe, UI-Merkwerte und Sicherheitsverifikation sind kontobezogen und Teil des Widerrufs- und Bereinigungspfads.

Das ist Metadatenminimierung, keine Metadatenfreiheit. Der aktive Dienst benötigt für Autorisierung und Routing weiterhin begrenzte Konto-, Beziehungs-, Geräte-, Zeit-, Medientyp- und Chiffratgrößeninformationen. Die Mitgliedschaftstabelle enthält derzeit weiterhin eine Kontokennung, der primäre Anzeigename bleibt in der Kontozeile gespeichert; vorübergehende Einladungswege und Alt-Receipts besitzen eigene Abbau- und Aufbewahrungsgrenzen.

• Routingbeziehungen und Gesprächsmitgliedschaften im laufenden Dienst
• Zeitpunkte, Mitglieds-Lesesequenz und ungefähre Aktivität
• Medientyp und Chiffratgröße von Anhängen
• Kontrollierte Kompatibilitätswege für noch nicht vollständig ausgerüstete Bestände
• IP- und Sicherheitsprotokolle gemäß Betriebsrichtlinie

Sicherheitsnummern machen Schlüsseländerungen sichtbar. Ein optionaler strikter Modus kann das Senden an nicht bestätigte Geräte blockieren.

Freiwillige Verifikation schützt nur, wenn Personen die Nummer über einen unabhängigen Kanal vergleichen und Warnungen ernst nehmen.