Start with the conclusion: a ZIP password does not prove “the cloud cannot see the files.” It only shows that extraction needs a passphrase. The ZIP directory is readable by default, and classic ZipCrypto can leak its internal key when a short stretch of plaintext is known. Before you upload, check two things: whether the content was already sealed on this device with authenticated encryption, and whether this HTTP request sent plaintext or the passphrase.
Answer the search intent in one sentence
A password on an archive before a cloud upload is not the same layer as local AES-GCM. The archive puts files in a ZIP container and locks the contents of those files. The container’s own directory—names, dates, sizes—is designed to be read. Local AES-256-GCM uses the browser Web Crypto API on the bytes, you download the ciphertext, then you upload; without your passphrase the cloud has only noise.
This note is for developers, ops, and anyone who wants to split “I set a password” from “the other side cannot read the content” before a backup lands in Drive. It does not replace the File Encryption Box how-to, and it does not walk the clicks that produce a .lock. What you should take away is what ZipCrypto and ZIP-AES each block, who holds the default cloud keys, what remains in a local ciphertext header, and how to check Network and a hex dump on this run.
“I set a password” is not “the cloud cannot see the content”
Everyday speech folds three different jobs into “this file is encrypted.” The first is encryption in transit: the browser talks to Drive over HTTPS, so a path observer has a hard time reading the bytes. The second is the provider’s encryption at rest: blocks on disk are wrapped with keys the provider manages, which helps if a disk is stolen. The third is client-side encryption with a key you hold: the content is already ciphertext before upload, so the provider cannot open it without your passphrase.
A ZIP password sits in a fourth habit: you build a passphrase-locked container on this machine, then upload that container as an ordinary file. Drive treats it like any other .zip—index by name, hash for instant upload, scan for malware or sensitive content when policy says so. If the payload is still ZipCrypto, or the directory is plaintext, a scanner does not need to “guess your password” to read filenames, and sometimes it can do more to the contents.
So “I set a password” only supports a narrow claim: someone who will not extract, or who lacks the passphrase, will not open the files easily. It does not support “a Drive employee cannot see this,” “a lawful request cannot recover the originals,” or “filenames never enter their index.” Those sentences become checkable only after you switch layers: authenticated encryption on this device, then upload ciphertext.
What ZipCrypto does not stop
Classic ZIP encryption is usually called Zip 2.0 or ZipCrypto. WinZip’s own help is blunt: the format is relatively weak, and you should not expect it to stop someone with a dedicated recovery tool; use AES when the files matter. That is in WinZip’s encryption notes, not a forum rumor.
The weakness is the cipher, not whether your password is long. In 1994, Eli Biham and Paul Kocher published a known-plaintext attack on the PKZIP stream cipher: with about a dozen bytes of matching plaintext and ciphertext, an attacker can recover the three internal 32-bit states and then the keystream for the rest of the file. Password length drops out of that step—the work copies the lock cylinder, it does not try keys. Public tools such as bkcrack turn that paper into a program, and archives stored (not deflated) with ZipCrypto are the most direct case.
Where does the known plaintext come from? A PDF starts with %PDF. Office documents, many images, and nested ZIPs have fixed magic. If you drop a well-known document format into a ZipCrypto archive and upload it, you have also handed over ciphertext plus a nearly certain plaintext sample. This is not a walkthrough of the attack. It is a reason to stop treating “Compress and set password” as AES-256-GCM.
Built-in compressors, a Drive page that offers “encrypt and zip,” and older packaging scripts often pick ZipCrypto because almost every extractor can open it. After you pack, read the properties: if it says ZipCrypto or Zip 2.0, do not use that archive as a backup plan. If it says AES, go to the next section—the content layer is stronger; the directory is often still plaintext.
Do not experiment with a real contract, passport scan, or an unredacted project folder. Prepare a disposable small file. Put a one-time canary in both the filename and the body. You are checking the directory, the header, and the traffic—not uploading privacy again.
Even an AES ZIP still shows the directory
WinZip has offered AES-128 and AES-256 (AE-1 / AE-2) since version 9.0. The key comes from the passphrase through PBKDF2, with an 8-, 12-, or 16-byte salt and 1,000 iterations. That is a large step up from ZipCrypto, but it is still not “AES-256-GCM in the browser.” WinZip AES encrypts then authenticates (AES-CTR plus HMAC). It is not NIST GCM. One thousand iterations is also far below the hundred-thousand-class password derivation that is common now. WinZip documents the wrapping on its AES encryption page.
The directory is easier to miss. WinZip states that encryption applies only to the contents of files inside the archive. Name, date, size, attributes, and compression ratio live in an unencrypted directory. Anyone who has the ZIP can read them without a password. They even published a note on “opening an encrypted ZIP still shows filenames,” and suggest a double-zip: pack once without encryption, then put that archive inside a second encrypted ZIP. See WinZip on filename visibility.
7-Zip’s .7z format can tick “Encrypt file names.” That is a different product line; do not mix it with default ZIP behavior. “Password required” in Explorer only means extraction needs a passphrase. Open the same file in another extractor and the list often appears at once: passport-back.jpg, payroll-2026.xlsx, client-list.csv. Instant upload, preview, and policy scans read that layer.
“Encrypted in Drive” usually means the provider holds the keys
Drop a ZIP—or the original file—into Drive and the page will mention encryption in transit, encryption at rest, AES-256. Those sentences can all be true and still fail to answer who holds the unwrap key. Google’s Drive help says files uploaded or created in Docs / Sheets / Slides are encrypted in transit and at rest with AES-256 by default. If you also want Google unable to decrypt, a Workspace admin must turn on client-side encryption, and the user must use a work or school account and finish identity verification. A personal file dragged into My Drive follows the default path, not client-side encryption. That is in the Drive encrypted-files help.
Google Cloud states the default at-rest model even more plainly: keys are Google-owned and Google-managed. Data encryption keys (DEKs) on disk are wrapped by key-encryption keys (KEKs); unwrap happens in the provider’s key service. See Google Cloud default encryption at rest. Workspace white papers draw the same line between “Google manages the keys” and “after client-side encryption, Google cannot read.” Instant-upload hashes, document preview, and compliance scans assume the server can see file bytes—or at least a plaintext hash. A local ZIP password does not turn that stack into zero knowledge.
So the lock on a Drive badge protects “a disk walked out of a data center” and “an observer on the path.” It does not protect “after I handed this company the file, they cannot see it either.” That second sentence becomes an observation only after the readable original is gone before upload.
Which layer local AES-256-GCM actually protects
AES-GCM is authenticated encryption: one pass both hides the bytes and binds integrity. If the ciphertext is altered, truncated, or the passphrase is wrong, decrypt should fail outright instead of emitting “garbage that looks like plaintext.” NIST SP 800-38D recommends a 96-bit (12-byte) IV for interoperable GCM; the tag is commonly 128 bits (16 bytes). Reusing an IV under the same key collapses both confidentiality and authenticity.
The correct path in a browser is crypto.subtle.encrypt with algorithm name AES-GCM. MDN states that SubtleCrypto.encrypt is available only in a secure context—HTTPS in production. A passphrase is not a 256-bit key. It must go through a function such as PBKDF2 with a salt and many iterations. RFC 2898 defines PBKDF2; the iteration count is how long one guess takes. One thousand and one hundred thousand are not the same class.
A file flow can be written as actions you can see: pick a local file, the script reads it in chunks, each chunk gets a fresh random IV and AES-256-GCM, then the browser downloads the ciphertext. That download is assembled on this device. It is not a server receipt. A 5 GB single-file cap describes streaming in the browser. It does not mean a remote host received 5 GB of plaintext.
FastPwd File Encryption Box follows that boundary: AES-256-GCM in Web Crypto; the passphrase goes through PBKDF2-HMAC-SHA256, 100000 iterations, a 16-byte salt, and a 256-bit key; default chunks are 1 MB, each with a 12-byte IV, ciphertext, and a 16-byte tag; one file up to 5 GB; output .lock / .enc with magic CSLK. Every tool is ready to use—no account and no vault. If you forget the passphrase, it cannot be recovered, because it was never uploaded. A promise is still only a promise. The checklist below includes the part of the header that is not encrypted.
What encryption can prove, and what the header still shows
The conclusion local encryption supports is equally narrow. Writing it down prevents one misread. It can support: on this run, file content became authenticated ciphertext chunk by chunk; without the passphrase, decrypt should fail; if Network does not find the canary, plaintext and the passphrase did not leave as the HTTP business data you observed.
It cannot support: the cloud sees no metadata at all, an extension did not read the clipboard, the passphrase is strong enough, or someone with the ciphertext will never run an offline guess. FastPwd Lock v1 stores the original filename and MIME in plaintext in the header so decrypt can restore the name. Upload passport-back.lock, or leave passport-back.jpg in the header, and Drive—or anyone with a hex viewer—can read those words. Encryption covers content chunks, not the label the container shows the world.
| What you see | What that supports | What that does not support |
|---|---|---|
| ZIP extraction asks for a password | The content layer has a lock | The directory is hidden; the algorithm is AES-GCM |
| You can list filenames without extracting | The ZIP directory is plaintext (the usual default) | The contents can also be opened |
| Properties say ZipCrypto / Zip 2.0 | Classic stream cipher; a known-plaintext attack applies | A long password stops a dedicated tool |
| Drive shows “encrypted storage” | Transit or at-rest encryption is likely present | The provider has no keys and cannot see the original |
This device downloaded a .lock / .enc |
The browser produced a ciphertext file | The original name in the header is hidden too |
| Network does not find the canary | These requests did not carry those fields | Extensions, the clipboard, and the next version are clean |
Check it now: Network, the header, and offline
Slogans are not evidence. Prepare a disposable small file. Put canary-fp-20260904-zip-vs-gcm in the body and name it canary-fp-20260904.txt. Use a one-time long passphrase. Do not reuse a real one.
- Run the control first: pack the same file into a password-protected ZIP. Open it in an extractor without entering the password. Note whether filenames are visible, and whether properties say ZipCrypto or AES. That is the range a ZIP password actually covers.
- Then encrypt locally in the browser. Open DevTools Network, check Preserve log, and leave the filter on All. After encryption finishes, paste the canary into the search box. It should not appear in request lines, bodies, or analytics.
- Open the downloaded
.lockin a hex viewer. The first four bytes should beCSLK(43 53 4C 4B). Further on you should see the salt, the chunk size, and the original filename you left. The content region should not still show that canary sentence in plaintext. - After the page has loaded, switch Network to Offline or turn off system networking, then encrypt another disposable small file. If a
.lockstill downloads, this encrypt/decrypt did not need a live API. Offline must pass; when you reconnect, search the canary again.
Do not send the passphrase on the same channel as the ciphertext. Put the .lock in Drive; send the passphrase through Burn-Link: this browser encrypts with AES-256-GCM, the server stores ciphertext only, and the key sits in the link’s # fragment as s.html?id={id}#{key}. Dropping the full burn address into the same Drive folder as the ciphertext is taping the key to the box.
Rename the source to something meaningless before you encrypt. The header writes that name as-is; the .lock / .enc extension also appears in the Drive list. That only reduces “the filename itself leaked.” It is not steganography.
Three cases that look encrypted and do not block what you think
First, “encrypt and zip” on a website. Some drives pack after the upload finishes, or wrap a share with an extraction code. That code stops people who will not click the share link. It does not stop a server that already stored the original. The check: did encryption happen before you picked the file, or after the progress bar completed? The second case is not local AES-GCM.
Second, an Office or PDF open password. That protects the matching reader’s open flow. The file format still holds a lot of structured fields; Drive preview, full-text search, and conversion services often walk around “prompt for a password on open.” Do not treat that as whole-file authenticated encryption.
Third, renaming the extension. Changing .xlsx to .bin before upload does not stop instant upload or some scanners, which still work from a content hash; the magic in the header is still there. An extension is not cryptography. After local encryption, those magic bytes should be gone from the content region. If a hex dump still shows PK, %PDF, or a plaintext xlsx marker, this run did not pass.
FAQ
If I set an AES-256 password on a ZIP, is it still unsafe to upload to Drive?
The content layer is stronger than ZipCrypto, but filenames, dates, and sizes in the ZIP directory stay readable by default. Drive and anyone who has the archive can list the files. It is also not AES-256-GCM in the browser: WinZip AES uses a different wrapping, and PBKDF2 runs 1,000 iterations. If you want the cloud to see only ciphertext, encrypt the whole content locally first, then upload.
If Drive says encryption in transit and at rest, is that enough?
That is usually default encryption with keys the provider holds. TLS covers the path; at-rest encryption covers a stolen disk. The provider, operators with key access, and a lawful request can still recover your original bytes. For Google Drive to make “Google cannot decrypt this” a fact, a Workspace admin must enable client-side encryption. That is not the default path when a personal account drags a file into My Drive.
After I upload a FastPwd .lock, can the cloud still see the original filename?
Yes. It can see the extension, and it can read the original filename and MIME from the header. What is encrypted is the file content in 1 MB chunks—not the container’s metadata. Rename the source to something meaningless before you encrypt. Do not put the passphrase in the same share as the ciphertext.
When I encrypt on FastPwd, does the file or passphrase get uploaded?
Per the product notes, encrypt and decrypt finish in the current tab with Web Crypto. The file and passphrase are not sent as business data and are not written to analytics. Visit analytics records action names, not the file or passphrase. Search Network for a canary: it should not appear in request lines or bodies. Localhost does not send visit analytics by default; retest on the live hostname for a closer match to real use.
Run the same disposable file through a ready-to-use tool
If you want a page that writes the compute boundary in the open, open FastPwd File Encryption Box. Ready to use; no signup. Pick the canary file above and a one-time long passphrase. If the passphrase is scored weak, the page asks you to confirm before it continues. Download the .lock. Watch Network at the same time: you should see static assets and maybe visit analytics, not the original file or passphrase as business fields.
You can generate the passphrase locally in the password generator. Random mode is 6–128 characters, default 16; shorter than 8 is flagged as weaker. Generation is not uploaded either. When a coworker must receive the passphrase, switch to Burn-Link. Do not put it in a Drive comment. Do not stuff a one-line secret into a .lock as a transport—File Encryption Box is for backing up and handing over a whole file, not a secret that belongs in a chat line.
Remember three things before the next upload. First, a ZIP password blocks extraction, not the directory, and not a known-plaintext attack on ZipCrypto. Second, default cloud encryption usually leaves the keys with the provider. Third, local AES-256-GCM protects content chunks; the header and the extension can still leak, so look at Network and a hex dump yourself. An observation you can repeat is the one worth writing into your own backup notes.
Further reading
“Local encryption, nothing uploaded” is not evidence until you search Network with a canary—see How to check if browser encryption never uploaded plaintext. When you hand a passphrase to the recipient on its own channel, see why the part after the hash stays out of HTTP by default in Why a URL hash can hold a key, and when that protection fails. If you also need to mask ID numbers in a ticket before they leave this machine, see Before you paste tickets and logs into AI, check which fields leave this machine.