toby cabot <[email protected]> wrote the lines prepended with ">> ".
On Sat, Jun 4, 2011 at 7:59 AM, Greg Troxel <[email protected]> wrote: > >> Sure, but let's say I realize what I've done before they've copied it. >> From what I've heard, with the traditional FS I can close the barn >> door and know that it's closed. With Tahoe-LAFS I can only ask for >> the barn door to be closed at some point in the future. I think this is mostly a difference of distributed systems vs. centralized systems instead of a difference of caps vs. ACLs or of Tahoe-LAFS vs. ZFS. In a distributed system, it can be really enlightening to think of ciphertext as something that you cannot control the distribution of. This is because in a distributed system--unless you have DRM--the only way to control the distribution of something is to encrypt it and control the distribution of the key, right? So how could you limit who has access to ciphertext? I guess the only other option is just never export the data--whether encrypted or not--off of your own local system, which means it isn't a distributed system. So, in designing Tahoe-LAFS, we embraced this assumption that you cannot control who has copies of ciphertext. We made it so that having the ciphertext gives you very little. You learn the length of the share in bytes (give or take a few). If a user uploads the ciphertext to you or downloads the ciphertext from you then you learn that they have done so. We decided to go ahead and throw in the verification metadata so that you can confirm whether the share has been corrupted or not. Other than that, gaining a copy of the ciphertext by itself doesn't give you any power. Since someone gaining the ciphertext gives them very little power, this increases the range of servers that you can use. It means you can safely use servers even if they are at risk of being taken over by attackers, for example. Now, given these basics (which, again, I think are kind of fundamental to any DRM-free distributed system), then how could one implement revocation of read-access to an immutable file? First of all, how would one implement read-access to an immutable file in the first place? Well, there's basically only one way to do it: the only way to give someone read-access to an immutable file is to give them the decryption key for that file. And revocation of read-access to an immutable file--how could one implement that? Well, we can't un-give the decryption key, so the only remaining option is to try to deny them the ciphertext. We could, for example, contact the storage servers that we earlier uploaded the ciphertext to and ask them to please delete it. This is not a complete stinker of a design. We need, after all, to be able to delete ciphertext in order to free up space. And people strongly feel a desire to be able to do this sort of revocation--we should not disregard their desires. But there are at least two major problems with it: 1. We can't know that the servers will really delete the ciphertext when we ask them to (what if one of them happens to be off-line at that moment?), we can't know if someone else didn't already get a copy of the ciphertext from the server, and we can't know if the person from whom we wish to revoke access didn't already get a copy of the ciphertext from the server. Imagine, for example, that I run a script which instantly downloads and stores a copy of a file as soon as I receive the decryption key for that file. Then you will never be able to shut the barn door before the horse has escaped unless you change your mind and revoke the access faster than my script runs. 2. If the servers *did* all successfully delete the ciphertext when we ask them to, then this would deny read-access to everyone, not just to one person. If we wanted to be able to revoke one person's read-access without revoking everyone's, then we would have to do some more complicated and/or inefficient process. For example, we could upload one copy of the ciphertext, encrypted under a different key, for each different user. These sorts of problems are probably not insurmountable, but they do seem to be significant issues, and after all even if we could overcome them then the "revoke read-access to this immutable file" command would still be unreliable (it would depend on whether our request to delete the ciphertext managed to reach all the computers which had a copy of the ciphertext, and whether every computer honored it, before the target user or some other computer loyal to him got a copy). Also, this would in a sense increase your vulnerability to the servers! If you think you might want to use the "revoke read-access to an immutable file" feature in the future, then you can no longer be quite so free about which servers you employ to store your ciphertext. Maybe you can't afford to use servers which are at risk of being taken over by attackers, because if those servers *have* been taken over, they might pretend to honor your revocation while secretly selling the ciphertext to the target user. So adding this feature would detract from Tahoe-LAFS's current virtue of imposing very little constraint on which servers you choose to use with it. > That's true for immutable files. For a directory, you can unlink the > contents and push out a new version. But I don't think there's been any > analysis of how effective this is. Ah, so revoking access to *mutable* things is a complete different ballgame. :-) Yes, there has been some analysis of it, but I don't have time to write any more on the subject tonight. :-) See #954. Regards, Zooko http://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revoke write authority _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
