4 Welcome to Tahoe-LAFS!

7 What is Tahoe-LAFS?

10 Welcome to Tahoe-LAFS_, the first decentralized storage system with

13 Tahoe-LAFS is a system that helps you to store files. You run a client

14 program on your computer, which talks to one or more storage servers on other

15 computers. When you tell your client to store a file, it will encrypt that

16 file, encode it into multiple pieces, then spread those pieces out among

17 multiple servers. The pieces are all encrypted and protected against

18 modifications. Later, when you ask your client to retrieve the file, it will

19 find the necessary pieces, make sure they haven't been corrupted, reassemble

20 them, and decrypt the result.

22 The client creates more pieces (or "shares") than it will eventually need, so

23 even if some of the servers fail, you can still get your data back. Corrupt

24 shares are detected and ignored, so the system can tolerate server-side

25 hard-drive errors. All files are encrypted (with a unique key) before

26 uploading, so even a malicious server operator cannot read your data. The

27 only thing you ask of the servers is that they can (usually) provide the

28 shares when you ask for them: you aren't relying upon them for

29 confidentiality, integrity, or absolute availability.

33 What is "provider-independent security"?

36 Every seller of cloud storage services will tell you that their service is

37 "secure". But what they mean by that is something fundamentally different

38 from what we mean. What they mean by "secure" is that after you've given

39 them the power to read and modify your data, they try really hard not to let

40 this power be abused. This turns out to be difficult! Bugs,

41 misconfigurations, or operator error can accidentally expose your data to

42 another customer or to the public, or can corrupt your data. Criminals

43 routinely gain illicit access to corporate servers. Even more insidious is

44 the fact that the employees themselves sometimes violate customer privacy out

45 of carelessness, avarice, or mere curiosity. The most conscientious of

46 these service providers spend considerable effort and expense trying to

47 mitigate these risks.

49 What we mean by "security" is something different. *The service provider

50 never has the ability to read or modify your data in the first place: never.*

51 If you use Tahoe-LAFS, then all of the threats described above are non-issues

52 to you. Not only is it easy and inexpensive for the service provider to

53 maintain the security of your data, but in fact they couldn't violate its

54 security if they tried. This is what we call *provider-independent

57 This guarantee is integrated naturally into the Tahoe-LAFS storage system and

58 doesn't require you to perform a manual pre-encryption step or cumbersome key

59 management. (After all, having to do cumbersome manual operations when

60 storing or accessing your data would nullify one of the primary benefits of

61 using cloud storage in the first place: convenience.)

63 Here's how it works:

65 .. image :: network-and-reliance-topology.svg

67 A "storage grid" is made up of a number of storage servers. A storage server

68 has direct attached storage (typically one or more hard disks). A "gateway"

69 communicates with storage nodes, and uses them to provide access to the

70 grid over protocols such as HTTP(S), SFTP or FTP.

72 Note that you can find "client" used to refer to gateway nodes (which act as

73 a client to storage servers), and also to processes or programs connecting to

74 a gateway node and performing operations on the grid -- for example, a CLI

75 command, Web browser, SFTP client, or FTP client.

77 Users do not rely on storage servers to provide *confidentiality* nor

78 *integrity* for their data -- instead all of the data is encrypted and

79 integrity-checked by the gateway, so that the servers can neither read nor

80 modify the contents of the files.

82 Users do rely on storage servers for *availability* . The ciphertext is

83 erasure-coded into ``N`` shares distributed across at least ``H`` distinct

84 storage servers (the default value for ``N`` is 10 and for ``H`` is 7) so

85 that it can be recovered from any ``K`` of these servers (the default

86 value of ``K`` is 3). Therefore only the failure of ``H-K+1`` (with the

87 defaults, 5) servers can make the data unavailable.

89 In the typical deployment mode each user runs her own gateway on her own

90 machine. This way she relies on her own machine for the confidentiality and

91 integrity of the data.

93 An alternate deployment mode is that the gateway runs on a remote machine and

94 the user connects to it over HTTPS or SFTP. This means that the operator of

95 the gateway can view and modify the user's data (the user *relies on* the

96 gateway for confidentiality and integrity), but the advantage is that the

97 user can access the Tahoe-LAFS grid with a client that doesn't have the

98 gateway software installed, such as an Internet kiosk or cell phone.

100 Access Control

103 There are two kinds of files: immutable and mutable. When you upload a file

104 to the storage grid you can choose which kind of file it will be in the

105 grid. Immutable files can't be modified once they have been uploaded. A

106 mutable file can be modified by someone with read-write access to it. A user

107 can have read-write access to a mutable file or read-only access to it, or no

108 access to it at all.

110 A user who has read-write access to a mutable file or directory can give

111 another user read-write access to that file or directory, or they can give

112 read-only access to that file or directory. A user who has read-only access

113 to a file or directory can give another user read-only access to it.

115 When linking a file or directory into a parent directory, you can use a

116 read-write link or a read-only link. If you use a read-write link, then

117 anyone who has read-write access to the parent directory can gain read-write

118 access to the child, and anyone who has read-only access to the parent

119 directory can gain read-only access to the child. If you use a read-only

120 link, then anyone who has either read-write or read-only access to the parent

121 directory can gain read-only access to the child.

123 For more technical detail, please see the `the doc page`_ on the Wiki.

125 .. _the doc page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc

127 Get Started

130 To use Tahoe-LAFS, please see :doc: `INSTALL` .

132 License

135 Tahoe-LAFS is an open-source project; please see the `top-level README`_ for

139 this is really ../README.rst, but it's not included in the Sphinx build so