2026-07-28

Cloud storage "encryption" vs. encrypting the file yourself: what actually protects tax documents and pay stubs

Sending a scanned tax return to an accountant, or a pay stub to a parent helping with a loan application, most people reach for whatever cloud drive is already open and generate a share link. It takes ten seconds, and the app's settings page usually says the file is "encrypted" somewhere. That word is carrying more weight than it should. Cloud storage's own encryption and encrypting the file yourself before it ever gets there protect against genuinely different failure modes — and that difference is exactly what turned a real, well-documented 2023 cloud exposure into a three-year leak instead of a non-event.

"Encrypted" describes three different things, and cloud storage usually means the first two

When a storage provider's settings page says your files are encrypted, it's almost always describing two specific protections. The first is encryption in transit: Google Cloud's own documentation describes this as protecting the network hop itself, using TLS between your device and the provider's servers — it says nothing about what happens at either end, where the data is plaintext by definition, since that's what your device sent and what the server needs to store or process it. The second is encryption at rest, protecting the copy sitting on the provider's disks. Here Google Cloud's own documentation is direct about who holds the key by default: "We own and manage the keys used in default encryption at rest." That's not a criticism specific to one vendor — it's how mainstream cloud storage works across the industry, and it means exactly what it says: the provider can decrypt your file whenever its systems need to, because the provider is the one holding the key. The third kind — client-side encryption — is different in a specific, structural way: the file becomes unreadable ciphertext before it ever leaves your device, using a key the provider never has. Most cloud storage services don't do this by default, because it would break features like previews, search, and in-browser editing that need the provider's servers to read the file.

What "at rest" doesn't protect against

A real case shows exactly where that gap opens up. In July 2020, a Microsoft AI research team published an Azure Shared Access Signature (SAS) token to a public GitHub repository, intending to share a folder of open-source AI models. The token was misconfigured twice over: instead of read-only access to that one folder, it granted "full control" over the entire storage account, and its expiration was set to 2051 — effectively permanent. Wiz Research discovered the exposed token on June 22, 2023, and reported it; Microsoft revoked it two days later, with public disclosure following on September 18, 2023 — roughly three years after the token first went live. What sat behind that link the whole time included two employees' full workstation disk backups and more than 30,000 internal Microsoft Teams messages. The storage account's own at-rest encryption was almost certainly on, exactly as Azure's defaults would provide — and it made no difference, because the SAS token itself was a credential that unlocked already- decrypted access. Worth being precise about scope here: this was an enterprise Azure Blob Storage account, not a personal Dropbox or Google Drive share. But the mechanism it exposed is the same one behind the "anyone with this link can view" option sitting in the share menu of every mainstream personal cloud drive — a link that, once created, forwarded, left in an old email thread, or picked up by a search crawler, hands out exactly the same decrypted access a legitimate viewer would get. "Encrypted at rest" was a true statement about that storage account the entire time, and it was irrelevant to what actually happened.

What changes when the file itself is ciphertext before it goes anywhere

Client-side encryption doesn't make a cloud provider more trustworthy or a share link harder to mis-scope — it makes both of those questions stop mattering for that particular file. If the ciphertext ends up somewhere it shouldn't — an over-shared link, a misconfigured bucket, a provider breach that reaches the storage layer — what leaks is still ciphertext, unreadable without the passphrase that was never uploaded anywhere in the first place. That's a meaningfully different guarantee than "the provider says this is encrypted," because it doesn't depend on every access control downstream of your upload being configured correctly, indefinitely, by someone else. The SAS token above stayed live for roughly three years before anyone caught the misconfiguration — that's not a rare kind of mistake, it's the ordinary failure mode access control eventually has.

A concrete way to send tax documents or a pay stub

The practical version of all this is a short checklist, not a philosophy. First, encrypt the actual file on your own device before it goes anywhere near a cloud drive, an email attachment, or a share link — don't rely on the provider's built-in "encrypted" label to do that job. Second, once the file itself is ciphertext, the channel you use to send it stops being the thing that decides whether the data is safe; email attachment, cloud link, USB drive, it no longer matters which one leaks. Third, send the passphrase somewhere other than alongside the file — a phone call, a text on a different app, in person — so a single compromised inbox or oversharing mistake can't hand over both the lock and the key at once. Fourth, actually confirm the recipient can open it before assuming the job is done; an accountant who's never seen a passphrase-protected file before may need a one-line explanation of what to do with it.

Where NearSeal fits into this

NearSeal is built for exactly the first step in that checklist, and it's worth being precise about the boundary. It runs entirely in the browser — the file and the passphrase never leave the device, there's no upload step for either. By default it derives an AES-256-GCM key from your passphrase via PBKDF2-SHA256 at 2²⁰ iterations (its NSEAL1 format); if you'd rather the result open in the official age or rage CLI too, not just this site, there's an opt-in age-encryption.org format instead (scrypt for key derivation, ChaCha20-Poly1305 for encryption). Either way, what leaves your device afterward — over whatever email, cloud link, or drive you choose — is already ciphertext. What NearSeal can't do is fix a share link scoped too broadly or an inbox that gets the wrong recipient; no client-side tool reaches that far into someone else's account settings or your own typing. What it can do is make sure that whichever channel ends up carrying the file, the contents inside it don't depend on that channel getting everything else right.