2026-07-25

Is a password-protected ZIP file actually safe to email?

"I'll just zip it and put a password on it" is one of the most common things people do before emailing a sensitive file — a signed contract, a scan of an ID, a spreadsheet of salaries. It feels like it solves the problem. Whether it actually does depends on two separate questions that are easy to conflate: does the password protection itself hold up, and does encrypting the file even address the biggest risk in "email it to someone" to begin with? The honest answer to both is more specific than most password-protect guides let on, and the specifics are worth getting right before trusting a sensitive file to it.

Not every "password-protected ZIP" uses the same encryption

The ZIP format has two very different things hiding under the same ".zip" extension and the same "add a password" checkbox. The original scheme, sometimes called ZipCrypto or "Zip 2.0" encryption, has been part of the spec since the early 1990s. The newer option, WinZip's AES extension, is real AES-256 with a proper key-derivation step. Which one a file gets depends entirely on the tool: many simple "add password to zip" utilities, and some operating systems' built-in "compress" features, still default to ZipCrypto because it's the most universally compatible option — every unzip tool on earth can open it. Getting AES-256 instead usually means opening 7-Zip, WinRAR, or a similar tool and explicitly selecting AES-256 as the encryption method, not just typing a password into whatever dialog appears first. From the outside, a ZipCrypto file and an AES-256 file look identical: same extension, same "enter password" prompt on open. There's no visual cue telling you, or an attacker, which kind of protection you're actually relying on.

The known-plaintext attack, in specific terms

ZipCrypto's weakness isn't a matter of degree — it's not "weaker than AES-256," it's a structural flaw that Eli Biham and Paul Kocher published decades ago and that a free, actively-maintained tool called bkcrack automates today. ZipCrypto encrypts with a stream cipher: three internal 32-bit keys generate a keystream that's XORed against the file's bytes, and those same three keys get updated as encryption proceeds, byte by byte, based on the plaintext itself. That update rule is the flaw. If an attacker already knows even a modest stretch of what the plaintext looked like — bkcrack's own documentation says as few as 12 bytes is theoretically enough — they can run that update rule backward from the known bytes and recover the three internal keys directly, without ever guessing the password at all. Once the keys are recovered, the entire archive opens, regardless of how long or random the actual password was. A real, dated example: a 2025-04-07 write-up at badoption.eu recovered a ZipCrypto-protected archive's protection using about 10,600 bytes of known plaintext — a public Windows system DLL the attacker already had an unencrypted copy of — with the full run, key recovery included, finishing in 7.75 seconds. The same write-up is explicit that this technique does not work against AES-encrypted zips; the flaw is specific to ZipCrypto's design, not to ZIP passwords or password length in general.

Where the "known" part of known-plaintext comes from

The catch that makes this practical rather than academic: a lot of files aren't secret in their entirety. A contract built from a standard template shares its boilerplate clauses with every other copy of that template circulating online. A PDF, a Word document, an Excel file — every one of those formats has fixed structural bytes at the start of the file before any of your actual content appears, and plenty of PDFs and Office documents produced by the same software share long stretches of that structure. A folder of installers or system files, like the DLL in the badoption.eu example, can be matched byte-for-byte against a public, unencrypted copy anyone can download. None of that requires the attacker to know your password or your content — it only requires them to recognize what kind of file is probably inside, and go find (or already have) a matching unencrypted copy of enough of it.

Sending it also means trusting the address bar, not just the archive

Even a perfectly encrypted file doesn't solve the other half of "email me the file" — getting it to the right inbox. Analysis of the UK Information Commissioner's Office's own published incident data, by Beyond Encryption, found that "data emailed to the incorrect recipient" was the single most common type of incident reported to the ICO in 2023: 1,744 cases out of 11,074 total reported incidents that year — 16% of everything reported, and nearly double phishing's 932 cases (roughly 8%) for the same year. The same analysis notes the pattern held into Q1 2024, with wrong-recipient email still the top incident type at 539 cases. Autocomplete filling in the wrong "J." from a contacts list, reply-all landing outside the intended group, a distribution list with one stale address — none of that is exotic; it's the single most common way a data breach starts, according to the regulator's own numbers, ahead of phishing and every other cause tracked. It's also a mistake that encryption is specifically good at containing: if the file itself resists opening without the right passphrase, a message sent to the wrong person is an inconvenience and a "please delete this" follow-up, not a disclosure of a signed contract or an ID scan to a stranger. That containment only works, though, if the encryption inside the attachment is the kind that resists exactly the attack described above.

What actually holds up before you hit send

Put together, the practical bar for encrypting a file you're about to email is not "does it ask for a password" — it's whether the algorithm behind that prompt is one with a known structural break like ZipCrypto's, or a modern authenticated cipher (AES-256-GCM, or an equivalent like ChaCha20-Poly1305) fed by a password-stretching function designed to make brute-force guessing slow. If you're using a zip tool, that means deliberately choosing its AES-256 option rather than trusting the default "add password" checkbox, and confirming the tool you picked actually offers that choice — plenty of the simplest ones don't. It also means not assuming password protection substitutes for sending the file to the right person in the first place; it's a second layer for when — not if, per the ICO's own numbers — the first layer slips.

Where NearSeal fits into this

This is exactly the gap NearSeal is built to close, and it's worth being precise about what it does and doesn't claim. It runs entirely in the browser — the file and the passphrase never leave the device, there's no upload step to trust with either. On the encryption itself, there are two formats to choose from, and neither is ZipCrypto: the default NearSeal format derives its key with PBKDF2-SHA256 at 2²⁰ iterations and encrypts with AES-256-GCM, or you can opt into the open age-encryption.org format (scrypt for key derivation, ChaCha20-Poly1305 for encryption), which opens with the real age or rage CLI as well as this site. Both are modern, authenticated ciphers with a deliberately slow key-derivation step in front of them — the specific known-plaintext technique described above targets a design flaw in ZipCrypto's stream cipher that simply doesn't exist in either format NearSeal produces. What NearSeal can't do is stop a file from being addressed to the wrong person — no encryption tool can fix that part of the workflow. What it can do is make sure that when that mistake happens, what lands in a stranger's inbox is ciphertext that a free, actively-maintained cracking tool can't open in a few seconds, rather than a checkbox's worth of false confidence.