Ende-zu-Ende- vs. Zero-Knowledge-Verschlüsselung: Was ist der Unterschied?

Q: Wogegen schützt jedes der beiden?

Kurze Antwort. Ende-zu-Ende-Verschlüsselung (E2EE) ist eine Eigenschaft der Kommunikation: Nur die beiden Endpunkte können die Nachricht lesen, Zwischenstationen nicht. Zero-Knowledge ist ein Betriebsmodell für Speicher: Der Server bewahrt Ihre Daten verschlüsselt auf, mit Schlüsseln, die er nicht hat. Die meisten modernen, auf Datenschutz ausgerichteten Dienste setzen beides um – Signal ist E2EE für Chats, Filarr ist Zero-Knowledge für die Cloud-Synchronisation. Die Begriffe überschneiden sich, sind aber keine Synonyme.

Die beiden Begriffe werden in Werbetexten, Sicherheitsblogs und sogar in wissenschaftlichen Arbeiten austauschbar verwendet. Sie bedeuten nicht dasselbe.

Dieser Artikel gibt die genaue Definition beider, zeigt, wo sie sich überschneiden und wo nicht, und wie Sie die Verschlüsselungsversprechen jedes auf Datenschutz ausgerichteten Dienstes bewerten.

Was ist Ende-zu-Ende-Verschlüsselung (E2EE)?

Ende-zu-Ende-Verschlüsselung ist eine Eigenschaft von Kommunikationssystemen. Die Definition ist einfach: Nur die beiden Endpunkte können den Inhalt lesen; kein System dazwischen, das die Nachricht weiterleitet, kann es.

Das Paradebeispiel ist der Signal Messenger. Wenn Sie eine Nachricht senden:

Ihr Telefon verschlüsselt die Nachricht mit einem Schlüssel, den das Telefon des Empfängers hat (und die Server von Signal nicht)
Der verschlüsselte Blob läuft über die Server von Signal
Das Telefon des Empfängers entschlüsselt ihn

Die Server von Signal sehen verschlüsselte Bytes hinein- und verschlüsselte Bytes hinausgehen. Sie sehen nie Klartext. Selbst wenn sie wollten, könnten sie es nicht – die Schlüssel verlassen die Geräte der Nutzer nie.

E2EE betrifft nicht nur Nachrichten. Dieselbe Eigenschaft gilt für:

Sprach- und Videoanrufe (Signal, FaceTime, WhatsApp)
E-Mail (Proton Mail, Tutanota)
Dateiübertragung (Wormhole, Magic Wormhole, OnionShare)
Gemeinsames Bearbeiten (manche E2EE-fähige Alternativen zu Google Docs)

Das bestimmende Merkmal ist immer dasselbe: Die Daten werden von einem Endpunkt verschlüsselt und nur vom anderen Endpunkt entschlüsselt. Die Server dazwischen sind blinde Kuriere.

Was ist Zero-Knowledge-Verschlüsselung?

Zero-Knowledge-Verschlüsselung ist eine Eigenschaft von Speicherdiensten. Die Definition: Der Server speichert Ihre Daten verschlüsselt mit Schlüsseln, die er nicht hat.

Im Vergleich zu E2EE hat Zero-Knowledge eine andere Form:

E2EE ist eine Eigenschaft einer Kommunikation zwischen Nutzern, von einem zu einem oder von einem zu vielen
Zero-Knowledge ist eine Eigenschaft der Beziehung eines einzelnen Nutzers zu seinem Cloud-Speicher

Das Lehrbuchbeispiel ist Bitwarden. Ihr Passworttresor wird auf Ihrem Gerät mit einem Schlüssel verschlüsselt, der aus Ihrem Master-Passwort abgeleitet wird. Der verschlüsselte Tresor wird auf die Server von Bitwarden hochgeladen. Dort liegt ein undurchsichtiger Blob. Wenn Sie sich auf einem anderen Gerät anmelden, entschlüsselt Ihr Master-Passwort den Tresor lokal – die Server von Bitwarden sehen ihn nie.

Weitere Zero-Knowledge-Dienste: 1Password, Proton Drive, Tutanota Calendar, die Cloud-Synchronisation von Filarr, Cryptomator (kombiniert mit einer beliebigen Cloud).

Wenn Sie Zero-Knowledge als „Kommunikation“ zwischen Ihrem früheren Ich (beim Hochladen) und Ihrem künftigen Ich (beim Herunterladen auf einem neuen Gerät) auffassen, wird es zu einem Sonderfall von E2EE. Aber die Einsatzmuster, Bedrohungsmodelle und technischen Herausforderungen unterscheiden sich so sehr, dass ein eigener Name gerechtfertigt ist.

Wo überschneiden sich E2EE und Zero-Knowledge?

