Tor vs Tahoe-LAFS for Anonymous Storage

Tahoe-LAFS splits files into shares and distributes them across storage nodes using erasure coding. A (k, n) threshold means k of n shares are needed to reconstruct the file. Even if (n-k) storage nodes are seized, the file is unrecoverable. Each share is encrypted before distribution - storage node operators see only encrypted chunks, never plaintext file content. The encryption key is part of the file capability (URI), not stored anywhere server-side. Only someone with the URI can decrypt and reconstruct the file. Tahoe-LAFS over Tor: connect the Tahoe client and storage nodes via Tor (configuring Tahoe to use SOCKS5 proxy or running storage nodes as .onion services). This hides the network location of storage nodes and clients. The combination provides: encrypted storage (even compromised nodes cannot read file content) and network anonymity (IP addresses hidden via Tor).

Simple .onion file hosting: run nginx or Apache as a .onion hidden service, serve files from the server's filesystem. The server holds cleartext files (or encrypted files if you manually encrypt before storing). A single server failure or seizure loses all data. Tahoe-LAFS over Tor: files are encrypted with strong keys derived from file capabilities, distributed across multiple nodes (potentially in different jurisdictions), and recoverable with only k-of-n shares. No single node holds the decryption key or the complete file. The trade-off: Tahoe-LAFS is significantly more complex to set up and operate. Simple .onion hosting is appropriate for content that is encrypted at rest (GPG-encrypted files served as downloads) or content where single-server availability is acceptable. Tahoe-LAFS is appropriate for long-term resilient storage where no single party should have access to the plaintext.

Tahoe-LAFS installation: pip install tahoe-lafs. Initialize a storage grid: tahoe create-introducer ~/tahoe-introducer and tahoe create-node ~/tahoe-storage for each storage node. Configure each storage node's tahoe.cfg to connect to the Tor network: set [connections] tcp = tor in the config file, and configure the introducer's .onion address as the introducer FURL. Storage nodes that are hidden services each get their own .onion address configured in Tor. The Tahoe client (tahoe create-client) connects to the introducer via its .onion address, discovers available storage nodes, and uses them for file storage. This setup is non-trivial but creates a grid where: all communication goes through Tor, storage nodes do not know each other's real IPs, and the client's IP is not known to storage operators.

Use simple .onion file hosting for: serving static content (documents, archives) from a well-maintained server, anonymous downloads where server continuity is maintained, and file sharing with a known audience via .onion links. Use Tahoe-LAFS over Tor for: long-term archival storage that must survive individual node failures or seizures, distributed team storage where no single team member should have administrative access to all content, key evidence storage for journalists or activists where single-point compromise would be catastrophic, and research data that must be preserved even if the primary researcher's server is compromised. The Tahoe-LAFS approach is analogous to a highly secure off-site backup that no single party can access without the decryption keys in the file capabilities.

Tahoe-LAFS over Tor adds the latency of Tor (100-400ms per hop) to the inherent distributed storage overhead (multiple network requests for shares from multiple nodes). File reads require k separate network requests to k different storage nodes via Tor circuits. File writes require n separate network requests to n nodes. For small files: this overhead is tolerable (seconds per operation). For large files (100+ MB): performance is limited by Tor circuit bandwidth (2-5 Mbps typical) and the serial/parallel network requests to storage nodes. Practical setup: use 3-of-5 erasure coding (3 shares needed from 5 total). Storage capacity is roughly (k/n) of total distributed storage: 3-of-5 means 60% of distributed storage is usable (5 shares, each k/n=60% of file size). Each storage node on a Romania VPS Mini at $19.99/mo or similar provides the storage capacity.