Vaulted
5-Minuten-Audit

Vaulteds Zero-Knowledge-Verschlüsselung selbst prüfen

Vertrau Sicherheits-Tools nicht einfach — überprüfe sie. Vier Browser-Tests, keine Installationen, fünf Minuten.

Die 60-Sekunden-Checkliste

Lies das zuerst kurz durch. Die detaillierte Anleitung unten behandelt jeden Schritt ausführlich.

  1. 1

    DevTools öffnen → Reiter Network

    Drücke in Vaulted Cmd+Option+I (macOS) oder F12 (Windows/Linux). Wechsle zum Reiter Network und filtere nach Fetch/XHR.

  2. 2

    Geheimnis erstellen und POST prüfen

    Gib einen erkennbaren Canary-String ein (z. B. CANARY-12345) und klicke auf Create. Finde die POST-Anfrage an /api/secrets. Öffne den Reiter Payload — du siehst nur Geheimtext (base64) und iv. Suche im Body nach deinem Canary; er ist nicht da.

  3. 3

    Den Share-Link prüfen

    Sieh dir den generierten Link an. Der Entschlüsselungsschlüssel steht nach dem # (dem URL-Fragment). Gemäß RFC 3986 senden Browser Fragmente nie an den Server — weder in Request-Zeilen, noch in Headern, noch in Referrern.

  4. 4

    Bestätigen, dass die Entschlüsselung clientseitig läuft

    Öffne den Link in einem neuen Tab. Die GET-Antwort von /api/secrets/[id] liefert nur Geheimtext. Suche im Sources-Panel nach crypto.subtle.decrypt — dieser Aufruf läuft in deinem Browser, nicht auf unserem Server.

Vaulted öffnen und starten →Bedrohungsmodell lesen

Was du prüfst

Vaulteds Versprechen ist konkret: Der Server sieht weder deinen Klartext noch deinen Verschlüsselungsschlüssel. Das lässt sich auf vier beobachtbare Eigenschaften herunterbrechen:

  1. Der Klartext erscheint in keiner Netzwerkanfrage.
  2. Der Verschlüsselungsschlüssel erscheint in keiner Netzwerkanfrage.
  3. Das URL-Fragment (wo der Schlüssel liegt) erreicht den Server nie.
  4. Die serverseitigen Daten allein können das Geheimnis nicht rekonstruieren.

Wenn alle vier zutreffen, ist die Architektur konstruktionsbedingt Zero-Knowledge — kein Marketing-Sprech nötig.

Test 1 — Klartext überquert die Leitung nie

  1. Öffne vaulted.fyi.
  2. Öffne DevTools und wechsle zum Reiter Network. Filtere nach Fetch/XHR.
  3. Gib einen erkennbaren String in das Geheimnis-Feld ein — zum Beispiel CANARY-12345.
  4. Klicke auf Create.

Du siehst eine einzelne POST an /api/secrets. Klicke darauf und schau in den Reiter Payload.

Der Body enthält ein ciphertext-Feld und ein iv-Feld. Beides sind base64url-kodierte Blobs. Suche im Payload nach CANARY-12345 — er ist nicht da. Der Klartext wurde im Browser verschlüsselt, bevor die Anfrage abgesendet wurde.

Wenn du gründlich sein willst, stelle die Netzwerkdrosselung auf „Slow 3G” und wiederhole den Test. Der Geheimtext sieht weiterhin wie Rauschen aus; der Klartext ist weiterhin nirgends zu finden.

Test 2 — Der Schlüssel überquert die Leitung ebenfalls nie

Nachdem du das Geheimnis erstellt hast, zeigt dir Vaulted einen Share-Link. Er sieht so aus:

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

Der Teil nach # ist das URL-Fragment. Gemäß RFC 3986 verarbeiten Browser Fragmente lokal — sie erscheinen nie in HTTP-Request-Zeilen, Headern oder Referrern.

So beweist du das:

  1. Kopiere den Share-Link.
  2. Öffne ihn in einem neuen Tab mit geöffnetem Network-Reiter in den DevTools.
  3. Finde die GET /s/abc123-Anfrage.
  4. Schau in den Reiter Headers — vollständige Request-URL, kein Fragment.
  5. Schau in den Reiter Request — kein Fragment.
  6. Prüfe document.referrer auf der nächsten Seite — Fragment entfernt.

