Ein Browser kann starke Kryptografie ausführen; dem an ihn ausgelieferten Code muss dennoch vertraut werden.
Ein Browser kann Ende-zu-Ende-Verschlüsselung lokal ausführen, einschließlich einer Post-Quanten-Schlüsselvereinbarung, ohne dass eine native Messaging-App installiert werden muss. Die schwierige Frage ist nicht, ob die Mathematik in einem Tab funktioniert. Entscheidend ist, ob die ausgelieferte Anwendung, der Umgang mit Schlüsseln und der Aktualisierungspfad das Vertrauen verdienen, das die Unterhaltung erfordert.
Webbasierter Zugang kann praktisch sein, wenn eine Installation nicht möglich ist. Er macht die Anwendung nicht immun gegen Zensur, kompromittiertes Hosting, bösartige Erweiterungen oder ein kompromittiertes Gerät.
Die kryptografischen Bausteine des Browsers
WebCrypto stellt grundlegende Operationen für Verschlüsselung, Schlüsselableitung, Signaturen und Schlüsselverwaltung bereit. Gängige Implementierungen bieten Primitive wie AES-GCM und ECDH. Diese Operationen sind Bausteine, kein vollständiges authentifiziertes Messaging-Protokoll.
Eine Webanwendung kann eine geprüfte ML-KEM-Implementierung in JavaScript oder WebAssembly ergänzen, wenn die erforderliche native API fehlt. Die Browserunterstützung verändert sich. Entwickler sollten deshalb die benötigten Funktionen in den genauen Zielversionen testen, statt anzunehmen, dass jeder Browser dieselben Algorithmen anbietet.
Ein konzeptioneller hybrider Ablauf sieht so aus:
- Geeignete Schlüssel mit kryptografisch sicherem Zufall erzeugen.
- Das Schlüsselmaterial des Gegenübers über den Identitätsmechanismus des Protokolls authentifizieren.
- Klassische und Post-Quanten-Beiträge zu einem gemeinsamen Geheimnis gewinnen.
- Diese gemäß dem festgelegten Schlüsselableitungsschema und dem Kontext der Unterhaltung kombinieren.
- Abgeleitete Schlüssel zur authentifizierten Verschlüsselung verwenden und dabei Nonces und Zustand korrekt verwalten.
Dies ist eine erläuternde Übersicht, keine Implementierungsanleitung. FIPS 203 standardisiert ML-KEM; der Standard zertifiziert weder eine bestimmte Browseranwendung noch definiert er jeden Schritt eines Chatprotokolls.
HTTPS-Auslieferung gehört zum Vertrauensmodell
Normalerweise liefert der Server das JavaScript und WebAssembly aus, das Klartext verarbeitet. Eine bösartig veränderte Anwendung kann eine Nachricht vor der Verschlüsselung oder nach der Entschlüsselung lesen, selbst wenn ihre Kryptografiebibliothek solide Algorithmen verwendet.
HTTPS hilft, die Auslieferung zu authentifizieren und vor Eingriffen im Netzwerk zu schützen. Es beweist nicht, dass der Betreiber des Ursprungsservers, sein Bereitstellungssystem oder seine Abhängigkeiten unkompromittiert sind. Eine gewöhnliche HTTPS-Webseite ist nicht automatisch ein unabhängig signiertes Anwendungspaket.
Die W3C-Sicherheitshinweise zu WebCrypto behandeln Skriptinjektion und die Notwendigkeit, die Integrität der Anwendung zu schützen. Content Security Policy, sorgfältige Verwaltung von Abhängigkeiten und andere Web-Sicherheitsmaßnahmen verringern Risiken. Keine davon verwandelt jedoch beliebigen Code desselben Ursprungs in einen nicht vertrauenswürdigen Beobachter, der Anwendungsdaten nicht berühren kann.
Auch WebAssembly teilt die Sicherheitsgrenze der Anwendung. Seine Sandbox begrenzt den Zugriff auf das Hostsystem über definierte Schnittstellen; sie macht die aufrufende Seite nicht vertrauenswürdig. C zu Wasm zu kompilieren macht die Ausgangssprache nicht speichersicher.
Schlüssel existieren nicht unbedingt nur im RAM
Ein Browser-Messenger kann Schlüssel oder verschlüsselten Zustand dauerhaft speichern, damit Nutzer zur selben Identität zurückkehren können. Er kann auch Geräteverknüpfung oder verschlüsselte Wiederherstellung anbieten. Diese Verhaltensweisen müssen dokumentiert werden, statt sie einfach auszuschließen.
Sinnvolle Fragen sind:
- Welche Schlüssel werden dauerhaft gespeichert, und in welchem Browserspeicher?
- Was passiert, wenn Websitedaten gelöscht werden oder eine private Browsersitzung endet?
- Kann bösartiger Code im Kontext der Anwendung einen nicht exportierbaren Schlüssel weiterhin verwenden?
- Kann ein neu ausgeliefertes Update auf alten lokalen Zustand zugreifen?
- Stellt die Wiederherstellung die Identität, den Nachrichtenverlauf oder beides wieder her?
Ein nicht exportierbarer WebCrypto-Schlüssel beschränkt den Export über die API. Das allein verhindert nicht, dass feindlicher Anwendungscode erlaubte Operationen anfordert oder Klartext sammelt.
Web- und native Clients haben unterschiedliche Vor- und Nachteile
| Aspekt | Browser-Client | Nativer Client |
|---|---|---|
| Verteilung | Ursprung, Hosting und Web-Update-Prozess | App-Store oder Paketverteilung und Signierungsprozess |
| Lokale Speicherung | Browserspeicher und Profilverhalten | App-Speicher des Betriebssystems und Anwendungslebenszyklus |
| Angriffsfläche | Skripte desselben Ursprungs, Erweiterungen und Browser-Schwachstellen | Anwendungsabhängigkeiten und Schwachstellen in Betriebssystem oder App |
| Verfügbarkeit | Erreichbare Domain und benötigte Netzwerkdienste | Auch eine installierte App benötigt ihre erforderlichen Netzwerkdienste |
Keine Spalte bestimmt einen Gewinner, ohne die Implementierung zu untersuchen. Eine Webanwendung kann nach ihrer Entfernung aus einem App-Store erreichbar bleiben, doch eine blockierte Domain oder ein fehlender Netzwerkpfad kann den Zugang weiterhin verhindern.
Leistung messen statt versprechen
ML-KEM-768 verwendet nach FIPS 203 einen 1.184 Byte großen Kapselungsschlüssel und einen 1.088 Byte großen Chiffretext. Diese Größen erklären, warum Protokolle KEM-Aktualisierungen zeitlich einplanen können, statt jeder kurzen Nachricht frisches Material anzuhängen. Sie sind keine Messwerte für die Bandbreite oder Geschwindigkeit einer gesamten Anwendung.
Ein brauchbarer Benchmark nennt Browser, Gerät, Build, Aufwärmmethode, gemessene Operation und Verteilung der Laufzeiten. Berücksichtigen Sie Seitenstart, Laden von Modulen, Speicherverbrauch, leistungsschwache Geräte und Netzwerkaufwand. Aussagen wie „unter zwei Millisekunden auf allen modernen Smartphones“ erfordern veröffentlichte Messungen; dieser Artikel liefert sie nicht.
Was das für Livara bedeutet
Livaras Sicherheitsübersicht dokumentiert LVR1 und die Grenzen der Wiederherstellung. Das Proof Lab demonstriert ausgewählte lokale P-256-, HKDF- und AES-GCM-Operationen; die Seite schließt die vollständige LVR1/LGS1-Komposition ausdrücklich aus diesem Prüfstand aus. Eine erfolgreiche Demonstration beweist daher nicht die Sicherheit des gesamten ausgelieferten Webcodes.
Verwenden Sie vor einer sensiblen Unterhaltung im Browser einen authentischen, gepflegten Client, prüfen Sie das aktuelle Bedrohungsmodell, schützen Sie das Browserprofil und verifizieren Sie das Gegenüber über das unterstützte Verfahren zur Schlüsselprüfung. Komfort und nützliche Kryptografie können zusammenkommen, solange die Grenze der Web-Auslieferung Teil der Bewertung bleibt.
