Damit du uns wiederfindest

Die Technik

Warum wir deine Nachricht nicht lesen können

Sicherheit ist hier kein Versprechen, sondern eine Eigenschaft des Systems: Deine Nachricht wird in deinem Browser verschlüsselt, bevor sie uns erreicht, und der Schlüssel dazu erreicht uns technisch nie. Auf dieser Seite steht ganz genau, wie das funktioniert – nachvollziehbar auch ohne Vorwissen, präzise genug für Leute, die es fachlich prüfen wollen.

Verschlüsselung
AES-256-GCM
Schlüssel
256 Bit, nur im Link
Passwort-Härtung
PBKDF2-SHA256 · 600.000 Runden
Schlüsselableitung
HKDF-SHA256
Ausgeführt in
deinem Browser (WebCrypto)
Der Link

Ein Link, zwei Welten

Das ganze System steckt in einem einzigen Trick: Der Link besteht aus zwei Teilen, die niemals denselben Weg nehmen.

Der Zugriffscode

Der Teil vor der Raute ist eine zufällige Kennung aus 128 Bit (16 Zufallsbytes, hexadezimal). Sie sagt unserem Server nur, welchen verschlüsselten Datensatz er heraussuchen soll – über den Inhalt verrät sie nichts. Raten ist aussichtslos: Selbst wer eine Milliarde Kennungen pro Sekunde durchprobiert, bräuchte im Mittel länger, als das Universum existiert.

Der Schlüssel

Alles hinter der Raute heißt URL-Fragment – und Browser übertragen diesen Teil einer Adresse grundsätzlich nie an einen Server. Das ist seit Jahrzehnten festgeschriebenes Web-Standardverhalten, kein Feature von uns. Der Schlüssel taucht deshalb in keinem Request, keinem Server-Log und keinem Proxy auf. Er existiert nur im Link selbst.

Chiffretext und Schlüssel sind damit physisch getrennt: Der Chiffretext liegt bei uns, der Schlüssel nur im Link. Wer eines von beidem hat, hat nichts.

Beim Absenden

Was passiert, wenn du auf „Verschlüsseln" klickst

  1. Schritt 1

    Dein Browser würfelt den Schlüssel

    32 Bytes – 256 Bit – aus dem kryptographischen Zufallsgenerator deines Browsers (WebCrypto, gespeist aus der Entropie deines Betriebssystems). Nicht aus Math.random(), das vorhersagbar wäre. 2²⁵⁶ Möglichkeiten sind mehr, als es geschätzte Atome im sichtbaren Universum gibt.

  2. Schritt 2

    Verschlüsselt wird lokal

    Dein Text wird mit AES-256-GCM verschlüsselt – vollständig in deinem Browser. Hast du ein Passwort gesetzt, wird es vorher mit 600.000 PBKDF2-Runden gestreckt und per HKDF mathematisch untrennbar in den Schlüssel eingerechnet. Der Klartext verlässt dein Gerät zu keinem Zeitpunkt.

  3. Schritt 3

    Nur der Chiffretext geht hoch

    An unseren Server geht ein „Envelope": Chiffretext, Salt und IV – alles Werte, die ohne den Schlüssel wertlos sind. Der Schlüssel selbst wird erst danach, in deinem Browser, an den Link angehängt: hinter der Raute, in dem Teil, den Browser nie übertragen.

Die Bausteine

Vier Standardverfahren, keine Eigenbauten

Gute Kryptographie erfindet man nicht selbst – man setzt geprüfte Standards richtig zusammen. Diese vier arbeiten hier:

AES-256-GCM

Verschlüsselung

AES ist seit 2001 der weltweite Standard für symmetrische Verschlüsselung – im Einsatz bei Banken, Behörden und praktisch jeder HTTPS-Verbindung, in über zwanzig Jahren öffentlicher Analyse nie praktisch gebrochen. „256" ist die Schlüssellänge in Bit, die stärkste Variante. GCM ist der Betriebsmodus und leistet zwei Dinge zugleich: Er verschlüsselt, und er berechnet ein 16-Byte-Echtheitssiegel (Authentication-Tag) über den Chiffretext. Beim Entschlüsseln wird dieses Siegel zuerst geprüft: Stimmt auch nur ein Bit nicht – falscher Schlüssel, falsches Passwort, manipulierte Daten –, schlägt die Entschlüsselung sauber fehl, statt Zeichensalat auszugeben, der wie eine Nachricht aussieht.

