pith. sign in

arxiv: 2606.09870 · v1 · pith:ZOHBKGYKnew · submitted 2026-06-02 · 💻 cs.CR · cs.DB· cs.DC· cs.MM· cs.NI· eess.IV

Safecloud: A Distributed, Encrypted Storage Cloud for Streaming

Gregory Magarshak This is my paper

Pith reviewed 2026-06-28 10:02 UTC · model grok-4.3

classification 💻 cs.CR cs.DBcs.DCcs.MMcs.NIeess.IV
keywords encrypted storagekey derivationdistributed cloudstreamingconvergent encryptionproof of storagededuplicationaccess control
0
0 comments X

The pith

A single key-derivation tree supplies range-scoped access, integrity verification, and constant-time segment keys for encrypted streaming.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper describes Safecloud as a network in which files are split into chunks, encrypted locally, and stored across browser tabs and routing servers that never receive plaintext or keys. All keys derive deterministically from one owner root via HKDF, so a grantee given a subtree key computes exactly the same chunk keys as the owner for that range while being unable to reach anything outside it. The same tree structure runs in parallel with Merkle trees for integrity and access trees for authorisation, and it additionally serves as the streaming index so a player computes any segment key in constant time and unlocks video, audio or captions as independent subtrees. Convergent encryption produces identical ciphertexts for identical content, allowing deduplication while a keyless node can still verify integrity. Nodes earn tokens through lightweight one-signature storage proofs that the authors position as cheaper than replication-based alternatives.

Core claim

The central construction is a one-root key hierarchy in which every chunk key derives from a single owner root via HKDF; owner and range-scoped grantee derive identical keys for the same chunks while a subtree key yields its range and nothing else. This key tree operates in parallel with a Merkle tree for integrity and an access tree for authorisation over the same navigation path. The key tree additionally functions as a streaming index permitting O(1) derivation of segment keys and independent subtrees for parallel tracks.

What carries the argument

The one-root key hierarchy using HKDF that doubles as streaming index, access tree and Merkle path over a shared navigation structure.

If this is right

  • Grantees obtain identical chunk keys to the owner from a delegated subtree key.
  • Identical content produces identical ciphertext and identifiers, enabling deduplication without plaintext exposure.
  • A streaming player derives any segment key directly from the root without extra index data.
  • Storage and routing nodes earn rewards through one-signature proof-of-storage challenges.
  • The system maintains confidentiality because nodes hold neither plaintext nor keys.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The per-track subtree design could support selective delivery of multi-language or multi-quality versions without re-encrypting the whole file.
  • Browser-tab storage might allow small-scale or community-run distribution networks to operate without dedicated servers.
  • The convergent-addressing property suggests the scheme could reduce storage costs for popular public-domain or Creative-Commons content.
  • Extending the key tree to support live or append-only streams would require only changes to the derivation schedule rather than new cryptographic primitives.

Load-bearing premise

Browser tabs can store ciphertext in IndexedDB, serve it on demand, and participate in the zero-sum economy without central coordination while preserving confidentiality and integrity.

What would settle it

An observation that a storage node obtains plaintext from stored ciphertext or derives keys outside its authorised subtree would disprove the confidentiality and delegation-containment claims.

read the original abstract

We present Safecloud, a distributed, encrypted, self-pricing storage and streaming network whose storage and routing nodes never see plaintext and never hold keys. Each file is split into chunks, encrypted on the owner's device, and distributed across Drops (browser tabs storing ciphertext in IndexedDB) and Jets (federated routing servers). Only the owner, or an authorised grantee, can decrypt. We make five contributions: (1) A one-root key hierarchy: every key derives deterministically from a single root via HKDF, and owner and range-scoped grantee derive identical chunk keys (derivation agreement); a subtree key derives its range and nothing else (delegation containment). (2) Convergent content addressing: identical content yields identical ciphertext and identifiers, enabling deduplication without plaintext exposure, with identifiers binding authenticated ciphertext so a keyless Drop verifies integrity (blind verifiability). (3) Three parallel trees over one navigation path (Merkle for integrity, key-derivation for confidentiality, access for authorisation), with sound Merkle-verified retrieval. (4) The key tree doubles as a streaming index: a player derives each segment key in O(1), seeking by derivation, while parallel tracks (video, audio, captions) are independent subtrees unlockable per-track and per-segment, a combination we believe no prior encrypted-storage network offers. (5) Jets and Drops earn Safebux verifiably, kept honest by a one-signature proof-of-storage challenge under chilling-effect Proof-of-Corruption, a zero-sum economy that is significantly cheaper than Filecoin's proof-of-replication sealing (which is slow and provides no confidentiality). We give the architecture, cryptographic construction, a threat model, and an open-source reference implementation, stating precisely what is implemented versus designed.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper proposes Safecloud, a distributed encrypted storage and streaming network. Files are chunked and encrypted client-side before distribution to Drops (browser tabs storing ciphertext in IndexedDB) and Jets (federated routing servers). Nodes never see plaintext or hold keys. Five contributions are described: (1) a one-root HKDF key hierarchy enabling derivation agreement and delegation containment; (2) convergent content addressing for deduplication and blind verifiability of integrity; (3) three parallel trees (Merkle for integrity, key-derivation for confidentiality, access for authorization) with sound Merkle-verified retrieval; (4) the key tree serving as a streaming index for O(1) segment key derivation, seeking by derivation, and independent per-track subtrees for video/audio/captions; (5) a Safebux zero-sum economy with one-signature proof-of-storage challenges under chilling-effect Proof-of-Corruption, claimed cheaper than Filecoin. The manuscript provides the architecture, cryptographic construction, threat model, and an open-source reference implementation distinguishing implemented from designed components.

