[tahoe-dev] So how do *you* manage your keys, then? Re: cleversafe says: 3 Reasons Why Encryption isOverrated

[Zooko Wilcox-O'Hearn]

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