[tahoe-dev] the only Cloud storage system which is privacy-compatible -- a diagram
Zooko O'Whielacronx
zookog at gmail.com
Thu May 28 15:14:08 PDT 2009
This is a pretty good nit-pick, Toby. ;-) But I think I can nit-pick
your nit-pick:
We distinguish between integrity -- accidents or unauthorized people
can't change the contents of your files -- and reliability --
accidents or unauthorized people can't delete your files. We also
distinguish both of those from availability -- accidents or
unauthorized people can't make your files unreachable to you even for
a limited time. Therefore it is fair to say that someone who owns all
of the storage servers can't violate your file integrity even though
he can erase your file (or make it unavailable to you).
Also there is the vexing subtlely of roll-back attack. Unauthorized
people, even if they control all of the storage servers *can't* forge
new file contents and trick you into thinking that their choice of
contents is the correct new contents of the file, so we can say that
you don't rely on the storage servers at all for "integrity", but they
*could* trick you into thinking that an older version of the file is
the current version, just by rewinding their storage server state to
an earlier state. For simplicity, I like to exclude roll-back from
the definition of "integrity" -- you have integrity if unauthorized
people can't trick you into accepting arbitrary new file contents.
By the way, we already have fairly strong protection against roll-back
attack in the form of a quorum system -- if some of the storage
servers that you do talk to tell you about the newer version of the
file then you can believe them because you can check the digital
signature on the newer version number. That means that an attacker
who wants to do a roll-back attack has to make sure you don't ask good
servers in addition to making sure that you ask bad servers. There's
another fairly cheap defense which it would be nice to add: you can
remember the most recent version of that file that you've seen in the
past, so that nobody can ever trick you into believing in a version of
the file older than the most recent version you've seen. It would be
great if someone would implement that (it's a curious question as to
where you store that information -- one intriguing possibility is in
the metadata of the parent directory!). Is there a ticket for this
issue?
Oh by the way, I recently made the text of about.html a little less
precise, as you correctly pointed out, in the interests of brevity:
http://allmydata.org/trac/tahoe/changeset?new=3888%40docs%2Fabout.html&old=3842%40docs%2Fabout.html
Thanks for the feedback! I appreciate precision.
Regards,
Zooko
More information about the tahoe-dev
mailing list