Decentralized storage networks have long grappled with a fundamental question: when a stranger's machine holds pieces of your data, can it read them? A research paper by Gregory Magarshak, a professor at IENYC, proposes a system called Safecloud that answers with a strict architectural divide. In Safecloud, storage nodes see only ciphertext, and routing nodes hold no keys. This design aims to provide confidentiality without relying on trusted hardware or complex encryption schemes.
How Safecloud splits and hides files
Safecloud breaks each file into fixed-size chunks and encrypts every chunk on the owner’s device before it leaves. The encrypted pieces are then distributed across two types of nodes. Drops run inside ordinary browser tabs and store encrypted chunks in IndexedDB, the storage built into web browsers. Jets act as routing servers that match chunks to Drops and handle retrieval requests. The owner, called the Cloud, holds the root secret and is the only party that can decrypt content.
Every key in the system derives from a single 32-byte root secret through a standard derivation function. Identical content under the same root yields identical ciphertext, allowing the network to keep only one copy of repeated data—a form of deduplication. However, this deduplication only applies within the scope of a single owner’s root. Two owners encrypting the same file will produce different addresses. The address used to locate each chunk is computed from the encrypted bytes, so a storage node can confirm it holds the correct chunk without needing any key and without any view of the contents.
Three trees over one path
Safecloud maintains three separate structures that share a common addressing scheme. A public Merkle tree ensures chunk integrity, a key-derivation tree guarantees confidentiality, and an access tree handles authorization. A single path can simultaneously locate a chunk’s integrity proof, its decryption key, and its access grant. When a consumer retrieves a chunk, it can verify the returned bytes against a public root. Any swapped or corrupted chunk is immediately detected.
Streaming from the key structure
One of Safecloud’s novel features is how its key hierarchy doubles as a streaming mechanism. A media player holding the key for a track can derive the key for the next segment with just one step from a key it already holds. Seeking to any point in a video costs one key derivation and one fetch. Video, audio, and caption tracks sit in separate branches, each unlockable independently. An owner can grant access to a range of segments—such as a preview or a rented chapter—by handing over a single key for that range.
Magarshak presents this combination of random-access decryptable streaming and per-segment access control as new among encrypted storage networks. One limitation persists: once a range key is given to a grantee, revoking that access requires rotating the keys for that range, because the grantee retains any keys it has already derived.
The economic layer
Drops earn a token called Safebux for storing and serving chunks, while Jets earn it for routing. Payments are settled through a signed claim that authorizes up to a rising maximum on a numbered line. This design allows a provider to prove what it is owed and prevents a payer from replaying an old authorization. Storage honesty is enforced through a challenge mechanism: a Jet asks a Drop to sign a fresh content address and nonce. A Drop that no longer holds the chunk fails the challenge. Repeated failure leads to a slashed stake and re-replication of the chunk.
Magarshak argues that this design is less costly than the sealing used by Filecoin, where providers prove storage through a slow encoding process that takes tens of minutes per sector and proves physical replication separately from confidentiality. He acknowledges that Safecloud’s challenge does not prove the same property as Filecoin’s sealing, but contends that the signature-plus-stake method is sufficient to keep honest providers honest at lower cost.
What runs and what remains
Magarshak separates the operational parts from those still in development. Encryption, chunking, content addressing, the Merkle integrity tree, and the delegation construction are all functional. The payment and proof-of-storage layer is specified and partly wired. The paper notes that payment verification hooks currently return true and the proof-of-storage challenge response is a placeholder.
Magarshak provided additional detail on where that layer stands. In Safecloud, the settlement contract is publicly verifiable, and every payment requires a valid cryptographic signature over a typed struct, enforced on-chain using the OpenClaiming Protocol. Proof-of-storage challenges use committed content addresses—the SHA-256 hash of the ciphertext—that a storage node cannot fabricate without holding the chunk. The open piece is the relay path, where a routing server covers gas for a storage node and needs session-key signing wired in. The direct path, where a node submits its own claims, already works.
The threat model
The paper sets a broad adversary. It may control any number of Drops, may run Jets, may monitor all network traffic, and may collude across nodes. It cannot break the encryption or signature schemes, and it does not control the owner’s device, which holds keys and plaintext. Under these assumptions, a storage node learns nothing from the ciphertext, cannot return altered bytes without detection, and fails the challenge if it claims storage it lacks. The remaining exposure is availability: if a large share of Drops withhold or drop data, the system becomes unavailable—a standard limitation of replicated storage.
The Safebox connection
Safecloud composes with a separate system called Safebox. Magarshak emphasized that the two are independent. Safecloud’s encryption, storage, routing, and payment layers can be audited and run without Safebox involved at all. The client-side code is readable in any browser’s developer tools, and the contract source is verified on block explorers linked from the project page.
He describes Safebox as an optional attestation layer that grew out of a decade running the Groups app on iOS, which used a Safari Web Extension to host private keys locally. Safebox extends that idea to the open web by attesting that a website or iframe runs a trusted front end that has not been tampered with. He compared it to the HTTPS padlock, but applied to the code running on the server.
Decentralized storage systems like Safecloud are part of a broader trend toward user-controlled data. By leveraging existing browser storage capacity, they offer a low-barrier entry for participants. However, the reliance on browser tabs raises questions about persistence—tabs can be closed, and IndexedDB can be cleared. Safecloud’s economic incentives aim to encourage long-term hosting, but the practical challenges remain significant. As such projects mature, they will need to balance security guarantees with usability to attract a critical mass of users.
Source: Help Net Security News