2026-09-07

When file encryption is the wrong tool: sync folders, shared work, and Git

Almost every piece of advice about file encryption has one setting: yes. Is it sensitive? Encrypt it. That answer is right often enough to pass for universal, and it quietly hides what encryption actually is. It is not a property you add to a file, like a tag. It is a trade. You give up everything a computer can do with readable bytes — sync a change efficiently, merge two edits, show a preview, produce a diff, scan for malware, search the contents, grant one person access and not another — in exchange for the bytes being useless to anyone without the passphrase.

When a file is on its way out of your hands, that is an excellent trade. When the file is staying put, being edited every week, and shared with four colleagues, it is frequently a bad one, and the bill arrives later: a folder of undated blobs nobody can tell apart, a repository that has quietly tripled in size, a passphrase three people know and one of them has left the company. This post is the half of the advice that rarely gets written down — the three places where reaching for a file encryptor makes your situation worse, and what the right tool is in each. We make one of these tools. A tool that only ever answers yes is marketing, not advice.

One question sorts nearly every case

Is this file leaving, or is it living?

A leaving file is finished. It is about to cross a boundary you do not control — an email attachment, a USB stick going in a drawer, an archive uploaded to storage you will not touch again, a laptop going in for repair. Nobody will edit it in that state. There is one handoff, and it has an end. Encryption fits this shape exactly, because the awkward parts of encryption — no merging, no preview, no partial update — describe things you were never going to do to that file anyway.

A living file is the opposite. It will be opened, changed, saved, and opened again, possibly by someone who is not you, possibly on three devices. Every one of those verbs is a thing encryption removes. Applying a handoff tool to a living file does not make the file safer so much as it makes the file harder to work with, and the usual outcome is that somebody works around it — by keeping a decrypted copy "just while I'm editing," which is exactly the plaintext you were trying not to have lying around.

Wrong tool 1: a file you keep editing, inside a sync folder

This is the most common mistake and the least visible one, because nothing breaks. The file syncs. It just costs far more than you think, and it takes away the safety net you were counting on.

Start with what a re-encryption actually produces. NearSeal, like any competently built file encryptor, generates a fresh random salt and a fresh random initialization vector every single time it encrypts something. That is not an implementation detail you can turn off; it is what stops two encryptions of the same file from being comparable, and it means the output is completely different bytes on every save, from the first byte onward, even if you changed one comma.

Now look at what that does to sync. Dropbox's own engineering write-up on streaming file synchronization describes the mechanism: "Every file in Dropbox is partitioned into 4MB blocks, with the final block potentially being smaller. These blocks are hashed with SHA-256 and stored. A file's contents can be uniquely identified by this list of SHA-256 hashes, which we refer to as a 'blocklist'." The efficiency of a design like that comes from blocks whose hashes did not change. An encrypted file has none: every block is new every time. A 300 MB encrypted archive that you touch weekly is a 300 MB upload weekly, and the same download on every other device you own — where the same archive stored as ordinary files would have moved a few megabytes.

The worse loss is the safety net. Cloud version history is genuinely useful for a plain document: you can look at Tuesday's version, see it is the one before the bad edit, and restore it. Version history for an encrypted blob is a list of timestamps attached to files you cannot preview, cannot search, and cannot tell apart without downloading each one and decrypting it. You still have the versions. You have lost the ability to know which one you want.

Then there are conflicts. Dropbox is explicit that it does not resolve them for you: "A conflicted copy is a file that Dropbox creates when multiple people edit the same file at the same time," and its guidance is that "the best way to resolve a conflicted copy is to compare both versions and merge them manually." Comparing and manually merging is a reasonable instruction for a spreadsheet. For two encrypted containers it is not an instruction at all — there is nothing to compare until both are decrypted, and no way to merge the results back into one. Dropbox has a separate help page for encrypted files stuck in sync conflict, and its advice is essentially triage: move the local version out of the Dropbox folder so the remote version can come down. One of your two versions gets picked up and carried out of the way.

