On Monday,2009-08-10, at 11:56 , Jason Resch wrote:
You have stated how Cleversafe manages the key but not provided any details regarding how Tahoe-LAFS manages the decryption key?
I think this is potentially Tahoe-LAFS's best contribution to the state of the art, so I hope many of the readers of these lists will think carefully about the following.
The design of Tahoe-LAFS is to separate key management (== access control) from data storage, and to make key management simple and flexible.
First, we boil down the key management problem for a given file or directory to a single key, which is short (less than 100 bytes) so that it is easier to manage. This key suffices for both decryption and integrity-checking.
Second, we make a separate, independent key for every single file or directory. This means that access control decisions such as "Should I share this file with my friend?" don't have to be linked to access control of other files or directories. (Although they *can* be bundled together if desired.)
Third, we *embed the key directly into the identifier of the file*. This part is important. You know how in a filesystem, whether local or distributed, files have a unique "file handle" or identifier? In a traditional Unix filesystem it is the inode number. Like a Unix directory, a Tahoe-LAFS directory consists of a map from the name of each child to the file handle to that child. The critical decision here is to embed the crypto key directly into that handle. The result is that when some human or some program wants to give anothe human or program access to a Tahoe-LAFS file or directory, it does so by giving the file handle. This single value serves for access control (you can't decrypt the file if you don't have it), identification (the unique identifer of the file is its file handle), and actual usage -- the file handle is sufficient to locate and acquire the file contents.
The resulting short string which serves as identifier, access control token, and file handle is called a "capability" or a "cap" for short. There are several kinds of capability in Tahoe-LAFS. The one that I've described above is a "read-cap to an immutable file".
Okay, my bus has arrived at work so I don't have time right now to describe the other ones, but please observe that this design so far already makes you start thinking about how you could build something cool on top of it. You can do so without having to think too much about how the ciphertext is stored (it is erasure-coded and spread across a distributed, fault-tolerant key-value storage grid), and without having to know too much about how other programs or other humans on the same system are managing their caps.
We owe thanks to many others including the authors of Self-certifying filesystem, Freenet, Mojo Nation and especially the obj-cap ideas as expressed by Mark Miller.
Regards, Zooko --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
