Why Encryption Is Not Enough
Encryption is necessary. It is not sufficient.
Every mainstream answer to "what is the most secure way to store sensitive files?" ends at the same place: encrypt the file, hold the keys yourself, pick a provider with a good audit history. That advice was correct when the threat was an opportunistic attacker with a limited budget and a limited window.
It is no longer the whole answer, because encrypted data still has one property that decides the outcome of a breach: the file exists whole, in one place, under one operator, in one jurisdiction.
Why is encrypted cloud storage still a single point of failure?
Client-side encrypted storage fixes one problem well. The provider cannot read your plaintext. That is real, and it is better than the default.
But it leaves the shape of the target unchanged:
- The complete ciphertext sits in one account. One credential compromise, one misconfigured bucket, one insider, and the attacker has all of it. Not a fragment. All of it.
- One operator can be compelled. A subpoena, a national security letter, or a change of ownership reaches every object in the account at once.
- One jurisdiction sets the rules. Data residency is a single legal regime, and legal regimes change.
- One vendor decides whether you still have access. Account termination, an outage, or a company failure is a total loss event.
Each of those is a single point of failure that encryption does not touch. Encryption protects the contents of the target. It does nothing about the existence of the target.
What is harvest now, decrypt later?
An adversary does not need to decrypt your data today to benefit from stealing it today.
The pattern is simple: exfiltrate ciphertext now, store it cheaply, and decrypt it when capability catches up. Storage is close to free. Patience is free. The only question is whether the data still matters when the decryption becomes practical.
For most operational data, it will not. For the data Untrace is built to hold, it will:
| Data | Sensitivity lifetime |
|---|---|
| Session token | Hours |
| Card number | Years |
| Passport scan, national ID | Decades |
| KYC and residency documents | Decades |
| Medical records | A lifetime |
| Genomic data | Beyond a lifetime, and it implicates relatives |
Encryption is a bet that the algorithm outlives the value of the data. For a session token that is a safe bet. For a passport scan collected during onboarding, you are betting a specific cipher and a specific key length against a multi-decade horizon that includes cryptanalysis you cannot forecast and hardware that does not exist yet.
That bet is covered in detail in Post-Quantum and Harvest Now, Decrypt Later.
How do AI agents change the attack economics?
The second shift is on the intrusion side, and it is already here.
Autonomous agents probe infrastructure continuously. They read your dependency tree, your public commits, your job postings, your error pages. They generate and test phishing content against your staff. They fuzz your endpoints. They do it for weeks without fatigue, at a cost that no longer scales with attacker headcount.
This inverts the economics that most security programs were sized for:
- The defender must be correct on every endpoint, every dependency, every release, every employee, every day.
- The attacker needs one opening, once.
- Reconnaissance that used to take a skilled human a week now runs unattended and in parallel across every company in a target list.
You cannot win an asymmetry like that by being more careful. Given enough attempts, something gets through. Assume the breach happens.
The useful question is not "how do we prevent every intrusion?" It is "what does an attacker actually hold after a successful intrusion?"
What actually survives both threats?
Only one property survives both a patient ciphertext harvest and a successful intrusion: the complete file never exists in any single location, so no single compromise yields it.
That is an architectural property, not a defensive one. It does not depend on the attacker failing. It changes what a success is worth.
Untrace's pipeline produces exactly that property:
- Data is encrypted on your device, before anything leaves it.
- The encryption key is split with Shamir's Secret Sharing into N shares, of which any K can rebuild it.
- The encrypted payload is erasure-coded into N recoverable shards.
- Each shard bundle goes to a different, independently operated node, and those nodes sit in different trust domains, jurisdictions, and technology stacks.
- Retrieval requires a wallet-signed request, verified by each node before it releases anything.
An attacker who fully compromises one node holds one encrypted payload shard and one key share. That is not a partially decrypted file, and it is not a weakly protected file. Below the threshold, a set of key shares is information-theoretically nothing: every possible key remains exactly as likely as every other. There is no computation, quantum or otherwise, that extracts a secret from information that is not present.
To get your file, an attacker has to compromise K independent providers, in different jurisdictions, running different software, at the same time, and also obtain your signing key. Untrace Cloud Drive ships a 2-of-4 configuration, so that is two separate providers plus your signature rather than one account. Enterprise deployments raise K deliberately, and each increment adds another independent operator to the list an attacker has to defeat.
That is the difference between a hard target and a meaningless one.
What this does not claim
Untrace's model is specific, and overstating it would be the same mistake as trusting encryption alone.
- It is not unbreakable storage. An attacker who compromises K of N nodes and obtains your wallet signing authority can reconstruct the file. The design raises that bar to a coordinated multi-provider, multi-jurisdiction compromise. It does not remove it.
- It does not protect an endpoint that is already compromised. Encryption and reconstruction happen on your device. Malware with control of that device at the moment you reconstruct a file sees the plaintext, as it would with any system.
- It does not make key management disappear. It replaces "do not lose this password" with threshold recovery and self-custodial signing, which is a different set of tradeoffs, not the absence of tradeoffs.
What it does remove is the single target. That is the property that decides whether one mistake becomes one incident or one catastrophe.
Next
- Post-Quantum and Harvest Now, Decrypt Later covers why threshold sharing is unaffected by future compute.
- Untrace Compared to Other Storage puts this side by side with encrypted cloud, IPFS, and self-hosted storage.
- Sharding Data Layer is the full technical pipeline.