Tahoe-LAFS

Summary

Tahoe-LAFS is a distributed storage system built around provider-independent security. A client encrypts files, encodes the ciphertext into shares and distributes them across a grid of storage servers. Servers need not be trusted with plaintext or with the ability to substitute valid file contents. They are still trusted to supply enough shares when you need them.

How it works

Erasure coding. A file is encoded into N shares and can be reconstructed from any k valid shares. This tolerates missing shares without storing a complete copy on every server. It does not mean that any k arbitrary servers will suffice: placement determines which shares each server holds. Shared power, administration or hosting can also make supposedly separate servers fail together.

Capabilities. A capability is a bearer credential, not an account name. Sharing it delegates the authority it contains.

Keep capabilities out of public messages and logs. Passing someone a read cap cannot make them forget a copy they already downloaded. Mutable files support updates; immutable files require a new capability when their bytes change.

Discovery. Introducers distribute storage-server announcements. Clients can combine announcements from several introducers, or use static server definitions without an introducer. Introducers help clients find the grid; they do not replace the capabilities that authorize access to data.

Operating a grid

Run the client or gateway on a machine you trust. Encryption and integrity checking happen there; using somebody else's gateway moves that trust to their machine.

Choose storage operators with independent failure risks. Configure the encoding parameters and review actual share placement. Tahoe-LAFS provides checking, verification and repair mechanisms, but operating the grid means arranging when they run and replacing missing redundancy before too many shares disappear. Keep an independent copy of essential capabilities and recovery instructions.

Trust model / threat model

The design separates confidentiality and integrity from availability. Storage servers can withhold or destroy shares, but should not be able to read the file or forge content accepted under its capability. Losing enough distinct shares defeats recovery regardless of how strong the encryption is.

Tahoe-LAFS does not promise anonymity. Its architecture documentation describes exposure of file sizes and opportunities to correlate uploads and downloads. Compromising the client or stealing a capability also bypasses the intended storage-server boundary.

Readiness

Usable for people prepared to run or join a storage grid and manage capabilities. The project supplies client, server and administration software. Availability remains an operational responsibility, not a guarantee supplied by the name of the protocol.

Limits

Erasure coding adds storage and repair work. A grid concentrated under one operator has correlated failure risk. A lost read capability can be as serious as a lost decryption key. Compare these obligations with ordinary Syncthing replication and the alternatives in Choosing Decentralized Storage.

Primary sources

• Tahoe-LAFS canonical repository.
• Provider-independent security and gateway trust.
• Architecture: capabilities, encoding, verification and reliability.
• Node configuration: encoding parameters, introducers and static servers.