Your browser tab could become encrypted storage for someone else's files - Help Net Security

Help Net Security newsletters : Daily and weekly news, cybersecurity jobs, open source projects, breaking news – subscribe here!

Please turn on your JavaScript for this page to function normally.

Mirko Zorz, Director of Content, Help Net Security

June 19, 2026

Share

Your browser tab could become encrypted storage for someone else’s files

Decentralized storage networks already hand pieces of people’s data to strangers’ machines. The lasting question across these networks is whether the machine holding the data can read it. A research paper by Gregory Magarshak, a professor at IENYC, describes a system called Safecloud built on one design rule: the nodes that store data see only ciphertext, and the nodes that route data hold no keys.

How the system 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 spread across two kinds of node. Drops run inside ordinary browser tabs and keep encrypted chunks in IndexedDB, the storage built into web browsers. Jets are routing servers that match chunks to Drops and serve retrieval requests. The owner, called the Cloud, holds the root secret and is the party that decrypts content.

Every key in the system derives from one 32-byte root secret through a standard derivation function. Identical content under the same root yields identical ciphertext, which lets the network keep one copy of repeated data. This deduplication holds within a single owner’s root, so two owners encrypting the same file produce different addresses. The address used to locate each chunk is computed over the encrypted bytes, so a storage node can confirm it holds the correct chunk with no key and no view of the contents.

Three trees over one path

Safecloud keeps three structures that share one addressing scheme. A public Merkle tree covers chunk integrity, a key-derivation tree covers confidentiality, and an access tree covers authorization. A single path locates a chunk’s integrity proof, its decryption key, and its access grant at once. A consumer retrieving a chunk checks the returned bytes against a public root, and any swapped or corrupted chunk gets detected.

Streaming that comes from the key structure

The same key hierarchy doubles as a way to stream media. A player holding the key for a track derives the key for the next segment in one step from a key it already holds, so seeking to any point in a video costs one derivation and one fetch. A file’s video, audio, and caption tracks sit in separate branches, and each can be unlocked on its own. 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 limit stays with the design: once a range key reaches a grantee, revoking that access requires rotating the keys for that range, since the grantee keeps what it has derived.

The economic layer

Drops earn a token called Safebux for holding and serving chunks, and Jets earn it for routing. Payment settles through a signed claim that authorizes up to a rising maximum on a numbered line, so a provider can prove what it is owed and a payer cannot replay an old authorization. Storage honesty rests on a challenge in which a Jet asks a Drop to sign a fresh content address and nonce. A Drop that no longer holds the chunk fails, and repeated failure leads to a slashed stake and re-replication of the chunk.

Magarshak argues this design costs less than the sealing used by Filecoin, where a provider proves storage through a slow encoding that runs on the order of tens of minutes per sector and proves physical replication apart from confidentiality. He states its challenge does not prove the same property as that sealing, and presents the signature-plus-stake method as enough to keep an honest provider honest at lower cost.

What runs and what remains

Magarshak separates the parts that run from the parts in progress. Encryption, chunking, content addressing, the Merkle integrity tree, and the delegation construction are working. The payment and proof-of-storage layer is specified and partly wired. The paper states that the payment verification hooks currently return true and that the proof-of-storage challenge response is a placeholder.

Magarshak gave more detail on where that layer stands. In Safecloud, he said, "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 published." Proof-of-storage challenges use committed content addresses, the SHA-256 of the ciphertext, that a storage node cannot fabricate without holding the chunk. He identified the...