ct = AES-256-GCM(key, iv, Klartext)

PBKDF2-SHA256

Passwort-Härtung

Menschen wählen schwache Passwörter – PBKDF2 macht daraus trotzdem brauchbares Schlüsselmaterial, durch absichtliche Langsamkeit: Das Passwort wird 600.000-mal hintereinander durch HMAC-SHA256 gerechnet (der von der OWASP empfohlene Wert). Für den Empfänger ist das ein einmaliger Sekundenbruchteil; für einen Angreifer kostet jeder einzelne Rateversuch 600.000 Rechenschritte. Ein zufälliges Salt pro Nachricht macht vorberechnete Tabellen nutzlos, und die Rundenzahl steht mit im Envelope – wir können sie künftig erhöhen, ohne alte Nachrichten zu brechen.

pk = PBKDF2-SHA256(Passwort, salt, 600.000)

HKDF-SHA256

Schlüsselableitung

HKDF verrührt den Link-Schlüssel und das gestreckte Passwort zum eigentlichen AES-Schlüssel. Das ist mehr als Zusammenkleben: Der finale Schlüssel entsteht mathematisch aus beiden Zutaten gemeinsam, es gibt kein „halb entschlüsseln und den Rest raten". Ein fest eingebauter Kontext-Text („easysafeshare:v1:aes-gcm") sorgt zusätzlich dafür, dass dieselben Bytes in keinem anderen Zusammenhang denselben Schlüssel ergeben würden – Domain Separation, wie das Lehrbuch es verlangt.

key = HKDF-SHA256(fk ‖ pk, salt, info)

CSPRNG

Zufall

Jeder Schlüssel, jedes Salt und jede IV kommt aus crypto.getRandomValues() – dem kryptographisch sicheren Zufallsgenerator, den dein Browser aus der Entropie des Betriebssystems speist. Das ist derselbe Zufall, mit dem dein Browser auch TLS-Verbindungen absichert. Vorhersagbarer Zufall wäre die klassische Hintertür schlecht gebauter Krypto – hier ist er per Konstruktion ausgeschlossen, und WebCrypto steht überhaupt nur auf HTTPS-Seiten zur Verfügung.

fk = 32 Zufallsbytes, salt = 16, iv = 12
Die Konstruktion

Die komplette Formel

So setzt dein Browser die Bausteine zusammen – Zeile für Zeile genau das, was unser veröffentlichter Code tut:

fk = 32 Zufallsbytes in den Link hinter #, wird nie übertragen
salt = 16 Zufallsbytes offen im Envelope – kein Geheimnis
pk = PBKDF2-SHA256(Passwort, salt, 600.000) nur wenn ein Passwort gesetzt ist
key = HKDF-SHA256(fk ‖ pk, salt, info) beide Faktoren, untrennbar verrechnet
ct = AES-256-GCM(key, iv, Klartext) iv = 12 Zufallsbytes pro Nachricht

Und das ist alles, was in unserer Datenbank liegt:

{
  "v": 1,
  "alg": "AES-GCM",
  "salt": "Jm3qJdgQ…",
  "iv": "p0XwR2Ka…",
  "ct": "T9zKfLm2wQvXr8…",
  "kdf": "PBKDF2-SHA256",
  "iter": 600000
}

Salt und IV sind keine Geheimnisse – sie sorgen nur dafür, dass gleiche Nachrichten nie gleichen Chiffretext ergeben. Das einzige, was diesen Datensatz öffnen kann, ist der Schlüssel aus dem Link. Er war nie hier. Ein Diebstahl unserer kompletten Datenbank – statistisch die häufigste Art, wie Daten wirklich abhandenkommen – erbeutet deshalb nur unlesbare Blöcke.

Beim Öffnen

