From this perspective, Tahoe-LAFS can be seen as "like git, and use

Okay, in today's installment I'll reply to my friend Kris Nuttycombe, who read yesterday's installment and then asked how the storage service provider could provide access to the files without being able to see their filehandles and thus decrypt them. I replied that the handle could be stored in another file on the server, and therefore encrypted so that the server couldn't see it. You could imagine taking a bunch of these handles -- capabilities to read an immutable file -- and putting them into a new file and uploading to the Tahoe-LAFS grid. Uploading it would encrypt it and give you a capability to that new file. The storage service provider wouldn't be able to read the contents of that file, so it wouldn't be able to read the files that it references. This forms a "Cryptographic Hash Function Directed Acyclic Graph" structure, which should be familiar to many readers as the underlying structure in git [*]. Git uses this same technique of combining identification and integrity-checking into one handle. the handle for encryption in addition to integrity-checking and identification". (There are many other differences. For starters git has a high- performance compression scheme and it has a decentralized revision control tool built on top. Tahoe-LAFS has erasure-coding and a distributed key-value store for a backend.) Okay, the bus is arriving at work. Oh, so then Kris asked "But what about the root of that tree?". The answer is that the capability to the root of that tree is not stored on the servers. It is held by the client, and never transmitted to the storage servers. It turns out that storage servers don't need the capability to the file in order to serve up the ciphertext. (Technically, they *do* need an identifier, and ideally they would also have the integrity-checking part so that they could perform integrity checks on the file contents (in addition to clients performing that integrity check for themselves). So the capability gets split into its component parts during the download protocol, when the client sends the identification and integrity-checking bits to the server but not the decryption key, and receives the ciphertext in reply.) Therefore the next layer up, whether another program or a human user, needs to manage this single capability to the root of a tree. Here the abstraction-piercing problem of availability versus confidentiality remains in force, and different programs and different human users have different ways to manage their caps. I personally keep mine in my bookmarks in my web browser. This is risky -- they could be stolen by malicious Javascript (probably) or I might accidentally leak them in an HTTP Referer header. But it is very convenient. For the files in question I value that convenience more than an extra degree of safety. I know of other people who keep their Tahoe-LAFS caps more securely, on Unix filesystems, on encrypted USB keys, etc.. Regards, Zooko [*] Linus Torvalds got the idea of a Cryptographic Hash Function Directed Acyclic Graph structure from an earlier distributed revision control tool named Monotone. He didn't go out of his way to give credit to Monotone, and many people mistakenly think that he invented the idea. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE