# HideFile-Sicherheit: So funktioniert die Verschlüsselung und wo sie endet

HideFile verschlüsselt deine Dateien im Browser mit einem Schlüssel, der aus deinem Passwort entsteht, und legt das verschlüsselte Ergebnis dann in einem gewöhnlichen Foto, PDF oder Video ab. Deine Dateien und dein Passwort werden nicht an uns gesendet. Diese Seite nennt die Algorithmen und Parameter, listet genau auf, was die App sendet, und benennt die Grenzen offen, auch die, die ein sorgfältiger Leser uns vorhalten wird.

Zwei Gedanken halten den Rest der Seite zusammen. Die Verschlüsselung ist die Sicherheitsschicht: Ohne das Passwort sind die Inhalte unlesbar. Die Tarndatei (cover file) ist Tarnung: Sie verändert, wie die verschlüsselten Bytes für jemanden aussehen, der deine Dateien durchsieht, und macht sie für jemanden, der sie untersucht, nicht unsichtbar.

## Dein Passwort wird auf deinem Gerät zu einem Schlüssel

Wenn du eine gesperrte Datei erstellst, macht HideFile aus deinem Passwort mit **Argon2id** (Version 1.3) einen Schlüssel, einer speicherintensiven Schlüsselableitungsfunktion (key derivation function). Speicherintensiv heißt: Jeder Versuch kostet einen Speicherblock und Zeit, sodass das Raten auch auf zum Raten gebauter Hardware langsam bleibt.

Der Aufwand hängt davon ab, wo die Datei erstellt wird. In einem Desktop-Browser nutzt Argon2id 64 MiB Speicher und 3 Iterationen auf einer einzelnen Lane. Ein Browser, der ein Handy oder Tablet meldet oder 4 GB Speicher oder weniger, bekommt 19 MiB, 2 Iterationen und eine einzelne Lane, weil ein Handy-Browser nicht zuverlässig 64 MiB pro Entsperrvorgang aufbringen kann, ohne zu scheitern. Diese niedrigere Einstellung erfüllt die Mindestempfehlung von OWASP für Argon2id. Die Parameter werden in der gesperrten Datei gespeichert, eine auf dem Desktop erstellte Datei behält ihren 64-MiB-Aufwand also auch, wenn du sie auf dem Handy öffnest.

Jede gesperrte Datei bekommt ein zufälliges 16-Byte-Salt, das mit ihr gespeichert wird. Zwei Personen mit demselben Passwort landen trotzdem bei verschiedenen Schlüsseln, sodass niemand eine einzige Tabelle mit Rateversuchen vorab berechnen und gegen jede Datei einsetzen kann.

## Deine Dateien werden mit XChaCha20-Poly1305 versiegelt

Der Schlüssel aus deinem Passwort verschlüsselt deine Dateien nicht direkt. Jede gesperrte Datei hat ihren eigenen zufälligen 256-Bit-Dateischlüssel, der auf deinem Gerät erzeugt wird. Der Passwortschlüssel umhüllt diesen Dateischlüssel, und der Dateischlüssel versiegelt deine Dateien.

Zum Versiegeln dient **XChaCha20-Poly1305**, eine authentifizierte Chiffre: Sie hält die Inhalte privat und erkennt Manipulation. Dateien werden als Datensätze gespeichert, jeder mit eigener zufälliger 192-Bit-Nonce und einem Poly1305-Authentifizierungs-Tag. Wird ein Datensatz verändert, ob durch eine beschädigte Kopie oder absichtlich, schlägt das Entsperren mit einer Fehlermeldung fehl, statt stillschweigend falsche Inhalte zu liefern.