Was passiert, wenn der Empfänger den Link öffnet

  1. Schritt 1

    Die Seite lädt – und verrät nichts

    Der Aufruf der Seite liefert nur die Information, dass es die Nachricht gibt und ob sie ein Passwort braucht. Der Chiffretext wird noch nicht ausgeliefert. Deshalb kann keine Link-Vorschau in Messengern, kein Crawler und kein Virenscanner die Nachricht versehentlich „verbrauchen".

  2. Schritt 2

    Ein Klick, eine Auslieferung

    Erst der Klick auf „Öffnen" holt den Envelope ab. Bei selbstzerstörenden Nachrichten löscht die Datenbank den Datensatz in derselben Operation, die ihn ausliefert – atomar. Öffnen zwei Personen den Link in derselben Millisekunde, bekommt ihn genau eine; das garantiert die Datenbank, nicht unser Anwendungscode.

  3. Schritt 3

    Entschlüsselt wird wieder lokal

    Der Browser des Empfängers liest den Schlüssel aus dem Fragment, rechnet denselben Weg rückwärts und prüft dabei das GCM-Siegel. Ein vertipptes Passwort ergibt eine saubere Fehlermeldung – und kostet die Nachricht nicht: Der Envelope bleibt im Speicher des Browsers, der nächste Versuch läuft lokal, ohne Serverkontakt. Nach dem Entschlüsseln wird der Schlüssel aus der Adresszeile entfernt.

Die Nagelprobe

Was ein Angreifer wirklich erbeutet

Die ehrlichste Art, ein Sicherheitssystem zu beschreiben: durchspielen, was jemand mit dem bekommt, was er stehlen kann.

  • Unsere komplette Datenbank

    Nur Chiffretexte, Salts und IVs. Der Schlüssel jeder einzelnen Nachricht steckt im jeweiligen Link – er war nie auf unserem Server, also ist er auch in keiner Kopie unseres Servers.

    Nichts lesbar

  • Der Link – aber ein Passwort ist gesetzt

    Der AES-Schlüssel entsteht erst aus Link-Schlüssel und Passwort gemeinsam. Ohne das Passwort bleibt nur ein Brute-Force-Versuch, bei dem jeder einzelne Kandidat 600.000 PBKDF2-Runden kostet.

    Nichts lesbar

  • Nur das Passwort

    Ohne den Link fehlen 256 Bit echter Zufall. Es gibt nichts, worauf man das Passwort anwenden könnte – nicht einmal den Chiffretext, denn der Zugriffscode fehlt ebenfalls.

    Nichts lesbar

  • Link und Passwort zusammen

    Wer beides hat, ist aus Sicht der Mathematik der legitime Empfänger. Genau deshalb gehören Link und Passwort in getrennte Kanäle – den Link per E-Mail, das Passwort per Telefon. Ein Angreifer müsste dann beide Kanäle gleichzeitig kompromittieren.

    Lesbar

Bei selbstzerstörenden Nachrichten kommt hinzu: Ein abgefangener und gelesener Link fällt auf, denn die Nachricht ist danach sichtbar weg. Heimlich mitlesen geht nicht.

Ehrlichkeit

Was auch diese Technik nicht kann

Ein Sicherheitsversprechen ist nur so viel wert wie die Klarheit über seine Grenzen. Diese drei gelten für jede browserbasierte Verschlüsselung – auch für unsere.

  • Das Gerät des Empfängers

    Wer die Nachricht öffnen darf, kann sie abfotografieren oder kopieren – kein Programm der Welt verhindert eine Kamera vor dem Bildschirm. Auch eine Browser-Erweiterung mit Vollzugriff auf Seiteninhalte könnte den Klartext lesen. Verschlüsselung schützt den Weg, nicht das Ziel.

  • Ein kompromittierter Server

    Würde jemand unseren Server übernehmen, könnte er manipuliertes JavaScript ausliefern, das Schlüssel abgreift. Das ist die prinzipielle Obergrenze jeder Browser-Kryptographie. Unsere Antwort darauf ist eine strikte Content-Security-Policy: Der Browser führt ausschließlich unser eigenes, pro Aufruf signiertes Skript aus – eingeschleuster Fremdcode wird blockiert.

  • Der komplette Link samt Passwort

    Wer vor dem Empfänger an Link und Passwort kommt, kann die Nachricht öffnen. Die Mathematik kann Besitz nicht von Diebstahl unterscheiden – die Trennung der Kanäle ist deine Aufgabe als Absender. Wir machen sie dir so leicht wie möglich.

Überzeug dich selbst

Alles auf dieser Seite kannst du nachprüfen: Öffne die Entwicklerwerkzeuge deines Browsers, verschlüssle eine Testnachricht und sieh selbst nach, was dein Browser an uns überträgt – und was nicht.

Jetzt eine Nachricht verschlüsseln