Before you drop a file in the cloud, who can read the plaintext — and which path the passphrase should take

Certificate packs, exported staff sheets, and configs that still hold a private key often end up in personal Drive or a company shared folder. The upload page will say “encryption in transit,” “encryption at rest,” or “vault.” Those phrases name the provider’s disks and pipes, not “nobody but you can open this.” Another article already covered how to check Network that plaintext did not leave: slogans are not evidence. This piece is a narrower scene — the file is about to leave this computer and sit on someone else’s storage. First split who can read the plaintext. Then decide which path the passphrase should take.

This is not a feature tour of “online file encryption,” and it is not a review of which cloud to pick. Three questions only: before anything leaves, did plaintext become ciphertext first; after upload, can the provider or the next downloader open the body as-is; did the passphrase travel in the same message as the .lock or .enc. MyPassGen’s file encryption page works on that boundary: AES-256-GCM finishes in the browser, then you download the result. The file and the passphrase are not sent as business data. Every tool opens without an account. The table and the steps below are things you can check on the spot.

“Encrypted” often names the provider’s layer

HTTPS only covers eavesdroppers on the path. Once the file reaches Drive, Dropbox, or OneDrive, the provider can still land it as plaintext or as ciphertext they can unwrap. Many products label that provider-held-key at-rest encryption as “your files are encrypted.” For operations, that helps if a disk walks out of a data center. For “I do not want the storage side to open a passport scan,” it is not enough.

Encrypt on the client first, then upload: that is a different layer. The browser or a local program derives a key from a passphrase you hold. The store keeps ciphertext. Rclone Crypt, some sync tools, and Web Crypto in a tab all sit on this layer. They answer “the storage party cannot use the body.” They do not answer a weak passphrase, a passphrase sent with the file, or a filename that already names the contents.

GDPR Article 9 treats biometric data used to uniquely identify a person, and other special-category data, as needing a specific lawful basis. An unencrypted passport scan dropped into personal Drive and then forwarded to a group chat still transfers the identifying document. Encrypt-then-upload reduces who can open the bytes. It is not anonymization, and it does not replace “should this file leave the machine at all.”

Who can read the plaintext

Put the same certs.zip into cloud storage and you can already split three classes. The difference is not the marketing line. It is who holds the key, and whether plaintext left the browser first.

Only the third class answers “I do not want the storage side to see the body.” Encryption has to finish before upload, and the key must not be handed to that storage machine. The previous article already said this: the Web Crypto API guarantees that the math can run on this device. It does not forbid a page from uploading first and encrypting later. “Encrypt locally first” has to be checked in traffic. It cannot be checked in a slogan.

What AES-256-GCM does at this step

MyPassGen’s first release uses AES-256-GCM only. NIST SP 800-38D specifies GCM as authenticated encryption: if the ciphertext is altered, decrypt should fail. You do not get a garbled body that you might treat as a document. RFC 5116 AEAD_AES_256_GCM uses a 32-byte key, a 12-byte nonce, and a 16-byte authentication tag. MDN’s AesGcmParams likewise recommends a 96-bit IV, and you must use a fresh IV for every encryption under the same key. The IV is not a secret. It can travel with the ciphertext.

The passphrase is not used as the AES key. This site’s file box runs PBKDF2 with 100,000 iterations, SHA-256, and a 16-byte salt, then a 256-bit key. The salt lives in the file header so decrypt can recompute the same key. RFC 8018 cites NIST SP 800-132: the iteration count should be as high as an acceptable wait allows. OWASP’s current advice for stored password hashes on a server is PBKDF2-HMAC-SHA256 at least 600,000 iterations. That is a different job. The first line of defense for a file passphrase is still a long random string. Iteration count slows offline guessing. It does not save 123456 written in a Drive comment.

Do not send the passphrase with the ciphertext

The usual failure is not the wrong algorithm. It is sending backup.lock and “the passphrase is summer plus the employee id” in the same Slack thread, the same email, or a readme.txt sitting in the same Drive folder. The storage side or anyone in that channel then holds both halves. Local encryption did nothing.

