Zero-Knowledge-Kurztext: Inhalte Ende-zu-Ende schützen

Problem

"Ende-zu-Ende-verschlüsselt" ist als Label im Markt massiv überdehnt. In vielen Produkten bedeutet es: der Schlüssel existiert kurzzeitig beim Anbieter, wird nach Nutzung verworfen, und der Anbieter verspricht, ihn nicht zu kopieren. Das ist ein Vertrauensversprechen und dabei weder struktureller noch nachprüfbarer Schutz. Wer personenbezogene oder anderweitige sensible Daten (z.B. Passwörter) verarbeitet, kann dem Anbieter nicht grundsätzlich trauen, nicht weil er bösartig ist, sondern weil Anordnungen, Insider-Zugriffe und erfolgreiche Angriffe existieren.

Zero-Knowledge (wörtlich "Null-Wissen" - der Anbieter weiß nichts über den Inhalt) ist hier die richtige Lösung: der Server kann den Inhalt nicht entschlüsseln, weil er den Schlüssel nie gesehen hat, auch nicht kurzzeitig. Das ist wesentlich stärker als Ende-zu-Ende-Verschlüsselung. Für Kurzmitteilungen mit hoher Vertraulichkeit (einmalig zu übertragende Passwörter, Zugangsdaten, Adressen, kurze Nachrichten) ist Zero-Knowledge der strukturell sauberste Schutz und zugleich eine Garantie: die tatsächlich übertragenen Daten lassen sich transparent in den DevTools (den eingebauten Entwicklerwerkzeugen des Browsers) nachvollziehen, der Verschlüsselungscode liegt offen im JavaScript.

Für wen ist das? Für alle, die kurze Geheimnisse sicher weitergeben müssen.

Kurze Antwort

Der Schlüssel verlässt nie den Browser, und genau das macht den Unterschied zu vielen "Ende-zu-Ende"-Diensten. Im Detail:

