--- title: VidraCrypt: Zero-Knowledge-Dateifreigabe im Browser url: https://www.vidrasec.com/de/blog/vidracrypt/ description: VidraCrypt ist ein Open-Source-Tool zum Teilen verschlüsselter Dateien im Browser, bei dem der Server weder Passphrase noch Klartext zu sehen bekommt. date: 2026-07-06 --- Bei einem Pentest muss ich Kunden regelmäßig Dinge schicken, die niemand gerne im Postfach liegen hat: den finalen Bericht, extrahierte Zugangsdaten, einen Dump als Nachweis für eine Schwachstelle. E-Mail und generische Filesharing-Tools eignen sich dafür schlecht. Deshalb habe ich [VidraCrypt](https://github.com/VidraSec/VidraCrypt) gebaut, ein kleines Open-Source-Tool, das Dateien vollständig im Browser entschlüsselt, ohne dass der Server jemals Passphrase oder Klartext zu sehen bekommt. ## Das Problem beim Versand sensibler Dateien Pentest-Deliverables gehören zu den sensibelsten Dokumenten, die ein Kunde je erhält. Ein Bericht beschreibt im Detail, wie man in das Netzwerk eindringt. Ein extrahierter Credential-Dump bleibt nutzbar, solange die Passwörter nicht geändert wurden. Wird das per normaler E-Mail oder über einen generischen Filesharing-Dienst verschickt, muss man jedem Mailserver, jedem Spamfilter und jedem Cloud-Anbieter dazwischen vertrauen. Manche Kunden haben bereits PGP oder S/MIME eingerichtet, das hilft beim Transport. Das größere Problem liegt aber meist gar nicht beim Transport: Sobald ein Bericht im Postfach landet, bleibt er dort meist einfach liegen. Weitergeleitet in anderen Threads, aufs Handy synchronisiert, vom Mail-Provider gesichert, noch Jahre später auffindbar, wenn alle Beteiligten längst vergessen haben, dass es ihn überhaupt gibt. Ein Dokument, das im Detail beschreibt, wie man das Netzwerk eines Kunden kompromittiert, sollte nicht zu einem dauerhaften, vergessenen Anhang im Postfach werden. Ich wollte einen Weg, eine Datei zu übergeben, die für niemanden außer dem vorgesehenen Empfänger lesbar ist, und die nicht standardmäßig als dauerhafte Klartextkopie in einem E-Mail-Archiv liegen bleibt. ## Wie VidraCrypt funktioniert VidraCrypt besteht aus einer statischen Webseite und einem kleinen Verschlüsselungsskript. Es gibt kein Backend, keine Datenbank und kein Benutzerkonto: * Die **Verschlüsselung** läuft auf meinem Rechner mit [age](https://github.com/FiloSottile/age) im Passphrase-Modus, mit einer `diceware`-Passphrase (sechs Wörter, Standardmethode). Das Skript `add-to-files.sh` übernimmt das: Es erzeugt für die verschlüsselte Datei immer einen zufälligen UUID-Dateinamen (damit der ursprüngliche Dateiname nie durchsickert) und schreibt einen Eintrag in einen lokalen Metadaten-Index. * Die **Entschlüsselung** läuft im Browser des Kunden mit [typage](https://github.com/FiloSottile/typage), einer JavaScript/WASM-Implementierung von `age`. Der Kunde öffnet einen Link, gibt die Passphrase ein, die ich ihm über einen anderen Kanal mitgeteilt habe (Signal, Telefonat), und die entschlüsselte Datei wird direkt aus seinem eigenen Browser heruntergeladen. Die verschlüsselte Datei selbst kann überall gehostet werden: ein Cloudflare-Pages-Bucket, S3, GitHub Pages. VidraCrypt ist das egal, da sie per einfachem `fetch()`-Aufruf abgeholt und clientseitig entschlüsselt wird. ### Der URL-Fragment-Trick Der Link sieht so aus: ``` https://your-host/app/#get= ``` Der interessante Teil ist das `#`. Alles nach einem `#` in einer URL ist ein Fragment, und Browser schicken das Fragment nie als Teil der HTTP-Anfrage an den Server. Es taucht nie in einem Webserver-Access-Log, einem CDN-Log oder einem Proxy dazwischen auf. Es existiert ausschließlich innerhalb des Browsers. Das bedeutet: Die URL, die auf die verschlüsselte Datei zeigt, und damit auch, welche Datei ein bestimmter Kunde erhalten hat, taucht in keinem Server-Log entlang des Weges auf. `decrypt.js` liest das Fragment clientseitig aus, dekodiert den base64url-String zurück in die eigentliche Datei-URL, validiert sie und holt erst danach den Ciphertext ab. Diese Validierung ist wichtig: Die App akzeptiert nur `https://`-URLs ohne eingebettete Zugangsdaten, ohne benutzerdefinierten Port und mit einem Pfad, der auf eine UUID endet. Das schließt den naheliegenden Missbrauchsfall aus, die Entschlüsselungsseite als offenen Redirector oder SSRF-Proxy für beliebige URLs zu missbrauchen. ## Absicherung Da das gesamte Sicherheitsmodell darauf beruht, dass der Browser genau dieses JavaScript und nichts anderes ausführt, setzt die App konsequent auf Browser-Security-Header: * Eine `Content-Security-Policy` mit `default-src 'none'` und ein `script-src`, das auf die exakten SRI-Hashes von `age-0.3.0.js` und `decrypt.js` gepinnt ist. Nichts anderes darf geladen oder ausgeführt werden. * `Cross-Origin-Opener-Policy` und `Cross-Origin-Embedder-Policy`, um die Seite von anderen Fenstern zu isolieren. * `Cache-Control: no-store` und `Clear-Site-Data: "*"`, damit von der Sitzung im Browser danach nichts zurückbleibt. * `require-trusted-types-for 'script'`, um die Angriffsfläche für DOM-XSS zu verringern. Die eingebundene Abhängigkeit `age-0.3.0.js` wird mit dokumentiertem Checksum in der README ausgeliefert, sodass jeder, der VidraCrypt selbst betreibt, vor dem Ausliefern prüfen kann, ob sie manipuliert wurde. Ein Punkt sei hier offen angesprochen: Das alles setzt voraus, dass der Server, der die App ausliefert, selbst vertrauenswürdig ist. Würde jemand den Host vollständig kompromittieren und `index.html` zusammen mit dem `Content-Security-Policy`-Header umschreiben, könnte er ein eigenes Skript (mitsamt passendem SRI-Hash) einschleusen und zum Beispiel die Passphrase beim Eintippen mitloggen. Das ist ein ziemlich unwahrscheinlicher Angriff, wer bereits diesen Zugriff hat, hat meist einfachere Optionen als auf eine Passphrase zu warten, aber es ist eine reale Einschränkung, die man benennen sollte: Im Web gibt es kein echtes Code-Signing wie bei nativen Apps, wo der Signaturschlüssel unabhängig vom Verteilungsweg ist. Content-Hashes über die CSP sind das nächstliegende Äquivalent, und die schützen vor Manipulation durch Dritte an dem, was ausgeliefert wird (ein kompromittierter CDN-Cache, eine bösartige Browser-Erweiterung, eingeschleuste Skripte von Drittanbietern), nicht aber davor, dass der Ursprungsserver selbst kompromittiert ist. ## Anwendung Eine Datei für einen Kunden verschlüsseln: ```bash ./add-to-files.sh --target-dir "encrypted-files" --base-url "https://files.example.com/bucket" "my-report.zip" ``` Das gibt die Passphrase aus (über einen separaten Kanal teilen) sowie einen fertigen `#get=...`-Link. Die verschlüsselte Datei dorthin hochladen, wohin die Base-URL zeigt, dem Kunden Link und Passphrase schicken, und er kann sie im Browser entschlüsseln, ohne irgendetwas zu installieren. Es gibt eine [Live-Demo](https://vidrasec.github.io/VidraCrypt/app/#get=aHR0cHM6Ly92aWRyYXNlYy5naXRodWIuaW8vVmlkcmFDcnlwdC9maWxlcy8wNjg2MTU1Mi1kZWI2LTRmNzEtYjk2Mi0xN2ZmOWE1NWYzMDc>) mit dem Test-Passwort `123`, wenn du den Ablauf selbst ausprobieren willst. ## Grenzen VidraCrypt soll keine Ende-zu-Ende-verschlüsselte Messaging-Lösung für extrem hohe Bedrohungsszenarien ersetzen. Die Passphrase muss den Kunden trotzdem irgendwie erreichen, und ist dieser Kanal kompromittiert, ist es auch die Datei. Außerdem wird vorausgesetzt, dass Browser und Gerät des Kunden nicht bereits kompromittiert sind, was für jede browserbasierte Kryptografie gilt. Umgekehrt gilt aber auch: Eine für sich allein durchgesickerte Passphrase reicht nicht aus, um an die Datei zu kommen. Die verschlüsselte Datei liegt hinter einer zufälligen UUID, die sich nicht erraten lässt, ein Angreifer braucht also zusätzlich den Link, der über einen anderen Kanal als die Passphrase verschickt wird. Gut gelöst ist damit das alltägliche Problem, eine sensible Datei zum Kunden zu bringen, ohne dass irgendwo außer auf dessen eigenem Rechner eine Kopie des Klartexts oder der Passphrase liegen bleibt. [**VidraCrypt ist nur eine von mehreren Maßnahmen, mit denen VidraSec Pentests durchgehend sicher durchführt. Kontaktiere VidraSec, wenn du einen Penetrationstest brauchst.**](/de/contact/)