Der Schlüssel, den der Empfänger zur Entschlüsselung des Geheimnisses braucht, war in der URL — blieb aber in seinem Browser. Der Server sah GET /s/abc123 und nichts weiter.

Test 3 — Der Server allein kann nicht entschlüsseln

Öffne ein Terminal und rufe das Geheimnis direkt per curl ab:

curl https://vaulted.fyi/api/secrets/abc123

Du erhältst ein JSON zurück, das ciphertext und iv enthält. Das ist der vollständige serverseitige Zustand deines Geheimnisses.

Versuche jetzt, das zu verstehen. Ohne den Schlüssel aus dem URL-Fragment kannst du es nicht. AES-256-GCM mit einem korrekt generierten Zufallsschlüssel ist für alle praktischen Zwecke von zufälligem Rauschen nicht zu unterscheiden. Ein vollständiger Datenbank-Dump von Vaulteds Servern würde genau das liefern — verschlüsselte Blobs und Metadaten.

Das ist die wörtliche Definition von Zero-Knowledge: Der Server speichert Daten, die er nicht lesen kann.

Test 4 — Die Verschlüsselung passiert in JavaScript, das du sehen kannst

Vaulted verwendet die Web Crypto API, eine Browser-Primitive — es gibt kein verschleiertes WASM oder natives Modul, das die Arbeit versteckt. Du kannst dabei zusehen, wie die Verschlüsselung stattfindet.

  1. Öffne in DevTools den Reiter Sources.
  2. Suche nach crypto.subtle.encrypt (nutze Cmd+Option+F für die globale Suche).
  3. Setze einen Breakpoint auf die Zeile, die crypto.subtle.encrypt aufruft.
  4. Löse eine neue Geheimnis-Erstellung aus.
  5. Der Breakpoint trifft. Inspiziere die Argumente: Du siehst deinen Klartext als Uint8Array, den AES-GCM-Schlüssel und einen frischen Zufalls-IV.
  6. Gehe über den Aufruf hinweg. Das Ergebnis ist der Geheimtext, der abgesendet wird.

Du schaust jetzt dabei zu, wie Klartext zu Geheimtext wird — in deinem Browser, vor jeder Netzwerkanfrage. Es gibt keinen anderen Weg, den die Daten nehmen könnten.

Was das beweist

  • Kein Klartext verlässt den Browser. Test 1.
  • Kein Schlüssel verlässt den Browser. Test 2.
  • Der Server kann mit dem, was er speichert, nicht entschlüsseln. Test 3.
  • Die Verschlüsselung ist real und passiert clientseitig. Test 4.

Das ist das gesamte Zero-Knowledge-Versprechen, in fünf Minuten an einem laufenden Produktionssystem demonstriert.

Was das nicht beweist

Verifizierung ist ehrliche Arbeit — es lohnt sich, klar über ihre Grenzen zu sein.

  • Die Tests beweisen das Verhalten in diesem Moment. Eine zukünftige Code-Änderung könnte die Eigenschaft brechen. Wenn du fortlaufende Gewissheit brauchst, abonniere das Changelog und führe die Tests regelmäßig erneut durch.
  • Sie schützen nicht vor deinem eigenen Gerät. Ein Keylogger oder eine bösartige Browser-Extension kann Klartext nach der Entschlüsselung lesen. Das liegt außerhalb der Kontrolle jeder Web-App.
  • Sie setzen voraus, dass das JavaScript, das du ausgeführt hast, das JavaScript ist, das Vaulted ausliefert. Ein gezielter Angreifer, der das CDN kompromittiert hat, könnte einem einzelnen Nutzer ein anderes Bundle ausliefern. Subresource Integrity und reproduzierbare Builds mildern das; siehe unser Bedrohungsmodell für alle Details.

Tiefer gehen

Wenn du mehr erfahren möchtest:

Das stärkste Argument für ein Sicherheits-Tool ist nicht sein Marketing. Es ist, dass du es auseinandernehmen und bestätigen kannst, dass es das tut, was es behauptet. Vaulted ist so gebaut, dass du das kannst.

Häufig gestellte Fragen

Fragen oder etwas Merkwürdiges entdeckt? Schreib an [email protected] — wir veröffentlichen unsere Richtlinie zur verantwortungsvollen Offenlegung und antworten innerhalb von 48 Stunden.
Geheimnis teilen →