Die entscheidende Sicherheitsfrage ist nicht, ob Verschlüsselung stark klingt, sondern was sie schützt, wer die Schlüssel besitzt und welche Nachweise die Aussage stützen.
„Verschlüsselung auf Militärniveau“ liefert nicht genügend Informationen, um eine Messaging-App zu beurteilen. Der Ausdruck sagt Ihnen nicht, wer die Schlüssel besitzt, welche Unterhaltungen geschützt sind, ob Backups Klartext offenlegen oder was geschieht, wenn ein Gerät kompromittiert wird.
Die sinnvolle Reaktion besteht nicht darin, Verschlüsselung abzutun. Vielmehr sollte man ein beeindruckendes Etikett durch konkrete, überprüfbare Aussagen ersetzen.
AES-256 ist eine Algorithmuswahl, kein vollständiges Sicherheitsmodell
AES ist ein öffentlicher Standard, keine geheime Militärtechnologie. FIPS 197 des NIST spezifiziert AES-128, AES-192 und AES-256; die Zahl bezeichnet die Schlüssellänge. Der Standard wurde 2023 redaktionell überarbeitet, ohne den Algorithmus zu ändern.
Eine starke Chiffre kann trotzdem in einem System eingesetzt werden, in dem der Dienst Zugriff auf Klartext hat. Fragen Sie, wer entschlüsseln kann, nicht nur, wie lang der Schlüssel ist. Fragen Sie auch, wie Schlüssel erzeugt und gespeichert werden, wie Identitäten authentifiziert werden und bei welchen Fehlerbedingungen die Anwendung abbricht, statt unsicher fortzufahren.
Wenn ein Anbieter AES-GCM nennt, ist das konkreter als AES allein: GCM verbindet Verschlüsselung mit Authentifizierung. Der korrekte Umgang mit Nonces, die Prüfung der Authentifizierungstags und andere Implementierungsanforderungen bleiben wichtig. Die GCM-Spezifikation des NIST ist die technische Referenz; ein Logo ist kein Nachweis dafür, dass eine App sie korrekt umsetzt.
Vier unterschiedliche Aussagen, die im Marketing häufig vermischt werden
| Aussage | Was sie betrifft | Was sie nicht belegt |
|---|---|---|
| Transportverschlüsselung | Schutz über eine Verbindung, etwa von der App zum Server | Dass der Server den Inhalt nicht lesen kann |
| Verschlüsselung ruhender Daten | Schutz gespeicherter Daten innerhalb eines bestimmten Schlüssel- und Zugriffsmodells | Dass der Betreiber keinen Entschlüsselungsschlüssel besitzt |
| Ende-zu-Ende-Verschlüsselung | Schutz von Inhalten zwischen festgelegten Endpunkten | Die Sicherheit eines kompromittierten Endpunkts oder die Ehrlichkeit eines Empfängers |
| Post-Quanten-Schlüsselaushandlung | Widerstand gegen bestimmte Quantenbedrohungen beim Aufbau von Schlüsseln | Ein vollständiges Audit der App, Anonymität oder garantierte zukünftige Sicherheit |
Transportverschlüsselung bedeutet nicht, dass jede Datenbank des Anbieters unverschlüsselten Klartext speichert. Ein Dienst kann gespeicherte Daten zusätzlich verschlüsseln. Entscheidend ist, ob der Anbieter die Schlüssel kontrolliert oder anderweitig auf lesbare Inhalte zugreifen kann. Bleiben Sie präzise, statt einen Slogan durch einen anderen zu ersetzen.
Eine breitere Einführung finden Sie unter Was Ende-zu-Ende-Verschlüsselung schützt.
„Verwendet einen NIST-Standard“ heißt nicht „FIPS-validiert“
FIPS 203 definiert ML-KEM, einen Schlüsselverkapselungsmechanismus. Ein Messenger kann angeben, diesen Algorithmus zu verwenden, ohne dass seine gesamte Anwendung zertifiziert oder unabhängig geprüft wurde. Standards, Algorithmustests, die Validierung kryptografischer Module und Produktsicherheitsaudits sind unterschiedliche Arten von Nachweisen.
Das Cryptographic Module Validation Program des NIST stellt klar, dass die Implementierung zugelassener Funktionen nicht ausreicht, um eine FIPS-140-Modulvalidierung nachzuweisen. Wenn ein Produkt mit einer Validierung wirbt, verlangen Sie das Zertifikat, das genaue Modul samt Version, die Betriebsumgebung und die zugelassene Konfiguration. Klären Sie anschließend, welchen Teil des Produkts dieses Zertifikat tatsächlich abdeckt.
Deshalb sollte auch „256-Bit-Sicherheit“ nicht als pauschale Bewertung für einen gesamten Messenger dienen. Protokollzusammensetzung, Schlüsselverwaltung und Implementierung können unterschiedliche Grenzen setzen.
Passwortauthentifizierung ist keine Nachrichtenverschlüsselung
Ein Anmeldeverfahren beantwortet die Frage, ob ein Nutzer auf ein Konto zugreifen darf. E2EE beantwortet, wer geschützte Nachrichteninhalte lesen kann. Keine der beiden Funktionen bietet automatisch die Eigenschaften der anderen.
SRP ist beispielsweise darauf ausgelegt, eine Authentifizierung zu ermöglichen, ohne das Passwort selbst zu übertragen. Das bedeutet nicht, dass eine gestohlene Authentifizierungsdatenbank harmlos wäre. Die Sicherheitsbetrachtung zu SRP in RFC 5054 erläutert, dass ein gestohlener Verifier Angriffe durch Passworterraten und andere Risiken ermöglicht. Vermeiden Sie den Schluss: „Es gibt keine Passwörter zu stehlen, also kann ein Servereinbruch keine Rolle spielen.“
Praktisch sollten Leser nach Kontowiederherstellung, aktiven Sitzungen und dem Zusammenhang zwischen Kontozugriff und Verschlüsselungsschlüsseln fragen. Eine Antwort, die lediglich „Zero Knowledge“ wiederholt, lässt die wichtigen Fragen offen.
Fünf Fragen an die Sicherheitsseite eines Messengers
- Welche Bereiche sind abgedeckt? Einzelchats, Gruppen, Dateien, Anrufe, öffentliche Beiträge und Backups können unterschiedliche Grenzen haben.
- Wer besitzt nutzbare Schlüssel? Berücksichtigen Sie Wiederherstellungsschlüssel, verknüpfte Geräte und serverseitige Verarbeitungsmodi.
- Wie wird der andere Endpunkt authentifiziert? Achten Sie auf Schlüsselprüfung, aussagekräftige Änderungswarnungen und ein dokumentiertes Vertrauensmodell.
- Welche Nachweise gibt es? Spezifikationen, reproduzierbare Builds, Testvektoren und unabhängige Audits beantworten unterschiedliche Fragen. Fragen Sie jeweils nach Version und Umfang.
- Was bleibt sichtbar oder angreifbar? Metadaten, kompromittierte Geräte, kopierte Nachrichten und öffentliche Inhalte dürfen in der Erklärung nicht unter den Tisch fallen.
Wenden Sie dieselben Fragen auf Livara an. Die Sicherheitsdokumentation nennt LVR1 und LGS1 und veröffentlicht betriebliche Grenzen. Betrachten Sie dies als zu bewertende Produktaussagen, nicht als unabhängige Zertifizierung. Das Proof Lab bietet begrenzte Demonstrationen und Artefaktprüfungen, keinen Beweis dafür, dass jede Funktion oder Veröffentlichung sicher ist.
So lesen Sie ein unabhängiges Audit
Prüfen Sie Datum, Prüfer, Code-Revision, einbezogene Plattformen und ausgeschlossene Komponenten. Lesen Sie die Befunde und den Behebungsstatus, nicht nur das zusammenfassende Prüfsiegel. Ein Audit einer kryptografischen Bibliothek deckt nicht automatisch Kontowiederherstellung, Web-App, Benachrichtigungen oder Betriebssicherheit ab.
Ein fehlendes Audit ist eine Lücke bei den Sicherheitsnachweisen, kein Beweis für eine konkrete Schwachstelle. Umgekehrt ist ein Audit keine lebenslange Garantie. Ein sinnvoller Vergleich hält die Nachweise und ihre Grenzen fest, statt einen universellen „sichersten“ Sieger auszurufen.
Häufig gestellte Fragen
Ist „Militärniveau“ immer eine andere Bezeichnung für AES-256?
Nein. Leiten Sie aus dem Ausdruck keinen bestimmten Algorithmus und keine Zertifizierung ab. Bitten Sie den Anbieter, genau zu erläutern, was er damit meint.
Verhindert stärkere Verschlüsselung Screenshots oder Schadsoftware?
Sie verhindert weder, dass ein Empfänger Inhalte kopiert, noch, dass ein kompromittiertes Gerät Daten offenlegt, auf die es zugreifen kann. Das sind andere Bedrohungen.
Was ist aussagekräftiger als ein Sicherheitsslogan?
Ein klarer Geltungsbereich, ein benanntes Protokoll, ausdrückliche Grenzen und überprüfbare Nachweise für die ausgelieferte Implementierung. Die Erklärung sollte Ihnen helfen zu entscheiden, worauf Sie vertrauen können – und was noch geprüft werden muss.
