Tool guide
How encrypting a file with a passphrase works
Encryption programs ask for a passphrase, and it’s natural to think of it as the key that locks the file. It isn’t quite. A good tool turns your passphrase into a key through a step designed to be slow, then uses that key with a cipher that both hides the file and seals it against tampering. Each part has a job, and knowing them tells you what actually keeps the file safe.
Step 1: turning a passphrase into a key
Ciphers need a key of an exact size, made of bytes that look completely random. For modern ciphers that’s 256 bits. A passphrase is neither the right size nor random-looking: “correct horse battery staple” is ASCII letters with a lot of pattern.
So the passphrase goes through a key derivation function. It mixes the passphrase with a salt, a random value stored in the file’s header, and produces a key of the right size. Change one letter of the passphrase, or the salt, and the key is completely different.
The important property is speed, or rather the lack of it. Anyone holding the locked file can try passphrases on their own computers, as fast as their hardware allows, without anyone noticing. A fast function lets them try billions a second. A deliberately slow one cuts that to a tiny fraction.
Argon2id, the method used by the file encryption tool, is slow in two ways. It takes a set number of passes over its data, and it needs a large block of memory, 128 MiB in the tool, for each guess. Memory is the part that hurts attackers: graphics cards and custom chips can run thousands of simple calculations side by side, but not thousands of copies of something that needs 128 MiB each. For you, the cost is a second or so once per file.
Step 2: encrypting and sealing
With the key made, the file is encrypted with an authenticated cipher. The tool uses XChaCha20-Poly1305, which does two things at once:
- Encryption. XChaCha20 turns the key and a nonce, a number used only once, into a stream of random-looking bytes, and combines it with the file. Without the key, the output can’t be told apart from random data.
- Authentication. Poly1305 computes a 16-byte tag over the encrypted bytes. Unlocking recomputes it, and if a single bit differs, the cipher refuses to return anything.
That second part is easy to overlook, and it matters. Without it, someone could change bytes in the locked file and you’d get a subtly wrong file back with no warning. With it, any change is detected, and so is a wrong passphrase: the wrong key simply produces a tag that doesn’t match.
Step 3: handling large files
Encrypting a 4 GB video as one piece would mean holding all of it in memory, and only finding out at the very end whether anything was wrong. Instead, the file is split into parts, 1 MiB each in the tool, and every part is encrypted and sealed on its own.
A few details keep the parts honest. Each part’s nonce includes its position, so parts can’t be swapped around without failing. The last part is marked as last, so cutting parts off the end is detected. And every part is tied to the header, so a header from one file can’t be paired with parts from another. Unlocking then reads one part at a time, with steady memory use however large the file.
What protects you, and what doesn’t
Put the pieces together and the picture is simple. The cipher and key size are far beyond attack. The slow key step multiplies the cost of every guess. That leaves the passphrase as the real defence.
A passphrase of six random words from a 2,048-word list has about 66 bits of randomness. Even at a very fast guessing rate, finding it would take far longer than anyone can wait, and Argon2id slows guessing much further still. A short word with a number on the end, or a phrase from a song, is a different story: attackers try those first. See how long a passphrase should be for the numbers.
Encryption also doesn’t protect a file before it’s locked or after it’s unlocked. The original on your device stays readable until you delete it.
Where you’ll meet this
The same pattern, a slow key step and an authenticated cipher, sits under password managers, encrypted backups and disk encryption. Silo uses Argon2id to make a key from your PIN or passphrase and XChaCha20-Poly1305 to encrypt the files in its vault, so the tool is a hands-on look at that design too. The difference is what holds the key: an app on your phone, or you, for a file you carry around.
Questions
Is the passphrase stored in the locked file?
No. Only the salt and the settings for the slow step are stored. The key is rebuilt from your passphrase each time you unlock, and checked by whether the file's seal opens.
Why does locking take a second before it starts?
That's the key being made. The slow step is tuned to take a noticeable moment on your device, which is nothing for you but adds up to years for someone trying billions of guesses.
Can the encryption itself be broken?
Not in any practical way known today. With a 256-bit key, trying every key is far beyond any computer. Real attacks go after the passphrase instead, which is why its strength matters most.
What does the salt do?
It makes the same passphrase give a different key for every file. An attacker can't precompute keys for common passphrases once and reuse them, and two files locked with the same passphrase don't look related.