In der Praxis setzen moderne, auf Datenschutz ausgerichtete Dienste oft beides zugleich um.

Eine typische verschlüsselte Notiz-App:

Nutzt Zero-Knowledge für den persönlichen Speicher – Ihre Notizen liegen verschlüsselt auf dem Server, und der Server kann sie nicht lesen
Nutzt E2EE, wenn Sie eine Notiz mit einem anderen Nutzer teilen – der Freigabelink oder die Einladung enthält einen verschlüsselten Schlüssel, den nur der Empfänger entschlüsseln kann

Ein einziges Produkt kann also beides sein. Filarr zum Beispiel ist Zero-Knowledge für den Speicher (Ihre verschlüsselten Blobs liegen auf Cloudflare R2, und die Server von Filarr können sie nicht lesen) und E2EE für das Teilen (siehe unten).

Wo überschneiden sie sich nicht?

Drei konkrete Fälle.

E2EE ohne Zero-Knowledge. Eine Messaging-App, die keine Nachrichten auf dem Server speichert (oder sie nur kurz verschlüsselt für die Zustellung aufbewahrt). Signal ist E2EE; der Server behält fast nichts.

Zero-Knowledge ohne E2EE. Ein persönlicher Tresor ohne Funktionen zum Teilen oder Kommunizieren. Ein Bitwarden-Nutzer allein, ein Filarr-Nutzer allein, der nichts teilt – die Daten sind auf dem Server nach dem Zero-Knowledge-Prinzip verschlüsselt, aber es gibt keinen „anderen Endpunkt“, weil es keine Kommunikation gibt.

Keines von beiden. Die meisten Cloud-Dienste. Google Drive verschlüsselt im Ruhezustand, aber Google hält die Schlüssel. Dropbox ebenso. iCloud ebenso (außer bei den Inhalten hinter Apples Schalter „Erweiterter Datenschutz“, die Zero-Knowledge sind).

Warum ist die Unterscheidung für Nutzer wichtig?

Die Unterscheidung zählt, wenn Sie ein Datenschutzversprechen bewerten. Betrachten Sie diese Aussagen:

„Wir verwenden Ende-zu-Ende-Verschlüsselung, um Ihre Daten zu schützen.“

Das ergibt bei einer Messaging-App Sinn. Bei einer Notiz-App oder einem Passwortmanager, der Daten in der Cloud speichert, ist „Ende-zu-Ende-Verschlüsselung“ technisch eine Dehnung – der Begriff gilt eigentlich für Kommunikation. Die richtige Aussage lautet „Zero-Knowledge“ oder „clientseitige Verschlüsselung ohne Schlüsselzugriff auf dem Server“.

Wenn Marketingteams „E2EE“ für Speicherprodukte verwenden, meint das in der Praxis meist dasselbe wie Zero-Knowledge, aber der lockerere Gebrauch kann Lücken verbergen. Lesen Sie die Architekturdokumentation, nicht die Werbeseite.

„Ihre Daten sind bei der Übertragung und im Ruhezustand verschlüsselt.“

Das sagt nichts darüber aus, wer die Schlüssel hält. Ein Dienst kann im Ruhezustand mit Schlüsseln verschlüsseln, die er selbst kontrolliert – das ist übliche Cloud-Sicherheit, kein Zero-Knowledge. Fragen Sie immer: Hat der Dienst eine Kopie des Entschlüsselungsschlüssels?

„Wir werden Ihre Daten niemals weitergeben.“

Ein Versprechen, keine Garantie. Mit Zero-Knowledge oder E2EE kann der Dienst Ihre Daten buchstäblich nicht weitergeben, weil er sie nicht lesen kann. Ohne eines von beiden vertrauen Sie darauf, dass der Dienst sein Versprechen hält, auch unter rechtlichem Druck.

Wogegen schützt jedes der beiden?

Bedrohung	Schützt E2EE?	Schützt Zero-Knowledge?	Schützt serverseitige Verschlüsselung?
Abhören des Netzwerks	✓	✓ (mit TLS)	✓ (mit TLS)
Server von Hackern kompromittiert	✓	✓	✗ (die Schlüssel liegen auf dem Server)
Betreiber des Dienstes liest Ihre Daten	✓	✓	✗
Behördliche Anfrage an den Dienst	✓	✓	✗
Mitarbeiter mit Datenbankzugriff	✓	✓	✗
Malware auf Ihrem Gerät	✗	✗	✗
Verlorenes Passwort/verlorener Wiederherstellungsschlüssel	✓, aber Daten nicht wiederherstellbar	✓, aber Daten nicht wiederherstellbar	✗ (der Dienst kann zurücksetzen)

E2EE und Zero-Knowledge bieten in ihrem jeweiligen Bereich denselben Schutz vor Bedrohungen. Der Unterschied liegt im Was – Kommunikation vs. Speicher – und im Wie.

