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.
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.
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.
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.
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.
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 open piece as 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,” he said.
The paper sets the adversary wide. It may run any number of Drops, may run Jets, may watch 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 terms a storage node learns nothing from the ciphertext, a node cannot return altered bytes without detection, and a node that claims storage it lacks fails the challenge. The remaining exposure is availability when a large share of Drops withhold or drop data, the standard limit of replicated storage.
Safecloud composes with a separate system called Safebox. Magarshak said the two stand apart. “Safecloud is completely independent of Safebox. The encryption, storage, routing, and payment layers can be audited and run without Safebox involved at all,” he told Help Net Security. 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 described 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 carries 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, applied to the code running on the server.
Apply now: Simplify security management with CIS SecureSuite Platform
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。