Security · 2026-07-20 · 9 min read
Most advice about protecting sensitive documents stops at “use a secure provider”, which is not advice so much as a purchasing suggestion. It also quietly assumes the provider is the only thing that can go wrong. In practice the document that leaks is rarely the one sitting in a well-run data centre. It is the scan of a passport that was emailed once, ended up in a Downloads folder, got swept into a sync client, and now exists in four places nobody is tracking.
So here is the other approach: make the file unreadable to everyone but you before it goes anywhere, and then stop caring quite so much where it goes. It takes about ten minutes to set up and roughly one minute per document afterwards.
First, decide what actually qualifies
Encrypting everything is a fantasy that collapses within a week, because you lose search, previews and easy sharing across your entire life. Encrypting the right twenty files is sustainable and covers most of the real exposure. A useful test: would you be uncomfortable if this document appeared in a stranger’s inbox, and would that discomfort last longer than a day? If yes, it belongs in the protected set.
- Identity documents — passport and ID scans, birth and marriage certificates, residency paperwork.
- Financial records — tax filings, bank statements, anything with an account number on it.
- Legal and business documents — signed contracts, cap tables, board material, NDAs, incorporation papers.
- Health records — test results, diagnoses, insurance claims.
- Credentials and recovery material — key backups, recovery codes, and seed phrases (which deserve their own offline handling entirely).
The workflow
Step 1 — encrypt on your own machine
Pick one tool and use it consistently. All of these are free, mature, and produce a file that is meaningless without the key.
| Tool | Best for | Why you would pick it |
|---|---|---|
| age | Single files and folders | Modern, tiny, one command, hard to misuse. The default choice today. |
| GnuPG | Anyone already in a PGP workflow | Ubiquitous and battle-tested, but the interface punishes mistakes. |
| 7-Zip / Keka | Non-technical family members | AES-256 with a password, a normal GUI, works everywhere. |
| VeraCrypt | A whole encrypted container | Mount it like a drive; good when you have many small documents. |
| rclone crypt | Automated, recurring uploads | Encrypts transparently as part of a sync job. |
Step 2 — handle the key like it is the document
This is the step people skip, and it is the one that decides whether the whole exercise helps or hurts. Real encryption means a lost key is a lost file, permanently, with no support line to call. Treat the key as the actual asset: store it in a password manager you already trust and back up, keep a second copy somewhere physically separate — a printed copy in a safe is not old-fashioned, it is uncorrelated with every digital failure — and never store the key alongside the ciphertext it opens. That last one sounds obvious and is violated constantly.
Step 3 — put the ciphertext somewhere durable
Once the file is encrypted, the storage layer no longer needs to be trusted with your secrets — it needs to be trusted to still be there. Those are very different requirements, and the second one is where most setups are actually weak. What you want now is a copy that does not depend on a single company continuing to exist, continuing to like you, and continuing to charge a price you accept.
This is where a decentralized network is a genuinely good fit. On Walrus Drive your encrypted file is split into redundant pieces spread across independent operators, and its existence is certified on the Sui blockchain — there is no account anyone can suspend, and losing several operators does not lose the file. Because you encrypted it in step 1, the fact that the network is public is not a problem; the bytes are meaningless without your key. And because we do not encrypt anything for you, there is no vendor claim you have to take on faith.
Step 4 — write down what you did
One plain text file, kept with your important paperwork: which tool encrypted what, where the key lives, and where the copies are. It feels excessive right up until the day someone other than you needs to find these documents, and then it is the only thing that matters. If you are storing on a network, record the blob identifiers too — they are your handles to the data.
Encrypt for confidentiality. Distribute for durability. They are two separate problems and one product almost never solves both well.
What this protects you from, honestly
| Threat | Does this workflow stop it? |
|---|---|
| A provider breach exposing your documents | Yes — they only ever held ciphertext |
| An insider or a lawful data request | Yes — there is nothing readable to hand over |
| Your account being closed or the company folding | Yes — the durable copy has no account and no company |
| A dead laptop or a house fire | Yes — provided the copies are genuinely off-site |
| Malware already running on your machine | No — it can read the file while you can |
| You losing your key | No — and this becomes your main risk, so plan for it |
That last row is the honest trade. You are exchanging “a company might expose my documents” for “I must not lose a key”. For most people that is a good exchange, because the second risk is one you control and can prepare for, while the first one you can only hope about. Decide retention deliberately too — network storage is paid by size and duration, and the pricing page will show you the live cost for a decade of a few hundred megabytes before you commit to anything. It is usually far less than people expect, which is the point of Cold Archives.