<figure><img src="/docs/guides/img/product/security-encryption-flow.svg" alt="Im Browser: Das Passwort und ein zufälliges 16-Byte-Salt gehen in Argon2id (64 MiB und 3 Durchläufe, oder 19 MiB und 2 Durchläufe auf Handys und Browsern mit wenig Speicher) und ergeben einen 32-Byte-Passwortschlüssel. Dieser Schlüssel umhüllt einen zufälligen 256-Bit-Dateischlüssel. XChaCha20-Poly1305 versiegelt die Dateien in Datensätzen, jeweils mit zufälliger 192-Bit-Nonce und einem Manipulations-Tag. Die versiegelten Datensätze werden in der Tarndatei gespeichert." loading="lazy" width="100%"><figcaption>Ein Passwort, zwei Schlüssel. Der Passwortschlüssel umhüllt immer nur den Dateischlüssel.</figcaption></figure>

Beide Algorithmen stammen aus den Open-Source-Bibliotheken von RustCrypto (den Crates argon2 und chacha20poly1305). Unser eigener Kern, in Rust geschrieben, nutzt sie und läuft in deinem Browser, kompiliert zu WebAssembly. Derselbe Kern läuft überall, wo HideFile läuft, es gibt also eine Implementierung zum Prüfen statt einer pro Plattform.

<figure><img src="/docs/guides/img/product/04-set-password-desktop.jpg" alt="Der Schritt „Set a password“ in HideFile mit einem verdeckten Passwort, einer grünen Stärkeanzeige mit „Strong“ und einer Schaltfläche „Create locked file“." loading="lazy" width="100%"><figcaption>Das Passwort ist der einzige Schlüssel. Die Pause nach „Create locked file“ ist Argon2id bei der Arbeit.</figcaption></figure>

## Nichts, was du sperrst, wird hochgeladen

Sperren, Entsperren und Speichern passieren alle im Browser-Tab. Deine Dateien, ihre Namen, dein Passwort und die Schlüssel werden nicht an einen HideFile-Server gesendet, und es gibt keinen HideFile-Server, der gesperrte Dateien speichert. Die einzige Ausnahme ist eine Funktion, die du selbst einschaltest: Wenn du deinen eigenen S3-kompatiblen Bucket verbindest, etwa Cloudflare R2, sendet die App verschlüsselte Bytes direkt von deinem Gerät an diesen Bucket, nicht an uns.

Einiges behält die App im Browser auf deinem Gerät. Damit das erneute Öffnen schnell geht, speichert sie bis zu einen Tag lang und bis zu 100 MB eine Kopie der zuletzt geöffneten gesperrten Datei, weiterhin verschlüsselt. Dateien, die du zur Wiederverwendung speicherst, und die Arbeitskopie einer geöffneten Datei liegen im privaten Dateispeicher des Browsers. Außerdem merkt sie sich Einstellungen wie Design und Ansicht sowie Name, Größe und Zeitpunkt der letzten zehn geöffneten Tarndateien, nie das Passwort. Löschst du die Websitedaten, ist alles entfernt. Tu das auf einem gemeinsam genutzten oder geliehenen Computer, wenn du fertig bist.

## Die Analysedaten, die wir senden, enthalten keine Dateidaten

Wir nutzen PostHog, um die Nutzung zu zählen, mit ausgeschaltetem Autocapture, sodass Klicks und Seiteninhalte nicht aufgezeichnet werden. Gesendet wird:

- Seitenaufrufe: der Seitenpfad und die verweisende URL, dein Browser- und Gerätetyp und die Bildschirmgröße.
- Ein ungefähres Land, das PostHog beim Eintreffen der Anfrage aus deiner IP-Adresse ableitet.
- Eine anonyme zufällige Kennung, die in deinem Browser gespeichert wird, um wiederkehrende Besuche zu zählen.
- Drei Ereignisse, `locked_file_created`, `locked_file_opened` und `locked_file_saved`, die jeweils nur den Typ der Tarndatei (png, jpeg, mp4 oder pdf) und die Plattform (web oder native) enthalten.