Welche Fragen sollten Sie stellen, bevor Sie einem Dienst vertrauen?

Eine kurze Checkliste, wenn ein Dienst E2EE oder Zero-Knowledge verspricht:

Wo ist die Schlüsselableitung dokumentiert? Ein ernstzunehmender Dienst veröffentlicht seine KDF-Parameter (Speicher bei Argon2id, Iterationen bei PBKDF2) in seiner Sicherheits- oder technischen Dokumentation.
Was sieht der Server? Verschlüsselte Blobs, in Ordnung. Dateinamen im Klartext? Ordnerstruktur? Betreffzeilen? Jede preisgegebene Metadatenangabe ist ein möglicher Seitenkanal.
Was passiert beim Zurücksetzen des Passworts? Wenn der Dienst Ihr Passwort zurücksetzen und Sie wieder an Ihre Daten lassen kann, ist er nicht Zero-Knowledge. Echtes Zero-Knowledge bedeutet: Passwort verloren = Daten verloren (wiederherstellbar nur über Ihren eigenen Wiederherstellungscode).
Ist der Code öffentlich oder auditiert? Ein Versprechen ohne öffentlichen Nachweis ist ein Marketingversprechen. Unabhängige Audits und öffentlicher Code machen Versprechen überprüfbar.
Wie funktioniert das Teilen? Wenn der Dienst das Teilen unterstützt, sollte das Freigabemodell E2EE wahren – der Server sollte den geteilten Inhalt nie unverschlüsselt sehen.

Wenden Sie diese Fragen auf jeden verschlüsselten Dienst an, bevor Sie ihm Ihre Daten anvertrauen.

Wo steht Filarr auf dieser Skala?

Filarr ist ein Local-First-Arbeitsbereich, dessen Cloud-Synchronisation Zero-Knowledge ist. Übertragen auf das Raster oben:

Zuerst Local-First. Ihre Dateien liegen verschlüsselt auf Ihrer Festplatte. Damit die lokale App funktioniert, ist kein Server beteiligt – es gibt keine „Kommunikation“ und keinen „Speicher“, die die Cloud vermitteln müsste.
Zero-Knowledge-Cloud-Synchronisation. Wenn Sie sich für die Cloud-Synchronisation entscheiden, werden Ihre Dateien mit AES-256-GCM verschlüsselt, unter Ihrem Kontoschlüssel (dem FEK), mit einem neuen Zufallswert pro Datei, und als undurchsichtige Blobs hochgeladen. Der Server speichert die verschlüsselten Blobs, die unter Ihrem Passwort und Ihrer Wiederherstellungsphrase verpackten Kopien Ihres FEK und einen bcrypt-Hash, der Ihre Anmeldung prüft; er sieht nie Ihren FEK im Klartext oder irgendwelche Dateiinhalte. Seit dem 16. Oktober 2026 meldet sich eine aktuelle App mit einem aus Ihrem Passwort abgeleiteten Schlüssel an, nicht mit dem Passwort selbst. Während einer Übergangszeit von etwa zwei Monaten senden ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere App-Version noch das Passwort (über HTTPS), wo ein kompromittierter Server es abfangen könnte.
Kopplung mehrerer Geräte. Wenn Sie ein neues Gerät koppeln, sendet Ihr bestehendes Gerät Ihren Hauptschlüssel über einen ECDH-Handshake an das neue Gerät – verschlüsselt mit einem flüchtigen Sitzungsschlüssel, den der Server nicht ableiten kann. Der Server reicht die verschlüsselten Schlüsselbytes durch und sieht nichts Brauchbares.
Teilen. Seit der ersten Veröffentlichung dieses Artikels hat Filarr das Teilen eingeführt, und es ist E2EE. Ein Freigabelink trägt seinen Schlüssel nach dem #, den ein Browser nie an den Server sendet; der Schlüssel eines geteilten Tresors wird für das persönliche Schlüsselpaar jedes Mitglieds versiegelt, und der Server reicht ihn nur versiegelt weiter.

Was der Server von Filarr sehen kann: undurchsichtige verschlüsselte Blobs, Blobgrößen, Zeitstempel der Synchronisation, die E-Mail-Adresse des Kontos, die verpackten Kopien Ihres Schlüssels und einen bcrypt-Hash, der Ihre Anmeldung prüft. Was er nicht sehen kann: Dateiinhalte, Dateinamen, Ordnerstruktur, Notiztitel, die Namen geteilter Tresore und Freigabelinks oder Ihren Schlüssel im Klartext.

Lesen Sie die vollständige Sicherheitsarchitektur von Filarr für die genauen Parameter und das Bedrohungsmodell hinter jeder Designentscheidung.