Encrypt a File, Then Send the Key Down a Different Road

What the tool actually does to your file

It is worth being precise, because "AES-256" on a button tells you almost nothing — the same three letters cover constructions that are excellent and constructions that are broken. This one calls the browser's own WebCrypto implementation with AES-GCM, which is authenticated encryption: it does not only hide the content, it also proves the content has not been altered. The key is 256 bits. The authentication tag is 128 bits, which you can verify without reading a line of code: a 71-byte plaintext produced an 87-byte ciphertext, exactly the sixteen extra bytes that RFC 5116 specifies for AES-256-GCM.

A passphrase is not a key, so it has to be turned into one. The tool uses PBKDF2-HMAC-SHA256 over 150,000 iterations, with a 16-byte salt drawn from the browser's cryptographic random source. The salt is new for every encryption, which is what stops a precomputed table from covering many files at once. The nonce is 12 bytes and also new every time — verified by encrypting the same file twice with the same passphrase and comparing: different salt, different nonce, different ciphertext. Both are stored in the clear at the front of the output, and that is correct rather than careless. A salt and a nonce are not secrets; they only have to be unique, and the person decrypting needs them to reproduce the key.

The authentication half is not decoration. Flip a single bit anywhere in the ciphertext and decryption refuses; flip a single bit of the stored nonce and it refuses too; give it a passphrase that differs by one capital letter and it refuses. In every case you get an error, never a file full of plausible-looking rubbish. That distinction matters more than it sounds: a mode without authentication, such as AES-CBC with no separate integrity check, hands back damaged data without complaint, and an attacker who can modify the file in transit can sometimes steer that damage.

The mistake everyone makes: the key rides with the file

Here is the shape of it. You encrypt the payroll spreadsheet, attach the .enc file to an email, and — because the recipient obviously needs it — you type the passphrase in the same message. Or in a follow-up message, which feels more careful and is not. Or in a reply on the same thread, which is worse, because now both halves are in one conversation that any search will surface together. Whatever the variation, you have built a lock and taped the key to the door.

The reason "I'll send it in a second email" fails is that it does not change who can read it. Encryption in transit is not the threat model here — mail between major providers is already encrypted on the wire. What you are actually defending against is someone reading the mailbox: a compromised account, a phone left unlocked, a shared family address, an employer with lawful access to the archive, a leaked backup, a forwarded thread that picked up one recipient too many. Every one of those exposes the second email exactly as much as the first. Two messages in the same inbox are one channel that happens to have been used twice.

What a second channel actually means

A second channel has to differ on the things that actually fail. Three axes are worth separating. A different medium — email versus voice versus paper — so that one protocol being broken does not hand over both halves. A different account — your work mailbox versus a personal messenger — so that one credential does not open both. And a different device, so that one stolen or infected phone does not hold the file and the passphrase side by side. Send the file from a laptop and the passphrase from that same laptop's desktop messaging app, and you have moved the key across the desk rather than out of the room.

This is why a passphrase read aloud on a phone call is genuinely better, and not merely old-fashioned. It leaves no copy: there is no message to search later, no backup to leak, no thread to forward by accident, no archive an administrator can open in two years. Intercepting it requires being on the line at the moment it is spoken, which is a far narrower and far more expensive attack than reading a mailbox at leisure. It also gives you something no channel provides on its own — you recognise the voice, so you know who received it. Say it slowly, use the NATO alphabet for anything ambiguous, and have them read it back.

The thing people forget: the recipient has to be able to open it

An encrypted file that nobody at the other end can decrypt is not security, it is a failed delivery — and the usual repair is worse than the original problem, because it ends with someone sending the file again unencrypted "just this once". So check the other end before you send. The .enc file this tool produces has no header at all: its first bytes are the raw random salt, with no magic number, no version, no algorithm name and no original filename. That is a bespoke layout. It is not a ZIP, not an OpenPGP message, not an age file, not the output of openssl enc — and none of those will open it.

The practical consequence is a good one, though: because the tool runs entirely in the browser, the recipient does not have to install anything, create an account or trust a server with the file. They open the same page, load the .enc file, type the passphrase and press decrypt, and the plaintext lands in their downloads. Nothing is uploaded in either direction. So the sentence to send with the file is not just the passphrase hint — it is which page to open. And send that sentence on the same channel as the file, since it is not a secret; only the passphrase changes road.