• Der Entschlüsselungs-Schlüssel entsteht im Browser des Senders als 32-Byte-Zufallswert (per crypto.getRandomValues()) und verschlüsselt den Inhalt mit AES-256-GCM (einem starken, gängigen Verschlüsselungsverfahren).
• Der Schlüssel landet im URL-Fragment (dem Teil hinter dem #). Dieses Fragment schickt der Browser nie an den Server.
• Der Server sieht nur Ciphertext (den verschlüsselten Text), Nonce und Salt (zwei technische Beiwerte), niemals den Klartext.
• Der Empfänger klickt den Link, sein Browser entschlüsselt lokal und zeigt den Klartext an.
• Bei One-View-Notes (einmal lesbaren Notizen) löscht der Server die Zeile beim ersten Abruf - danach existiert weder Klartext noch Chiffrat. Geht der Tab verloren, ist die Notiz unwiederbringlich weg.

Tiefgang

Das URL-Fragment als lokales Geheimnis

RFC 3986 definiert den Fragment-Bezeichner (der Teil nach #) explizit als clientseitig auszuwertend. Browser schicken das Fragment nicht im HTTP-Request an den Server, nicht im Referer-Header, nicht in Logs. Es ist die einzige Stelle in einer URL, die dem Server strukturell unzugänglich bleibt. Einfach nachzuprüfen in den DevTools Ihres Browsers.

Das macht das Fragment zum idealen Transportmittel für ein Geheimnis, das zeitgleich sehr benutzerfreundlich ist. Der Absender erzeugt den Schlüssel, verschlüsselt, speichert nur den chiffrierten Text auf dem Server. Dann baut er eine URL, die den Schlüssel ins Fragment hängt. Der Link kann in Messenger, E-Mail, Chat weitergereicht werden, jeder, der ihn vollständig erhält, kann die Notiz entschlüsseln - einmalig oder auch mehrmalig, optional um eine zweite, unabhängige, Verschlüsselung erweitert. Dann müssen beide Teile vorliegen um die Notiz entschlüsseln zu können.

Schlüsselerzeugung und Schema

Dernium macht die eingesetzte Verschlüsselung bewusst offen und nachprüfbar. Wir sind hier transparent und schreiben keine bloßen Marketing-Zeilen: Alles kann tatsächlich nachvollzogen und verifiziert werden.

Im Browser, mit Web Crypto API (der eingebauten Verschlüsselungs-Schnittstelle des Browsers):

const key = crypto.getRandomValues(new Uint8Array(32)); // 256 bit
const nonce = crypto.getRandomValues(new Uint8Array(12)); // 96 bit GCM
const subtleKey = await crypto.subtle.importKey(
 'raw', key, { name: 'AES-GCM' }, false, ['encrypt', 'decrypt']
);
const ciphertext = await crypto.subtle.encrypt(
 { name: 'AES-GCM', iv: nonce }, subtleKey, plaintextBytes
);
// Server bekommt: ciphertext || nonce || (optional) salt
// URL wird: https://notes.example.de/n/<id>#k=<base64url(key)>

Der Schlüssel geht ins Fragment und nicht an den Server. GCM liefert Authentizität mit; eine Manipulation am Ciphertext führt zum vollständigen Versagen beim Entschlüsseln - der gesamte Text wird unlesbar. Aufgrund von adaptivem Padding (einem Auffüllen auf gleichmäßige Längen) ist noch nicht einmal die konkrete Textlänge der verschlüsselten Notiz erkennbar.

Passwort als zweite Schicht

Für Fälle, in denen der Link selbst in falsche Hände geraten könnte (unsichere Kanäle wie Messenger, SMS, durchsichtiger Proxy), lässt sich ein zweiter Schlüssel aus einem vom Ersteller festlegbaren Passworts ableiten:

const salt = crypto.getRandomValues(new Uint8Array(16));
const passKey = await scrypt(password, salt, N=2**17, r=8, p=1, dkLen=32);
const finalKey = hkdfSha256(key, passKey);

Der Server speichert das Salt (einen öffentlichen Zufallswert, der die Ableitung pro Notiz einzigartig macht). Zum Entschlüsseln muss der Empfänger nun zusätzlich zum vollen Link das eingegebene Passwort kennen. Die Brute-Force-Kosten (der Aufwand fürs systematische Durchprobieren) hängen am scrypt-Parameter N; auf modernen Clients dauert eine Iteration einige zehntel Sekunden, was für einen einzelnen Zugriff in Ordnung ist und für Brute-Force massiv teuer. Sie werden in dem Fall merken, dass die Entschlüsselung einer Notiz nicht unmittelbar erfolgt. Das ist keine langsame Serververbindung sondern Arbeit, die auf Ihrem lokalen Rechner verrichtet wird. Auf mobilen Endgeräten kann es tatsächlich auch ein paar Sekunden dauern.

Die Lösch-Garantie

Zero-Knowledge schützt den Inhalt; bei der Einmalkeits-Garantie ist die verlässliche Löschung aber ebenso wichtig. Derniums Umsetzung:

• One-View-Notes: atomarer DB-Delete ... WHERE id = $1 AND consumed_at IS NULL RETURNING * (eine Datenbank-Operation, die in einem einzigen, unteilbaren Schritt löscht und zurückgibt). Nur eine parallele Leseanfrage gewinnt; alle anderen bekommen NotFound.
• Zeitfenster-Notes: expires_at-Spalte, Cleanup-Job löscht abgelaufene Zeilen. Bis dahin Zugriff möglich, danach physisch gelöscht.
• Backups enthalten höchstens Ciphertext. Der Entschlüsselungs-Schlüssel liegt nie auf dem Server (er steht nur im URL-Fragment beim Empfänger). Selbst wenn ein Restore eine bereits gelöschte Notiz zurückbrächte, wäre das nur unentschlüsselbarer Ciphertext - ohne den clientseitigen Schlüssel nicht lesbar.
• Kein Support-Override. Es gibt keine Möglichkeit, einen verlorenen Schlüssel wiederherzustellen. Das ist Produktmerkmal und bewusst per Design, kein Defekt und auch wir haben keine Möglichkeit das zu umgehen. Dadurch können wir auch nicht z.B. gezwungen werden Inhalte von Notizen zu verraten: wir können beweisen (und das kann auch unabhängig von Extern verifiziert werden), dass wir weder Inhalte noch Textlängen jemals selbst lesen können. Damit können wir sie auch niemandem zur Verfügung stellen.

Abgelehnte Alternativen und Mythen

"Wir speichern den Schlüssel kurz am Server und werfen ihn danach weg -> "Ende-zu-Ende-Verschlüsselung" als Schutzversprechen" Der Schlüssel war am Server. Eine Speicher-Forensik oder ein Insider mit Zugriff auf den Prozess können den kurzlebigen Schlüssel abgreifen. Zero-Knowledge schließt das strukturell aus da das Geheimnis niemals an einem Ort liegt von wo er abgegriffen werden könnte.

"Wir nutzen PGP." Funktional eine sehr starke Lösung, aber operativ komplex: jeder Empfänger braucht einen Schlüssel, Key-Management ist nicht gelöst, Messenger und Webmail-Clients unterstützen PGP unterschiedlich. Zero-Knowledge-Kurztext-Dienste sind deutlich niederschwelligere Alternativen und gegen künftige Quantenangriffe robust (symmetrisches AES-256 verliert durch Grovers Algorithmus nur die halbe effektive Schlüssellänge und bleibt damit ausreichend stark).

"Ein S3-Bucket mit Client-seitigem Krypto." Funktioniert, aber die Lösch-Garantie muss separat gebaut werden. One-View-Semantik im Client durchzusetzen ist fragil (der Client kann mehrfach aufrufen); zuverlässig ist sie nur serverseitig wo sie ohne Einfluss des Endnutzers erzwungen werden kann.

"Das Fragment lässt sich per JavaScript abfangen." Nur, wenn auf der Seite selbst feindlicher JavaScript-Code läuft. Deshalb gehören zu Zero-Knowledge-Diensten eine scharfe CSP (Content Security Policy, eine Browser-Regel, die fremden Code blockiert) ohne inline-Scripts (siehe kommender Beitrag dieser Serie) und ein minimal gehaltener Bundle. Kein Drittanbieter-JavaScript, kein CDN, kein Analytics.

Was Sie jetzt tun sollten

1. Prüfen Sie nach, dass der Schlüssel wirklich im Fragment bleibt. Öffnen Sie die DevTools (Taste F12), den Netzwerk-Tab, und rufen Sie eine Notiz ab. In keinem Request darf der Teil hinter dem # auftauchen - nur die id.
2. Schicken Sie sensible Inhalte als One-View-Note. Für einmalig zu übertragende Passwörter und Zugangsdaten ist die einmal lesbare Notiz die richtige Wahl - sie kann hinterher nicht aus Verläufen erneut abgegriffen werden.
3. Setzen Sie bei unsicheren Kanälen ein Zusatz-Passwort. Wenn Sie den Link über Messenger oder SMS teilen, vergeben Sie ein Passwort und nennen Sie es dem Empfänger auf einem anderen Weg (Telefon). So nützt ein abgefangener Link allein nichts.
4. Den Empfänger auf den Browser-Verlauf hinweisen. Der Link mit Schlüssel steht im Verlauf. Bitten Sie den Empfänger, den Eintrag nach dem Lesen zu löschen, oder im privaten Fenster zu öffnen.
5. Bei E-Mail-Versand mit Vorschau-Crawlern rechnen. Manche Mail-Dienste öffnen Links automatisch und können eine One-View-Note vorzeitig verbrauchen. Der Klick-Warte-Schritt mildert das ab; im Zweifel den Link nicht per Mail, sondern per Chat senden.

Wie Dernium hier hilft

Dernium Note implementiert den im Beitrag beschriebenen Flow direkt: Schlüssel-Erzeugung im Browser mit crypto.getRandomValues(), AES-256-GCM-Verschlüsselung, Schlüssel-Transport im URL-Fragment, atomarer One-View-Delete, kein Support-Override. Optional scrypt-basiertes Passwort-Hardening als zweite Schicht on-top, konfigurierbare TTL (Lebensdauer) für Zeitfenster-Notes; serverseitig liegt stets nur Ciphertext, der Schlüssel nie.

Verifikation

• RFC 3986 (URI-Syntax), Abschnitt 3.5 zum Fragment.
• Web Crypto API: MDN-Dokumentation.
• Offene Vergleichs-Implementationen: PrivateBin, OneTimeSecret, Bitwarden Send. Jeder Code ist einsehbar, jeder Prüfer kann nachvollziehen, wo der Schlüssel entsteht und wohin er geht.
• Tests: HTTP-Logs auf dem Server auf Suche nach dem Fragment-Wert, er darf nie auftauchen. DevTools-Netzwerk-Tab beim Abruf: nur die id, nicht der Schlüssel im Request.

Offene Punkte

Browser-Verlauf. Das Fragment steht in der URL des Browser-Verlaufs. Wer Einmal-Notizen verwendet, sollte das dem Empfänger bewusst machen, der Verlauf ist eine Kopie des Schlüssels für die Dauer der Browser-Historie. Informationen lassen sich hieraus keine mehr ziehen - außer, dass Dernium Note verwendet wurde. Bei mehrfach (zeitlich begrenzt) abrufbaren Notizen ist hierüber ein Zugriff möglich. Optimal schützt man sich hier mit einem Passwort als zweite Verteidigungslinie.

Mail-Preview. Manche Mail-Dienste (Outlook, ...) holen URLs im Link vor, um Previews zu bauen. Wenn der Preview-Crawler den Link öffnet, wird eine One-View-Note vor dem eigentlichen Empfänger konsumiert. Das ist ein reales Problem und lässt sich nur abmildern (nicht heilen): Dernium implementiert hier einem Klick-Warte-Schritt, bei dem der Empfänger aktiv bestätigt, bevor die Note freigegeben wird.

Häufige Fragen

Worin unterscheidet sich Zero-Knowledge von Ende-zu-Ende-Verschlüsselung?

Bei Ende-zu-Ende-Verschlüsselung kann der Schlüssel - je nach Umsetzung - kurzzeitig beim Anbieter durchlaufen, der dann verspricht, ihn nicht zu speichern. Bei Zero-Knowledge sieht der Server den Schlüssel nie, weil er den Browser nie verlässt. Das ist kein Versprechen, sondern eine strukturelle Eigenschaft, die jeder selbst in den Entwicklerwerkzeugen des Browsers nachprüfen kann.

Was passiert, wenn ich den Link mit dem Schlüssel verliere?

Dann ist die Notiz unwiederbringlich verloren. Es gibt bewusst keine Wiederherstellung und keinen Support-Override. Das ist gewollt: Genau weil der Anbieter den Inhalt nie lesen kann, kann er ihn auch niemandem - auch keiner Behörde - herausgeben. Für wichtige Inhalte gilt deshalb: erst nach erfolgreichem Empfang den Link verwerfen.

Kann jemand den verschlüsselten Text auf dem Server angreifen?

Der Server hält nur den Ciphertext, einen Nonce und ein optionales Salt. Ohne den Schlüssel aus dem URL-Fragment ist daraus nichts zu gewinnen - moderne symmetrische Verschlüsselung wie AES-256-GCM ist nach heutigem Stand nicht zu brechen. Durch adaptives Padding ist nicht einmal die Textlänge erkennbar.

Wozu dient das zusätzliche Passwort?

Es schützt den Fall, dass der Link selbst in falsche Hände gerät, etwa über einen mitgelesenen Messenger. Aus dem Passwort wird mit dem Verfahren scrypt ein zweiter Schlüssel abgeleitet, der mit dem ersten kombiniert wird. Ohne beides - vollständiger Link und Passwort - lässt sich die Notiz nicht öffnen. Geben Sie das Passwort idealerweise über einen anderen Kanal weiter als den Link.

Warum löscht Dernium One-View-Notes serverseitig statt im Browser?

Weil eine reine Browser-Logik umgangen werden kann - ein Client lässt sich zu mehrfachem Abruf überreden. Die Einmaligkeit wird deshalb in der Datenbank in einem einzigen, unteilbaren Schritt erzwungen: Nur die erste Leseanfrage erhält den Inhalt, alle weiteren bekommen "nicht gefunden". So ist die Garantie nicht vom Wohlverhalten des Endgeräts abhängig.