And the failure that actually loses data is more mundane than any of this. To work on the file you decrypt it, and the decrypted copy lands in the synced folder next to the encrypted one. Now the plaintext is the thing being replicated to every device and every backup. NIST's Guide to Storage Encryption Technologies for End User Devices (SP 800-111, November 2007) makes the general form of this point: "when a file is encrypted using file/folder encryption and the original file is deleted, the remnants of the original plaintext file might still be present on the storage media."

What to use instead. For a file that lives on your machine, the tool that matches the threat is disk encryption — FileVault on macOS, BitLocker on Windows. It protects the whole device against the realistic threat to a device (it is lost or stolen), and it costs you nothing in workflow: no re-uploads, no conflicts, no blobs. SP 800-111 describes exactly this layering as normal practice — full disk encryption "to protect all data on a device from device loss or theft," with file-level encryption "to provide additional protection for a subset of data that is more sensitive than the rest." Encrypt individual files for the moment they leave, not for the years they stay.

Wrong tool 2: sharing with a team, over time

A passphrase feels like a permission. It is not one, and the difference is the whole problem.

A permission has a subject. It belongs to one named person, it can be granted on Tuesday and withdrawn on Friday, and the withdrawal is a single action that takes effect immediately and leaves a record. A passphrase has none of that. It is a fact that some number of people now know. There is no list of who those people are, no log of who opened the file and when, and no expiry.

Watch what happens when someone leaves the project. To remove their access you have to change the passphrase, which means re-encrypting the file, which means delivering a new passphrase to every remaining person through a channel that is genuinely separate from the file — and doing that again the next time anyone leaves. Meanwhile the old encrypted copy on their old laptop still opens with the old passphrase, because it is the same file it always was; you have not revoked anything, you have only stopped issuing updates. This is not a NearSeal quirk. git-crypt, a tool built specifically for keeping encrypted files in shared repositories, states the same limitation plainly in its own README: it "does not support revoking access to an encrypted repository which was previously granted."

The everyday friction is just as decisive. Two people cannot edit an encrypted container at once, so the group falls back to taking turns and announcing it in chat. Nobody can search across the files. Nobody can link to one. Comments and review tools do not work. Within a few weeks the usual thing happens: one person keeps a decrypted copy on their desktop because it is the only way to get work done, and the group's real security posture becomes that copy.

What to use instead. For an ongoing shared working set, use a platform whose access model can actually express what you need — per-person access, immediate revocation, an access log — and keep file encryption for the moments material crosses out of that platform: the export you email to outside counsel, the archive that goes to a client, the copy on the USB stick. There is also a real cryptographic answer to per-person access, which is encrypting to recipients' public keys rather than to a shared secret; the age format supports that mode. NearSeal does not expose it — it is passphrase-only, deliberately, because a browser tool with no accounts has no sane place to keep a key list — so if you need per-recipient keys, you need the age command-line tool, not this website.

Wrong tool 3: committing the encrypted file to Git

The instinct is understandable: the secret has to live somewhere the team can find it, the repo is where the team looks, so encrypt it and commit it. Git is the environment where an encrypted blob is least at home.

Git stores every version of a file as its own object, and shrinks history by looking for similarity between objects — the packing documentation notes that objects are "compared against the other objects within --window to see if using delta compression saves space." Encrypted output is built to be indistinguishable from random data, so there is no similarity to find, between versions or anywhere else. git-crypt's README says it in four words: "Files encrypted with git-crypt are not compressible." Practically, each commit that touches the file adds its full size to the repository, permanently, for everyone who clones. GitHub's documentation on large files warns at 50 MiB, blocks files over 100 MiB outright, and recommends keeping repositories under 1 GB, which a weekly-committed encrypted archive will reach faster than anyone expects.

