On May 12, 2009, at 18:45, Zooko O'Whielacronx wrote: > Now, there is an easy way to layer some such revocation on top of > Tahoe -- just run a web proxy (e.g. Apache) and give people URLs, > possibly unguessable urls or tiny urls, pointing to that web proxy. > Then you can remove items from your url database to revoke access to > them. Allmydata.com runs a tiny url service front-end on their > production grid, but as far as I know they've never revoked any tiny > urls.
Note, however, that you can't (afaik; I haven't actually dived into the architecture to really know) currently put those URLs into a Tahoe directory, because Tahoe directory items aren't arbitrary URLs. http://allmydata.org/trac/tahoe/ticket/683 -- hint hint. You have just presented another use case. > Another way to implement something similar to this is to use Tahoe's > garbage collection feature to delete the (ciphertext) share data even > while the person holding the cap retains the decryption key. This > could be seen as a kind of expiry. This is not revocation: 1. anyone running a storage server or having previously downloaded shares can hold onto the ciphertext, so deleting shares has no guaranteed effect, and you're only removing data that they could have already downloaded and decrypted anyway. (There is value in this -- "oops, I uploaded this private data, delete it before anyone downloads it" -- but it is not a guarantee, not even the sufficiently-good- guarantee of crypto-with-a-decent-number-of-key-bits.) 2. It does not disable access to a shared resource /which continues to exist and be shared except for the revoked access/, which I proffer as a sketchy definition of revocation. -- Kevin Reid <http://homepage.mac.com/kpreid/> _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