A safer split: ciphertext goes through Drive or an email attachment; the passphrase goes on another channel — in person, by phone, or a one-time link (the key sits after # in the URL; the read page does not need an account). Do not put the passphrase in the filename, in a zip comment, or in a “only I can see this” note that still lives under the same cloud account.

Generate the passphrase on this machine with the password generator. Random mode is 6–128 characters, default 16. Below 8 should be treated as weak. A forgotten passphrase cannot be recovered: there is no server-side plaintext backup, and there are no security questions. That is the cost of the store not seeing the body. It is not a missing feature.

What a .lock file still shows

Ciphertext is not “the whole file turned into unreadable noise.” A public container header often still carries metadata. MyPassGen defaults to .lock and can also write .enc — the same format, different extension, so it lines up with other tools. The header starts with four bytes CSLK, then a version, a 16-byte salt, a chunk size, and the original filename and MIME type in plaintext. The body is AES-GCM in roughly 1 MB chunks. Each chunk carries its own 12-byte IV and 16-byte tag.

So if you encrypt passport-scan.pdf into passport-scan.pdf.lock and upload that, the Drive listing and the file header both still say “this is an identity document.” Encryption protects the bytes of the body, not the name. When the name is sensitive, rename the original to something meaningless before you encrypt. Do not give the uploaded .lock a readable title either.

One file can be up to 5 GB. Encryption slices with Blob.slice into about 1 MB, then hands each slice to crypto.subtle.encrypt. Web Crypto’s encrypt() takes one BufferSource at a time. Feeding the whole file in one call will pin a large tab’s memory. Slicing avoids “give the whole plaintext to the API at once.” The result is still assembled on this machine for download. Decrypt currently reads the entire .lock first, so a very large file costs more memory — that is a fact you can see in the task manager, not a slogan.

Check it on the spot

The steps below do not depend on a brand promise. Use a disposable small text file. Do not practice on a real ID scan.

1. Create a few-dozen-byte probe.txt and write a test phrase only you know, for example orange-lake-7. Do not use a real passphrase or an ID number.
2. Open DevTools Network and enable “Preserve log.” Open the file encryption page, pick that file, set a passphrase, and start encryption.
3. Read each Fetch / XHR: the request line and the request body should not contain orange-lake-7, and they should not contain the passphrase you just typed. Analytics should not carry the original either. Scripts, styles, and stats that do not include a file body are allowed.
4. Download the .lock or .enc. In a hex viewer, the first four bytes of the header should be 43 53 4C 4B (ASCII CSLK). Further in you should still see the original name probe.txt in plaintext — not the test phrase itself.
5. Drop that ciphertext back on the same page. The correct passphrase should restore the test phrase. Change one character of the passphrase and decrypt should fail. You should not get a garbled body.
6. Only then upload the .lock to Drive or Dropbox. Send the passphrase in a different message. Open the cloud preview: without the passphrase, the original should not open.

MyPassGen’s file encryption page works on that boundary: AES-256-GCM, PBKDF2 at 100,000 iterations, one file up to 5 GB, output .lock / .enc. Computation finishes in the current tab. You do not create an account. What you trust is still Network and the file header, not the five words “we do not upload.”

Short secrets should not become whole files

An API key, a recovery code, or a database password does not need to become a file first. The whole-file path fits certificate packs, exported sheets, and disk-image slices. Short text belongs on a one-time link: plaintext up to 32 KB, the server holds ciphertext only, the key sits after #, and you can set read count and TTL. Create and read both work without signing in.

Outbound notes are a different job. A URL with utm_source follows which parameters you can strip. Phone numbers and ID numbers in a ticket follow which fields you must mask. Encrypting a file answers “the storage side cannot open the body.” It does not answer “this discussion should not carry a complete number.”

Common mistakes

“The cloud says encrypted, so only I can read it.” When the provider holds or manages the keys, ops staff, a legal demand, and a stolen account still see a usable file. Encrypt locally first, and the set of people who can unwrap it shrinks to people who hold the passphrase.

“HTTPS already protects the whole trip.” HTTPS ends at the provider’s ingress. After the file lands, the protection boundary changes hands. What you are reducing is plaintext in the copy that sits at rest.

“Renaming to .lock is encryption.” A renamed file that never went through authenticated encryption still searches as plaintext in a text editor. The header should have an agreed magic, and the body should not open. Changing the suffix alone does nothing.

“I forgot the passphrase; support can reset it.” Zero-knowledge storage has no server-side passphrase copy. The footer also does not offer a support inbox to “reset an encryption passphrase.” The passphrase lives in your own password manager, or on another channel you control.

Where to start

Start with the one file you have to upload today. Run the six steps above on a disposable small file. Confirm Network has no original, the header is CSLK, and a wrong passphrase fails. Then encrypt the real file. If the name is sensitive, rename it first.

Upload ciphertext to Drive or attach it to mail. Say the passphrase in person, call it in, or create a one-time link. Do not drop the passphrase into a text file in the same folder. After that one pass you can already answer the title: the storage side should not get plaintext; the passphrase should not travel with the ciphertext; the header may still show the original name, and that name needs its own step.

FAQ

How is a provider “vault” different from encrypting locally first?

A vault usually still has the provider holding or managing the keys. Sign in to the same account and you can open the file. After you encrypt locally, the storage side cannot unwrap the body without the passphrase. If the account is stolen, someone without the passphrase can only download ciphertext.

If I forget the passphrase, can I still decrypt?

No. There is no server-side plaintext or passphrase backup. Use a long random passphrase and keep it in your own password manager. That is the matching cost of “the storage side cannot see the body.”

What is the difference between .lock and .enc?

On this site they are the same container with different extensions. Decrypt accepts either suffix. Do not assume another program’s .enc uses the same header.

Do I need an account to encrypt? Is the file uploaded?

No account. The log risk starts when you hand the original to a site that encrypts for you. Local processing keeps the file and the passphrase in the current tab. What you check is whether Network sent a file body or a passphrase, and whether you can still search the .lock for the test phrase.