You also lose the thing you use Git for. A diff shows two walls of base64 or binary noise, so review is blind and git log -p tells you nothing; git blame has nothing to attribute; a merge conflict inside the blob cannot be resolved, only chosen between. There is a reason git-crypt takes a design decision NearSeal explicitly does not: it encrypts "using AES-256 in CTR mode with a synthetic IV derived from the SHA-1 HMAC of the file," deterministic on purpose so that Git can tell whether the file changed. That determinism has a documented price — it "leaks no information beyond whether two files are identical or not," which is a real leak, accepted because version control cannot function without it. NearSeal makes the opposite choice, random salt and IV every time, which is the right choice for a handoff and the wrong one for versioning.

And the trap that catches people is the one where encryption arrives too late. If the plaintext secret was ever committed and pushed, encrypting it in a later commit protects nothing: the earlier commit is still in the history, in every clone, and in every fork. GitHub's guidance is direct about the order of operations — if the sensitive data "is a secret (e.g. password/token/ credential)... as a first step you need to revoke and/or rotate that secret" — and warns that "if the commit that introduced the sensitive data exists in any forks, it will continue to be accessible there."

What to use instead. For credentials, the answer is almost always not to commit them at all: keep them out of the tree with .gitignore and hand them to the application at runtime from your platform's secret store or environment configuration. If you genuinely must version encrypted material — a config file with embedded secrets, say — use tooling designed for that job, such as git-crypt, rather than dropping an opaque container into the repo by hand.

What NearSeal cannot do for you

These are the limits of the tool we make, stated as plainly as we can put them.

If you forget the passphrase, there is no recovery of any kind. No reset link, no support ticket, no backdoor, no master key, no partial credit for a near-miss. Nothing is stored on a server because there is no server in this part of the product: the key is derived from your passphrase and a random salt kept in the file, and a wrong passphrase simply fails the authentication check. NIST puts the general rule in one sentence: "If a key is lost or damaged, it may not be possible to recover the encrypted data." Write the passphrase into a password manager at the moment you create it.

It cannot revoke, rotate, or expire access. There are no per-person keys and no record of who opened anything. A passphrase, once known, is known.

It cannot protect a machine that is already compromised. If there is a keylogger running, it reads the passphrase as you type it; if there is malware with access to your files, it reads the plaintext before you encrypt or after you decrypt. SP 800-111 states the general case: "if an end user device is compromised at any time, any storage encryption technologies on it may become partially or wholly ineffective."

It cannot rescue a weak passphrase. NearSeal's default format runs the passphrase through PBKDF2-SHA256 at 2²⁰ iterations before it becomes an AES-256-GCM key, which makes each guess expensive — but an encrypted file is just a file, and anyone holding a copy can guess against it offline, forever, with no lockout and nothing to trip an alarm. Length is what helps.

It does not hide the filename or the size. In the NearSeal format the original filename travels in the container header in the clear (from format version 2 it is bound into the authentication tag, so it cannot be altered undetected — but it is not secret); the age format has no filename field at all, so the name lives on the outside of the file where you put it. SP 800-111 flags exactly this: file-level encryption "cannot protect the confidentiality of filenames and other file metadata, which itself could provide valuable information to attackers (for examples, files that are named by Social Security number)."

And it is not disk encryption. It encrypts the copy you hand it; the original you dragged in is still wherever it was, and deleting it afterwards does not guarantee the bytes are gone from the drive. That is the job of FileVault or BitLocker, not of a web page.

The short version

Encryption is a handoff tool. It is very good at making a file safe to leave your hands, and it is bad at almost everything a file does while it stays. If the file is leaving — an attachment, a drive, an archive, a device going in for repair — encrypt it, and NearSeal will do that in your browser with nothing uploaded and no account required, in its own AES-256-GCM format or in the portable age format that opens in the official age and rage tools. If the file is living where it is, encrypt the disk instead. If it is living with other people, use permissions. The honest recommendation from an encryption tool is not "encrypt everything." It is "encrypt the things that are leaving, and know that when the passphrase is gone, so is the file."