Significance. If the constructions and network assumptions hold, the work would deliver a novel combination of encrypted streaming features (O(1) key derivation for seeking plus per-track independent subtrees) not offered by prior encrypted-storage networks, together with a verifiable economy avoiding proof-of-replication overhead. The open-source reference implementation and explicit implemented-versus-designed statement are strengths that support reproducibility and further evaluation.

major comments (3)
  1. [Contribution (4) and description of Drops] Contribution (4) and Drops description: the claim that the key tree doubles as a streaming index enabling O(1) segment derivation and independent per-track subtrees for range-scoped retrieval presupposes reliable on-demand serving by Drops. The architecture places all ciphertext in IndexedDB inside ephemeral browser tabs that must participate in verifiable challenges and the zero-sum economy without central coordination, yet no mechanism is described to mitigate tab closure, storage eviction, or selective non-participation that would collapse availability.
  2. [Threat model and contribution (5)] Threat model and contribution (5): the one-signature PoS challenge and Proof-of-Corruption are asserted to keep Drops honest, but the manuscript provides no analysis, reduction, or simulation demonstrating resilience when Drops are user-controlled browser tabs subject to closure or malice, rendering the confidentiality and integrity claims under the stated threat model unevaluable.
  3. [Cryptographic construction] Cryptographic construction sections: while the HKDF hierarchy, convergent addressing, and three parallel trees are outlined, the paper supplies no formal security proofs, game-based reductions, or error analysis to substantiate the central claims of derivation agreement, delegation containment, blind verifiability, and sound Merkle-verified retrieval.
minor comments (2)
  1. The abstract states that the manuscript distinguishes implemented from designed components, but the provided text does not include an explicit table or section listing which elements fall into each category; adding this would improve clarity.
  2. Terminology for novel entities (Drops, Jets, Safebux) is introduced inline; a short dedicated definitions paragraph or table would aid readers.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the positive assessment of the work's significance and the detailed major comments. We respond point-by-point below, indicating where the manuscript will be revised.

read point-by-point responses

  1. Referee: [Contribution (4) and description of Drops] Contribution (4) and Drops description: the claim that the key tree doubles as a streaming index enabling O(1) segment derivation and independent per-track subtrees for range-scoped retrieval presupposes reliable on-demand serving by Drops. The architecture places all ciphertext in IndexedDB inside ephemeral browser tabs that must participate in verifiable challenges and the zero-sum economy without central coordination, yet no mechanism is described to mitigate tab closure, storage eviction, or selective non-participation that would collapse availability.

    Authors: We agree that the manuscript does not describe explicit mechanisms to mitigate tab closure, storage eviction, or selective non-participation by Drops. The architecture assumes voluntary participation incentivized by the Safebux economy and relies on redundancy across multiple Drops for availability, but these assumptions are not stated clearly. In revision we will add an explicit discussion of availability assumptions, note the limitations of the browser-tab model, and qualify the streaming claims accordingly. revision: yes

  2. Referee: [Threat model and contribution (5)] Threat model and contribution (5): the one-signature PoS challenge and Proof-of-Corruption are asserted to keep Drops honest, but the manuscript provides no analysis, reduction, or simulation demonstrating resilience when Drops are user-controlled browser tabs subject to closure or malice, rendering the confidentiality and integrity claims under the stated threat model unevaluable.

    Authors: The referee is correct that the manuscript contains no formal analysis, reduction, or simulation of the one-signature PoS and Proof-of-Corruption under browser-tab dynamics. The current text presents the economic model at a descriptive level only. We will expand the threat-model section with additional discussion of the incentive assumptions and limitations, but a full game-theoretic analysis or simulation cannot be added at this stage. revision: partial

  3. Referee: [Cryptographic construction] Cryptographic construction sections: while the HKDF hierarchy, convergent addressing, and three parallel trees are outlined, the paper supplies no formal security proofs, game-based reductions, or error analysis to substantiate the central claims of derivation agreement, delegation containment, blind verifiability, and sound Merkle-verified retrieval.

    Authors: The manuscript presents an applied systems architecture and reference implementation rather than a purely cryptographic paper. Security properties are argued informally from the standard assumptions of the primitives (HKDF determinism, Merkle collision resistance, convergent encryption). No formal game-based proofs are supplied because they fall outside the stated scope. We maintain that the level of detail is appropriate and do not plan to add formal reductions. revision: no

