Untrace Compared to Other Storage
Storage options are usually compared on price, capacity, and uptime. Those matter, but they do not answer the question that decides whether a breach is survivable:
After a successful compromise, what does the attacker actually hold?
This page compares the common architectures on that basis.
The architectures
Centralized cloud (S3, Google Drive, Dropbox, OneDrive). Files stored whole. Provider holds the keys and can read plaintext. Access controlled by account credentials.
Client-side encrypted cloud (Tresorit, Proton Drive, Cryptomator over any backend). Files encrypted before upload. Provider cannot read plaintext. The complete ciphertext still sits in one account with one provider.
Content-addressed distributed storage (IPFS, Filecoin, Storj). Content split and distributed for availability and durability. Encryption is the user's responsibility and is not part of the addressing model. Public IPFS content is retrievable by anyone holding the CID.
Self-hosted (your own NAS or servers). Full control, full responsibility. One physical location, one operator, one backup regime, one patching schedule.
Untrace. Encrypted client-side, key split by Shamir's Secret Sharing, payload erasure-coded, shards distributed across independent operators in different trust domains. Retrieval requires wallet-signed authorization verified per node.
Comparison
| Property | Centralized cloud | Encrypted cloud | IPFS / Filecoin | Self-hosted | Untrace |
|---|---|---|---|---|---|
| Provider can read plaintext | Yes | No | Depends on user | No | No |
| Complete file recoverable from one compromise | Yes | Yes, ciphertext | Often yes | Yes | No |
| Single point of failure | Yes | Yes | Partially | Yes | No |
| One subpoena reaches all data | Yes | Yes, ciphertext | Varies | Yes | No |
| Insider with full access exists | Yes | Limited | Varies | Yes | No |
| Harvest-now-decrypt-later exposure | Full | Full ciphertext | Full if unencrypted | Full | Sub-threshold shards only |
| Key protected information-theoretically | No | No | No | No | Yes, below threshold |
| Survives loss of one provider | No | No | Yes | No | Yes, K of N |
| Access control model | Password | Password | CID, effectively public | Password | Wallet signature |
Why "encrypted cloud" is the interesting comparison
Client-side encrypted storage is the strongest mainstream answer, and it is genuinely good. The provider cannot read your files. If your question is "can the vendor snoop?", the answer is already solved.
The gap is what remains true after that fix:
- The complete ciphertext is still assembled in one account. One credential compromise takes all of it.
- The provider is still a single legal entity in a single jurisdiction, reachable by a single order.
- The archive is still a single object that a patient adversary can copy once and hold indefinitely. See harvest now, decrypt later.
- Losing the account still loses everything.
Encrypted cloud storage makes the target opaque. It does not make the target smaller. Untrace's difference is that there is no assembled object to take.
Why distributed storage alone is not the answer either
IPFS and Filecoin distribute content, which sounds like the same idea. It is not.
Their splitting exists for availability and durability, not confidentiality. Content addressing is designed so anyone holding the identifier can retrieve the content. Chunks are not secret, and reassembly is the intended behavior of the network rather than a privileged operation.
Splitting an encrypted file into ordinary sequential chunks does not give you threshold recovery either. Every missing chunk leaves the file incomplete, so you gain fragility rather than resilience. Recovering from K of N requires erasure coding, and protecting the key across those shards requires secret sharing. Untrace uses both, for the two different jobs.
The property that does not appear on the table: heterogeneous scatter
Distributing shards across N nodes only helps if those nodes fail independently. Ten nodes in one provider's account, in one region, running one software build, is one target wearing a costume.
Untrace's shards are placed across different trust domains: separate storage providers, separate jurisdictions, separate legal regimes, and separate technology stacks, with an on-chain anchor for the manifest commitment.
The result is that reaching the reconstruction threshold is not a single escalating campaign. An attacker must compromise K independent providers that share no common:
- Operator. No single company can be breached, bribed, or acquired into granting access.
- Jurisdiction. No single court order or national security process compels enough of them.
- Technology stack. No single CVE, dependency, or supply-chain compromise reaches enough of them.
- Credential system. No single leaked key or SSO tenant unlocks enough of them.
Each of those independence axes multiplies attacker cost. Together they turn "breach a company" into "run a coordinated multinational operation against unrelated organizations, simultaneously, without detection, and also obtain the user's signing key."
That is the actual differentiator, and it is a property of placement rather than of cryptography.
Where Untrace is the wrong choice
It is worth being direct about this, because a comparison that concludes "always us" is not a comparison.
- High-throughput hot data. Threshold reconstruction across independent providers costs latency. For a busy application database, use a database.
- Content meant to be public. If anyone should be able to read it, sharding adds cost for no benefit. Use a CDN.
- Casual file sync. For holiday photos and shared documents, mainstream sync tools are cheaper and more convenient, and the threat model does not justify the difference.
- Data with a short sensitivity lifetime. If it stops mattering in a week, encryption alone is a fine bet.
Untrace is built for data with a long sensitivity lifetime and a high consequence of disclosure: identity and KYC documents, compliance archives, legal and medical records, credentials, and the assets whose exposure is not recoverable by rotating a password.
Next
- Why Encryption Is Not Enough for the threat model behind this table.
- Sharding Data Layer for the technical pipeline.
- Frequently Asked Questions for direct answers to specific questions.