When the passphrase is lost

Nothing can be done. Not by the site, not by support, not by you. There is no account holding a copy, no recovery key, no escrow, and no back door — the key never existed anywhere except in the memory of the browser tab that made it, and it was derived from the passphrase on the fly. Lose the passphrase and the file is a block of noise that will stay noise. It is worth saying plainly because people assume a recovery path exists by default, the way it does for a webmail password.

And that is the design working, not failing. A recovery path is by definition a second way in, and a second way in is something an attacker can also walk through — or a court can compel someone to open. The right response is not to wish for a back door but to store the passphrase somewhere durable before you need it: a password manager entry attached to the file's name, or written on paper in a drawer if the file is going to matter in five years. Use a passphrase you can dictate, since you will probably have to. Four or five unrelated words beat a mangled single word on both counts — it is stronger and it survives being read aloud.

One honest weakness: the iteration count

The cipher is not where this construction is thinnest — the key derivation is. PBKDF2 exists to make guessing expensive, and its cost is set by the iteration count. This tool uses 150,000. The OWASP Password Storage Cheat Sheet, the reference most defenders work from, currently recommends 600,000 for PBKDF2-HMAC-SHA256. The shipped figure is one quarter of that, which multiplies an offline guessing attacker's throughput by four. Measured on one core, 150,000 iterations took about 36 milliseconds per attempt, so a single ordinary core tries roughly 28 passphrases a second; specialised hardware does vastly better, and PBKDF2 is friendlier to that hardware than a memory-hard function like Argon2id would be.

This does not make the tool unsafe, and it changes nothing about the cipher, the salt or the nonce, all of which are right. It shifts where the safety comes from: with a lighter key derivation, more of the burden falls on the passphrase itself. A four-word passphrase drawn at random from a large word list stays out of reach either way; a single dictionary word with a number on the end was never protected by iteration counts at all. Pick the passphrase as if there were no stretching, and the difference between 150,000 and 600,000 stops mattering to you.

Frequently asked questions

Is AES-256-GCM enough on its own?

For the encryption itself, yes — it is a standard authenticated mode and the browser implementation is the same one used for HTTPS. But a cipher only protects what the key protects. Here the key is derived from your passphrase, so the real strength ceiling is the passphrase, and the real failure mode is sending it down the same channel as the file. AES-256-GCM cannot help with either.

Why is the salt sitting in the open at the start of the file?

Because it is not a secret and was never meant to be. A salt exists so that the same passphrase produces a different key each time, which stops one precomputed table from attacking many files at once. It only has to be unique, not hidden. The same is true of the nonce. Whoever decrypts needs both to rebuild the key, so they have to travel with the ciphertext — hiding them would mean encrypting them, which would need a key, which is where you started.

Can I just send the passphrase in a second email?

No, and it is the single most common version of the mistake. Two emails to the same address land in the same mailbox, the same archive and the same backup. Anyone who can read one can read the other, and a search on the sender's name pulls them up side by side. It is not a second channel, it is the same channel used twice. Use a different medium — voice, or a messenger on a different account — or the encryption is only buying the time it takes someone to scroll.

Can the recipient open the .enc file with 7-Zip, GPG or openssl?

No. The container is a bespoke layout — 16 bytes of salt, 12 bytes of nonce, then ciphertext and tag — with no magic number, no version byte and no algorithm identifier, so no standard tool can even recognise it. The recipient opens the same page in their own browser, loads the file, types the passphrase and presses decrypt; nothing is installed and nothing is uploaded. Tell them which page to open in the same message as the file. That part is not secret.

I have lost the passphrase — is there really nothing to be done?

Really nothing. The key existed only inside the browser tab that created it, derived from the passphrase at the moment of encryption; no copy is stored anywhere, by anyone. There is no recovery key, no escrow and no support route, and that absence is deliberate — any recovery path is a second way in, which an attacker could also use. If you remember the passphrase roughly, guessing variants by hand is your only option, and each attempt costs about a twentieth of a second.