Circularity Check

0 steps flagged

No circularity in derivation chain

full rationale

The manuscript describes an architecture using standard HKDF key derivation, convergent addressing, Merkle trees, and a browser-based storage model, but presents no equations, fitted parameters, or predictions that reduce to their own inputs by construction. No self-citations are invoked as load-bearing uniqueness theorems, and the central claims (key tree as streaming index, per-track subtrees) are stated as design contributions rather than derived results. The derivation chain is therefore self-contained against external benchmarks with no exhibited circular steps.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 3 invented entities

Design rests on standard cryptographic assumptions and introduces new system components (Drops, Jets, Safebux) without independent evidence or falsifiable predictions in the abstract.

axioms (2)
  • standard math HKDF provides secure deterministic key derivation from a root key
    Invoked for the one-root key hierarchy and derivation agreement.
  • standard math Merkle trees enable sound integrity verification of retrieved chunks
    Used for the parallel Merkle tree over the navigation path.
invented entities (3)
  • Drops no independent evidence
    purpose: Browser tabs storing ciphertext in IndexedDB for distributed storage
    New storage node type introduced; no independent evidence provided.
  • Jets no independent evidence
    purpose: Federated routing servers for data distribution
    New routing component; no independent evidence provided.
  • Safebux no independent evidence
    purpose: Verifiable earnings token for storage and routing nodes
    New economic unit; no independent evidence provided.

pith-pipeline@v0.9.1-grok · 5864 in / 1466 out tokens · 29913 ms · 2026-06-28T10:02:03.021989+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

11 extracted references · 2 canonical work pages · 2 internal anchors

  1. [1]

    Intercloud: Eventual Consistency for Decentralised Economies via Chilling-Effect Consensus

    G. Magarshak, “Intercloud: Eventual Consistency for Decentralised Economies via Chilling-Effect Consensus,” arXiv:2605.22830, 2026

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  2. [2]

    Prevention by Construction: Inductive Security for Layered AI Execution Infrastructure,

    G. Magarshak, “Prevention by Construction: Inductive Security for Layered AI Execution Infrastructure,” 2026, manuscript (Safebox)

    2026

  3. [3]

    Safecloud 2.0: A Distributed, Verifiable, Reliable Compute Cloud via Deterministic Re-Execution and Chilling-Effect Claims of Corruption,

    G. Magarshak, “Safecloud 2.0: A Distributed, Verifiable, Reliable Compute Cloud via Deterministic Re-Execution and Chilling-Effect Claims of Corruption,” 2026, manuscript

    2026

  4. [4]

    IPFS - Content Addressed, Versioned, P2P File System

    J. Benet, “IPFS—Content Addressed, Versioned, P2P File System,” arXiv:1407.3561, 2014

    work page internal anchor Pith review Pith/arXiv arXiv 2014

  5. [5]

    Filecoin: A Decentralized Storage Network,

    Protocol Labs, “Filecoin: A Decentralized Storage Network,” white paper, 2017

    2017

  6. [6]

    PoReps: Proofs of Space on Useful Data,

    B. Fisch, “PoReps: Proofs of Space on Useful Data,” and Filecoin Spec, “Sector Sealing (Proof-of-Replication),” Protocol Labs, 2018–2024

    2018

  7. [7]

    Storj: A Decentralized Cloud Storage Network Framework,

    Storj Labs, “Storj: A Decentralized Cloud Storage Network Framework,” white paper, 2018

    2018

  8. [8]

    Reclaiming Space from Duplicate Files in a Serverless Distributed File System,

    J. R. Douceur et al., “Reclaiming Space from Duplicate Files in a Serverless Distributed File System,” inICDCS, 2002

    2002

  9. [9]

    Prolly Trees: Probabilistic B-Trees for Verifiable, History-Independent Data Structures,

    A. Bingham et al., “Prolly Trees: Probabilistic B-Trees for Verifiable, History-Independent Data Structures,” technical report, 2020

    2020

  10. [10]

    Space/Time Trade-offs in Hash Coding with Allowable Errors,

    B. H. Bloom, “Space/Time Trade-offs in Hash Coding with Allowable Errors,”Commun. ACM, vol. 13, no. 7, 1970

    1970

  11. [11]

    The Protection of Information in Computer Systems,

    J. H. Saltzer and M. D. Schroeder, “The Protection of Information in Computer Systems,”Proc. IEEE, vol. 63, no. 9, 1975

    1975