Ende-zu-Ende-verschlüsselte Cloud-Sync
TL;DR: CookieVault verschlüsselte Cookie-Sync nutzt libsodiums XChaCha20-Poly1305 mit Argon2id-abgeleiteten Schlüsseln. Deine Cookies werden auf dem Gerät verschlüsselt, bevor sie den Browser verlassen, und der Sync-Server speichert nur undurchsichtigen Geheimtext — Geheimtext, den selbst CookieVault-Ingenieure nicht entschlüsseln können. Es ist eine Pro-Zero-Knowledge-Funktion.
Die Ende-zu-Ende-verschlüsselte Cookie-Sync ist ein Zero-Knowledge-Mechanismus, der deine Cookies geräteübergreifend im Gleichschritt hält und zugleich sicherstellt, dass der Cloud-Server nichts als nicht entschlüsselbaren Geheimtext speichert. Deine Passphrase leitet den Verschlüsselungsschlüssel auf deinem eigenen Gerät mit Argon2id ab; dieser Schlüssel berührt nie die CookieVault-Infrastruktur, was bedeutet, dass weder unsere Ingenieure noch eine Server-Kompromittierung noch eine rechtliche Forderung deine Cookies offenlegen können. Es ist das Pro-Stufen-Rückgrat, das sich CookieVault Editor und CookieVault Guardian teilen, und die kryptografische Grenze ist quelloffen, sodass die Behauptung überprüfbar statt versprochen ist.
Wie die Verschlüsselung funktioniert
Kurz gesagt: Deine Passphrase durchläuft auf dem Gerät Argon2id (memory-hard Schlüsselableitung), um einen Hauptschlüssel zu erzeugen. Jeder Cookie-Eintrag wird dann mit XChaCha20-Poly1305 aus libsodium versiegelt, bevor er den Browser verlässt. Der Server empfängt nur Geheimtext und einen Authentifizierungs-Tag; er sieht den Schlüssel nie.
Die Pipeline ist bewusst aus gut geprüften Primitiven gebaut statt aus maßgeschneiderter Kryptografie. Argon2id ist der memory-hard Algorithmus, der die Password Hashing Competition gewann, gewählt speziell, weil er GPU- und ASIC-Brute-Force-Angriffen gegen eine menschlich merkbare Passphrase widersteht. XChaCha20-Poly1305 ist eine authentifizierte Verschlüsselungs-Konstruktion mit einer 192-Bit-erweiterten Nonce — breit genug, um Nonces zufällig zu wählen, ohne praktisches Kollisionsrisiko, was eine ganze Klasse von Implementierungs-Fallstricken beseitigt.
Sechs Eigenschaften definieren das Design:
- Clientseitige Schlüsselableitung — Argon2id verwandelt deine Passphrase auf deinem Gerät in einen Schlüssel; der Schlüssel wird nie übertragen oder serverseitig gespeichert
- Verschlüsselung pro Eintrag — jedes Cookie wird einzeln mit XChaCha20-Poly1305 versiegelt, sodass ein einzelner beschädigter Blob nie den ganzen Tresor vergiftet
- Authentifizierter Geheimtext — der Poly1305-Tag erkennt jede Manipulation, sodass ein veränderter Blob abgewiesen statt stillschweigend in Müll entschlüsselt wird
- Subschlüssel pro Gerät — jeder Browser leitet einen Schnell-Entsperr-Subschlüssel ab, sodass er nicht in jedem Sync-Zyklus die vollen Argon2id-Kosten neu durchläuft
- Speicherung nur als Geheimtext — der Sync-Server hält undurchsichtige Blobs plus minimale Routing-Metadaten persistent, nie Klartext
- Offene kryptografische Grenze — der Ableitungs-, Verschlüsselungs- und Sync-Client-Code ist öffentlich, sodass der Datenpfad prüfbar ist
Ein weithin vertretenes Prinzip der angewandten Kryptografie ist, dass du vor dem Hochladen verschlüsseln solltest, statt dem Server zu vertrauen, dass er für dich verschlüsselt. Genau diese Grenze setzt CookieVault durch: Der Browser ist der einzige Ort, an dem je Klartext existiert.
Das Bedrohungsmodell
Kurz gesagt: Wir nehmen an, dass der Server vollständig kompromittiert werden kann, und gestalten so, dass es keine Rolle spielt. Server-Einbruch, Netzwerkabhören und eine Vorladung reduzieren sich alle auf “Angreifer hat Geheimtext”. Das eine Szenario, das Klartext offenlegt, ist ein Angreifer, der dein entsperrtes Gerät kontrolliert — wogegen kein Sync-System verteidigen kann.
Cookies sind Inhaber-Token: Wer ein gültiges Sitzungs-Cookie hält, ist für die Zielwebsite du. Die Browser-Dokumentation ist eindeutig, dass Cookies Sitzungs-Identifikatoren und Authentifizierungs-Zustand tragen1, was genau der Grund ist, warum es leichtsinnig wäre, sie im Klartext an einen Dritten zu synchronisieren. Das Bedrohungsmodell nimmt das ernst.
| Bedrohungsszenario | Was der Angreifer sieht | Ergebnis |
|---|---|---|
| Sync-Server vollständig eingebrochen | Undurchsichtiger XChaCha20-Geheimtext | Keine nutzbaren Cookies; kein Schlüssel auf dem Server |
| Netzwerk-MITM | TLS-umhüllter Geheimtext | Doppelt geschützt; nichts zu lesen |
| Rechtliche Forderung / Vorladung | Nur gespeicherter Geheimtext | Nichts Entschlüsselbares zum Herausgeben |
| Böswilliger Insider | Derselbe Geheimtext wie für alle | Zero-Knowledge bedeutet, es gibt keinen privilegierten Zugang |
| Gestohlenes, gesperrtes Gerät | Verschlüsselter lokaler Tresor | Braucht deine Passphrase zum Entsperren |
| Gestohlenes, entsperrtes Gerät | Klartext nach dem Entsperren | Außerhalb des Geltungsbereichs — schütze den Zugang auf Geräteebene |
Die ehrliche Grenze ist die letzte Zeile: Die Ende-zu-Ende-Verschlüsselung schützt Daten bei der Übertragung und im Ruhezustand auf dem Server, nicht einen Angreifer, der bereits an deinem entsperrten Browser sitzt. Dafür verlässt du dich auf Geräte-Login, Festplattenverschlüsselung und Bildschirmsperren — Verteidigungen, die unterhalb der Erweiterung liegen.
Free vs. Pro
Kurz gesagt: Die gesamte lokale Cookie-Arbeit ist für immer kostenlos. Die verschlüsselte geräteübergreifende Synchronisierung ist die Pro-Funktion (4 USD/Monat oder 36 USD/Jahr), weil sie die einzige Fähigkeit ist, die Server-Infrastruktur braucht. Die Krypto, die deine Daten schützt, ist unabhängig von der Stufe identisch.
| Fähigkeit | Free | Pro (4 USD/Mon. o. 36 USD/Jahr) |
|---|---|---|
| Lokales Cookie-Anzeigen / -Bearbeiten / -Löschen | Ja | Ja |
| Lokaler Export (JSON / Netscape / HAR) | Ja | Ja |
| Auto-Löschen beim Tab-Schließen (Guardian) | Ja | Ja |
| Geräteübergreifende verschlüsselte Sync | Nein | Ja |
| Cookie-Verlauf mit Rückgängig (30 Tage) | Nein | Ja |
| Verschlüsselte Profil-Sync | Nein | Ja |
| Zero-Knowledge-Architektur | Nicht zutreffend (lokal) | Ja |
Pro lohnt sich nur, wenn du mehr als ein Gerät nutzt und sie synchron halten willst, oder wenn du das Sicherheitsnetz des Cookie-Verlaufs mit Rückgängig willst. Ein Nutzer mit nur einem Gerät und reinem Lokal-Betrieb bekommt den gesamten Kern-Workflow kostenlos. Siehe die Preisseite für die vollständige Aufschlüsselung Free / Pro / Team.
Wie du die verschlüsselte Sync einrichtest
- Installiere CookieVault (Editor, Guardian oder beide) von der Download-Seite
- Öffne das Erweiterungs-Popup und klicke auf “Enable sync”
- Lege ein Pro-Konto an mit deiner E-Mail — das verarbeitet nur Abrechnung und Routing, nie deinen Schlüssel
- Wähle eine starke Passphrase und speichere sie in einem Passwort-Manager; sie ist das Einzige, das deine Daten je entschlüsseln kann
- Bestätige, dass die Schlüsselableitung auf dem Gerät läuft (das Popup zeigt “deriving key…”, während Argon2id arbeitet)
- Warte, bis der erste verschlüsselte Snapshot hochgeladen ist — alle ausgewählten Cookies werden vor der Übertragung versiegelt
- Installiere CookieVault auf einem zweiten Gerät und gib dieselbe Passphrase ein, um lokal denselben Schlüssel abzuleiten
- Prüfe, dass die Sync-Anzeige auf beiden Geräten grün wird; geänderte Einträge replizieren jetzt als verschlüsselte Blobs
Wenn du je die Passphrase änderst, leitet jedes Gerät einen neuen Schlüssel ab und verschlüsselt seinen lokalen Tresor vor dem nächsten Push neu. Es gibt keine serverseitige Neuverschlüsselung, weil der Server keinen Schlüssel zu verwenden hat.
Audit und Überprüfbarkeit
Kurz gesagt: Der Verschlüsselungscode ist quelloffen und reproduzierbar gebaut, sodass der Datenpfad heute überprüfbar ist. Ein unabhängiges Drittanbieter-Audit des Krypto-Stacks ist für Q3 2026 angesetzt, mit dem Bericht und allen Befunden vollständig veröffentlicht.
Vertrau-mir-Sicherheit ist keine Sicherheit. Weil der Ableitungs-, Verschlüsselungs- und Sync-Client-Code in öffentlichen, MIT-lizenzierten Repositories liegt, kann jeder bestätigen, dass der Schlüssel das Gerät nie verlässt und dass nur Geheimtext den Server erreicht. Chromes Erweiterungsmodell schränkt zusätzlich ein, worauf eine Erweiterung zugreifen kann2, und Cookies werden über die offizielle Browser-Cookie-API1 gelesen und geschrieben statt über einen privaten Kanal. Das geplante externe Audit soll ein zweites, unabhängiges Augenpaar hinzufügen; wir verlinken den Bericht von der Sicherheitsseite, sobald er vorliegt.
Siehe auch
- CookieVault Editor — der Cookie-Editor, der diese Sync-Engine nutzt
- CookieVault Guardian — die Auto-Löschen-Erweiterung, die sich dieselbe Pro-Sync teilt
- Sicherheit — das vollständige E2E-Verschlüsselungsdesign und Bedrohungsmodell
- Open Source — MIT-Lizenz, öffentliche Krypto-Grenze, reproduzierbare Builds
- Multi-Konto-Profile — verschlüsselte Profil-Snapshots, die auf die gleiche Weise synchronisieren
- Preise — Aufschlüsselung Free / Pro / Team
Footnotes
-
Der Browser-Cookie-Speicher, einschließlich Sitzungs- und Authentifizierungs-Cookies, ist von MDN unter https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies dokumentiert. CookieVault liest und schreibt Cookies nur über die offizielle Browser-Cookie-API. ↩ ↩2
-
Die Cookies-API der Chrome-Erweiterungen und ihr Berechtigungsmodell sind unter https://developer.chrome.com/docs/extensions/reference/api/cookies dokumentiert, was die einzige Schnittstelle definiert, die eine Erweiterung nutzen darf, um auf den Browser-Cookie-Speicher zuzugreifen. ↩