Dateinamen, Größen, Anzahlen, Pfade, Passwörter, Schlüssel, Inhalte und Fehlermeldungen werden nicht gesendet. Ein Inhaltsblocker wie uBlock Origin blockiert die Analyse, und die App funktioniert genauso. Du kannst das selbst prüfen: Öffne die Entwicklertools deines Browsers, beobachte den Tab „Netzwerk“ (Network), während du eine Datei sperrst und speicherst, und suche nach einer Anfrage, die deine Dateien enthält. Die [Datenschutzerklärung](https://hidefile.app/privacy) ist die verbindliche Fassung dieser Liste.

<figure><img src="/docs/guides/img/product/security-what-leaves.svg" alt="Bleibt auf deinem Gerät: deine Dateien, Dateinamen und Größen, dein Passwort, Verschlüsselungsschlüssel, entsperrte Inhalte und die Tarndatei. An die Analyse gesendet: Seitenaufrufe mit Pfad und Referrer, Browser, Gerät und Bildschirmgröße, ungefähres Land, eine anonyme zufällige Kennung und drei Ereignisse (erstellt, geöffnet, gespeichert), die nur den Tarndateityp und die Plattform enthalten. Nur wenn du es einrichtest: Verschlüsselte Bytes gehen an deinen eigenen S3- oder R2-Bucket, nicht an uns. Der Code der App wird von hidefile.app geladen, wenn du die Seite besuchst." loading="lazy" width="100%"><figcaption>Was auf deinem Gerät bleibt, und die kurze Liste dessen, was es verlässt.</figcaption></figure>

## Das Bedrohungsmodell, als Personen beschrieben

| Wer | Ergebnis | Warum |
|---|---|---|
| Jemand, der durch dein Handy, deinen Laptop oder dein Cloud-Laufwerk scrollt | Gestoppt | Er sieht ein gewöhnliches Foto, PDF oder Video und nichts, das wie ein Tresor heißt |
| Jemand, der deinen Handy-Code kennt | Gestoppt | Die Tarndatei hat ein eigenes Passwort, getrennt von der Gerätesperre |
| Jeder mit einer Kopie der Tarndatei, aber ohne das Passwort | Gestoppt | Die Inhalte bleiben verschlüsselt |
| Ein forensischer Gutachter oder jeder, der HideFile kennt und genau hinsieht | Nicht verborgen | Er kann erkennen, dass Daten hinzugefügt wurden; die Inhalte bleiben verschlüsselt |
| Jemand, der dich zwingen kann, das Passwort herauszugeben | Nicht gestoppt | Keine Software löst das |
| Schadsoftware, Bildschirmaufzeichnung oder ein Beobachter an einem entsperrten Gerät | Nicht gestoppt | Solange Dateien geöffnet sind, sehen sie, was du siehst |

<figure><img src="/docs/guides/img/product/security-threat-model.svg" alt="Gestoppt: jemand, der durch dein Handy oder deinen Laptop scrollt und ein gewöhnliches Bild sieht; jemand, der deinen Handy-Code kennt, weil die Tarndatei ein eigenes Passwort hat; jeder mit einer Kopie ohne das Passwort, weil die Inhalte verschlüsselt bleiben. Nicht verborgen vor einem forensischen Gutachter, der erkennen kann, dass Daten hinzugefügt wurden. Nicht gestoppt: jemand, der das Passwort aus dir herauszwingen kann, und Schadsoftware oder ein Beobachter an einem entsperrten Gerät." loading="lazy" width="100%"><figcaption>HideFile hält beiläufiges Neugierigsein ab, keine forensischen Werkzeuge.</figcaption></figure>

## Ein forensisches Werkzeug kann erkennen, dass Daten hinzugefügt wurden

HideFile versucht nicht, vor einer forensischen Prüfung zu verbergen, dass Daten vorhanden sind, und behauptet das auch nicht. Deine verschlüsselten Datensätze liegen in der eigenen Dateistruktur der Tarndatei, wo ein normales Anzeigeprogramm sie ignoriert. Ein dafür gebautes Werkzeug oder ein Gutachter, der weiß, wonach er suchen muss, kann erkennen, dass Datensätze hinzugefügt wurden. Die Dateigröße ist ein einfacheres Indiz: Ein kurzer Urlaubsschnappschuss mit mehreren Gigabyte ist ungewöhnlich, und der Vergleich der Tarndatei mit dem unberührten Original zeigt den Unterschied sofort.

Der Gutachter erhält die Tatsache, dass etwas da ist, nicht die Inhalte. Ohne das Passwort bleiben die Datensätze versiegelt. Das ist die ehrliche Grenze: Offen sichtbar zu sein beantwortet einen Neugierigen und eine gewöhnliche Suche, nicht einen entschlossenen Gutachter, der dein Gerät in der Hand hat. Für Grenzkontrollen, geschulte Gutachter oder rechtlichen Druck ist es das falsche Werkzeug.

Die Manipulationserkennung deckt die versiegelten Datensätze ab, nicht jedes Byte der Tarndatei. Eine App, die die Tarndatei neu speichert, Metadaten entfernt oder neu komprimiert, kann das Bild verändern, ohne dass die Verschlüsselung Alarm schlägt, und sie kann die Datensätze ganz entfernen, was die Dateien darin zerstört. Behalte die Tarndatei als Datei.

## Es gibt keine Passwortwiederherstellung

Wir haben dein Passwort nicht und können es nicht aus einer gesperrten Datei ableiten. Es gibt keinen Zurücksetzen-Link, keinen Wiederherstellungscode und keinen Support-Weg, der eine Datei öffnen könnte. Geht das Passwort verloren, sind die Dateien darin verloren. Das ist eine Eigenschaft des Designs und der Grund, warum jeder, der eine Kopie deiner Tarndatei hat, uns nicht einfach bitten kann, sie zu öffnen.

## Was nicht Open Source und nicht geprüft ist

Der HideFile-Quellcode ist nicht öffentlich, und keine unabhängige Firma hat ihn geprüft. Die Algorithmen sind Standard, die Bibliotheken, die sie umsetzen, sind Open Source, und diese Seite sowie die [Sicherheitsseite in der App](https://hidefile.app/security) nennen die Parameter, aber unser Code, der sie aufruft, kann von Außenstehenden heute nicht gelesen werden.

Das ist wichtig. Ein Hacker-News-Kommentator brachte es als Reaktion auf ein anderes geschlossenes Werkzeug, das Daten in einem Foto versteckt, in vier Wörtern auf den Punkt: „no source code == no security.“ Andere in dieser Community weisen darauf hin, dass eine Web-App bei jedem Besuch frisch vom Server ausgeliefert wird, sodass selbst veröffentlichter Quellcode einen Weg bräuchte, um zu bestätigen, dass der Code, den du ausführst, ihm entspricht. Beide Punkte sind berechtigt, und für einen Leser, der diesen Maßstab anlegt, erfüllt HideFile ihn noch nicht. Wir sagen das lieber, als darüber zu streiten. Wenn du einen Fehler findest, schreib an support@hidefile.app mit Schritten zum Nachstellen und gib uns angemessene Zeit, eine Korrektur auszuliefern, bevor du veröffentlichst.

## Quellen

- HideFile: [How HideFile protects you](https://hidefile.app/security)
- HideFile: [Privacy Policy](https://hidefile.app/privacy)
- OWASP: [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
- RFC 9106: [Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications](https://www.rfc-editor.org/rfc/rfc9106)
- RustCrypto: [argon2 crate](https://docs.rs/argon2) and [chacha20poly1305 crate](https://docs.rs/chacha20poly1305)
- Hacker News: [Show HN: a hardware-bound local password vault hidden in a photo](https://news.ycombinator.com/item?id=49508206), comment [49509561](https://news.ycombinator.com/item?id=49509561)
- Hacker News: [comment on browser delivery of encrypted apps](https://news.ycombinator.com/item?id=19983075)
