[tahoe-dev] So how do *you* manage your keys, then? Re: cleversafe says: 3 Reasons Why Encryption isOverrated
zooko at zooko.com
Mon Aug 17 16:11:35 UTC 2009
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
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
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.
More information about the tahoe-dev