Ende-zu-Ende-Verschlüsselung

Der Großteil des Webs verschlüsselt bereits auf zwei andere Arten. Die Transportverschlüsselung (TLS, das Schloss) schützt Daten zwischen deinem Gerät und einem Server, doch der Server liest sie danach. Die Verschlüsselung ruhender Daten schützt eine Festplatte, aber das Unternehmen, das sie betreibt, hält meist auch den Schlüssel. Ende-zu-Ende nimmt den Schlüssel aus den Händen des Unternehmens: Selbst ein Einbruch in den Server, eine Anordnung an den Betreiber oder ein neugieriger Mitarbeiter erbeuten nur unlesbare Bytes. Messenger haben den Gedanken vertraut gemacht: Eine Nachricht wird auf einem Telefon versiegelt und auf einem anderen geöffnet, sodass nicht einmal das Unternehmen dazwischen weiß, was sie sagt, nur dass etwas verschickt wurde. Offene Entwürfe wie das Signal-Protokoll zeigen, dass der Ansatz von zwei Freunden bis zu großen Gruppen trägt.

In der Praxis erzeugt ein Gerät einen Schlüssel, verschlüsselt damit jedes Element vor dem Senden und gibt ihn nur an Geräte weiter, die du freigibst. Schwierig ist nicht das Verschlüsselungsverfahren, das Standard ist (AES-256-GCM ist weit verbreitet), sondern der Umgang mit den Schlüsseln: wie ein neues Gerät einen erhält und was geschieht, wenn du alle verlierst. Echte Ende-zu-Ende-Systeme antworten mit einem Passkey, einem Wiederherstellungsschlüssel oder einem bereits vertrauenswürdigen Gerät und nehmen einen Kompromiss in Kauf. Weil niemand sonst deine Daten öffnen kann, kann sie auch niemand sonst retten. Stell dir einen Brief in einer abgeschlossenen Kiste vor: Der Bote trägt die Kiste die ganze Strecke, aber nur wer den passenden Schlüssel hat, kann den Inhalt lesen.

Auch die Grenzen gehören dazu. Die Verschlüsselung schützt die Daten vor dem Server, nicht vor einem kompromittierten Gerät, einem gestohlenen entsperrten Telefon oder Schadsoftware. Und ein KI-Chat kann nicht bis zum Modell Ende-zu-Ende sein: Das Modell muss deinen Text lesen, um zu antworten. Der Begriff passt also auf Speicherung, Synchronisierung, Sicherungen und Freigabelinks, nicht auf den Live-Austausch mit dem Modell. Ein guter Test ist die Frage, wer den Schlüssel hält. Ist es der Betreiber, kann der Dienst verschlüsselt sein, aber nicht Ende-zu-Ende, und der Betreiber kann gezwungen oder gehackt werden.

Bei der ersten Nutzung erzeugt dein Browser einen nicht exportierbaren AES-256-GCM-Schlüssel: Die Seite kann damit ver- und entschlüsseln, aber kein Skript kann ihn als Bytes lesen, auch nicht unseres. Deine Unterhaltungen, Bilder, Charaktere und dein Gedächtnis werden damit verschlüsselt, bevor sie in die Datenbank deines Browsers geschrieben werden. Schaltest du die Synchronisierung in den Einstellungen ein, wird jedes Element in deinem Browser unter einem Datenschlüssel verschlüsselt, den unsere Server nie besitzen, und seine Kennung wird unkenntlich gemacht. Dieser Schlüssel ist mit deinem Passkey und deinem Wiederherstellungsschlüssel verpackt und für jedes freigegebene Gerät versiegelt; jede Synchronisierungsanfrage muss von einem freigegebenen Gerät signiert sein. Ohne Passkey, ohne Wiederherstellungsschlüssel und ohne ein anderes freigegebenes Gerät lässt sich unsere Kopie nicht mehr öffnen.

Auch Freigabelinks und deine Sicherung sind verschlüsselt, die Sicherung mit deiner Passphrase. Nicht Ende-zu-Ende ist die Antwort selbst: Deine Nachricht läuft über unsere Server zum Modell und zurück, und die Transparenzseite hält fest, dass sie weder in die Datenbank noch in die Protokolle geschrieben wird. Das erklärt auch, warum wir nur versiegelte Elemente speichern: Ein Datenbankleck würde unlesbare Bytes, aufgerundete Größen und Zeitstempel offenlegen, aber kein einziges Wort von dir.