How HideFile protects you

The surface of this app avoids technical words on purpose. This page does not. Everything below is written to be checked.

The shape of the system

Your files are locked on this device and woven into a cover file — an ordinary photo, PDF, or video that still opens as a photo, PDF, or video.

There is no HideFile server holding your files or your password.

There is no password reset and no recovery. We do not hold your password, and we cannot derive it from a locked file. If you lose the password, the files are gone. That is the design, not a gap in it.

The cryptography, named plainly

Two pieces do the work.

Your password becomes a key: Argon2id

Argon2id is a memory-hard key derivation function — turning your password into a key deliberately costs a large block of memory as well as time, so guessing stays expensive even on hardware built for guessing.

The parameters are chosen when a locked file is created, and stored inside it. As facts:

• Algorithm — Argon2id, version 1.3, producing a 32-byte key.
• Created in the installed app — 64 MiB of memory, 3 iterations, a single lane. This is used on every platform the installed app runs on, phones included. Each guess an attacker makes has to pay that memory too.
• Created in a browser — the same 64 MiB and 3 iterations, except on a browser that reports a phone or tablet, or 4 GB of memory or less. Those get 19 MiB, 2 iterations, a single lane.
• Salt — 16 random bytes per locked file, stored with it. Two people with the same password get different keys, so no attacker can precompute one table and open everyone's files.

Opening an existing locked file uses the parameters stored in that file, whatever device you open it on. A file created on a desktop keeps its 64 MiB cost when you open it on a phone.

The lower browser numbers are a real trade-off, stated rather than hidden: a phone browser cannot reliably spend 64 MiB per unlock without failing to unlock at all. That reduced setting — 19 MiB, 2 iterations, 1 lane — still meets the current OWASP minimum for Argon2id.

This is also why unlocking pauses for a moment. The pause is the machinery working, and it is the same pause an attacker pays on every attempt.

Your files are sealed: XChaCha20-Poly1305

XChaCha20-Poly1305 is authenticated encryption — it keeps your files private and detects tampering. Your files are sealed in records, each carrying its own authentication tag. If a sealed record is altered, whether by a corrupted copy or by someone editing it deliberately, unlocking that record fails loudly rather than handing you quietly wrong contents. What this does not cover is described below.

• Cipher — XChaCha20 with a 256-bit key and a Poly1305 authentication tag.
• Nonce — 192 bits, random per sealed piece. Large enough that random values do not collide in practice, which is the property the extended nonce exists for.
• Keys — one random 256-bit key per locked file, generated on your device. The key derived from your password wraps that key and unwraps it again; it never encrypts the files you put inside.

Both are implemented in the same Rust core for every version of HideFile — browser, desktop, and phone. The browser runs that core compiled to WebAssembly, so there is one implementation to audit rather than three.

Plain sight, honestly described

A cover file is not a second layer of encryption. Your files are already sealed; the cover file changes what the sealed bytes look like to someone who finds them. Being precise about that line matters more than sounding strong.

What it does protect against:

• Someone browsing your phone, laptop, or cloud drive and seeing a photo rather than a locked file.
• Backup and sync tools, which copy the cover file as an ordinary file, with your files still sealed inside it.
• A file listing or search that turns up nothing named like a vault, because nothing is.

What it does not protect against:

• File size. A holiday snapshot carrying several gigabytes is unusual, and unusual is noticeable. Anyone comparing the cover file against an untouched original will see the difference.
• Forensic examination. Someone who knows HideFile exists and examines the file closely can determine that something has been added to it. The contents stay sealed; the fact that something is there is not a secret we claim to keep.
• Every byte of the cover file. Tamper detection covers the sealed records, not the whole cover file. The ordinary photo, PDF, or video bytes around those records can be changed — re-saved by an image tool, stripped of metadata, recompressed by a sync service — without any alarm from the encryption. Your files stay sealed and unreadable either way, but a clean unlock is not proof that the cover file came back to you untouched.
• Being made to give up the password. No software solves this. If you are in a situation where someone can compel you, treat plain sight as cover, never as protection.
• A compromised device. While a file is unlocked, it is readable on that device. Malware, screen recording, or someone at the keyboard while you are working sees what you see.

Plain sight is a good answer to a curious person and an ordinary search. It is not an answer to a determined examiner with your device in hand. Your password is what protects the contents in every one of these cases.

What HideFile keeps

Your password is never written down. It lives in memory only while a file is open, and it is gone when you lock up.

The app does write other things on this device, and one claim we will not make is that the following is exhaustive forever. It is what the app writes today, grouped by why:

Copies of your locked files, kept to make reopening fast

• The locked file you last opened. In the browser, opening a locked file stores the whole file — every byte of it — in browser storage so the app can reopen it without asking you to find it again. Cached copies expire after a day, and the cache holds at most 100 MB.
• Locked files you save for reuse, and the working copy of an open one. These live in the browser's private file area, which is not visible in your normal file listings.

These copies are the locked file itself, still sealed. They are as unreadable without your password as the original is. What they do mean is that a locked file you opened on a shared or borrowed machine leaves a copy behind on it. Clearing site data for this app removes them.

Settings and preferences

• Theme — light or dark.
• View preference — grid or list, and the simple or detailed view mode.
• Onboarding state — whether you have seen the first-run introduction.
• Recently opened cover files — the name, size, and time for the last ten, so you can pick up where you left off. Never a password.
• Storage and connection settings — which storage the app should prefer, and any address you have set for your own backend.
• File access permission — on iPhone and iPad, the system handle that lets the app reopen a file you picked. It grants access to that file, not to its contents.

Connections and licensing

• Cloud connections — if you connect a cloud drive, its settings are stored here. Sign-in details are kept in memory for the session unless you ask the app to remember them, in which case they are encrypted with a passphrase you choose before being stored.
• Licence — a device identity and its key, plus the licence token that proves this device is activated. A purchase on Apple platforms also stores an identifier used to match the purchase to this install. If you sign in to the licence portal, your licence key is held for that browser session only.
• Reviews you write — saved here until you choose to export and send them.

Diagnostics

• Unlock performance notes — which of two ways of reading large files is faster here, so the next unlock picks the better one. Alongside the timings it records your browser, operating system, whether the device is a phone, its processor count, its reported memory, and a size range for the file. This stays on the device.
• Usage analytics. When analytics is configured for the build you are running, the app reports which of its pages you visited and three usage events (a locked file was created, opened or saved) to an analytics service, with an anonymous ID and an approximate country derived from your IP address. The events carry only the cover type (photo, video or PDF) and the platform: no file names, no file contents, no sizes and no password. This is the one thing on this list that leaves your device.

Nothing on this list would help anyone open a locked file without your password. To remove all of it, clear this app's site data in your browser, or uninstall the app.

Open questions welcome

If something here is unclear, or you think a claim on this page is wrong, we would rather hear it than not: support@hidefile.app.

For a security flaw, please tell us how to reproduce it, and give us reasonable time to ship a fix before publishing.

The numbers on this page are taken from the code that ships. When they change, this page changes with them.