[added Cc: tahoe-...@allmydata.org, and I added ke...@guarana.org on the whitelist so his posts will go through to tahoe-dev even if he isn't subscribed]

On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote:

Possession of the read-cap to the mutable file gives you two things: it gives you the symmetric encryption key with which you decrypt the file contents, and it gives you the public key with which you check a digital signature in order to be sure that the file contents were written by an authorized writer.

How do you prevent someone possessing the read-cap for a mutable file from rolling the file back to an earlier version that they have seen, without the consent of the write-cap possessor(s)?

You don't even need a read-cap to perform a roll-back attack -- if you can control the ciphertext that the reader gets, then you can give them a copy of an older ciphertext, even if you yourself are incapable of decrypting it. This is a difficult attack to defend against. In the current version of Tahoe-LAFS we already have one interesting defense -- we the reader is communicating with many different servers, and if *any* of the servers is honest and up-to- date and informs the reader about the existence of a newer version, then the reader knows that the older version that he can read is not the latest. Readers in Tahoe-LAFS always download shares of the file from multiple servers, and all of the servers that it uses would have to agree on the version number. Therefore, to perform a rollback attack you need to control at least that many servers as well as you have to control or deny-access-to any other servers which the reader would query and which would inform him about the newer version number. See section 5 of [1].

Does that answer your question about rollback?

It would be interesting to build stronger defenses against rollback attack. For starters, if the same reader reads the same file multiple times and gets new contents each time, he might as well remember the version number so that he will detect whether that file rolled back during his inspection of it. Also, it would be interesting if a file handle to a mutable file included the version number that the mutable file was at when the file handle was created. Building on that, it would be really cool if, in a future version of Tahoe-LAFS, we could make it so that you can take a cheap snapshot of the current contents and then give someone a file-handle which *both* securely identified "the most recent version that you can find of this file" and *also* "the specific (immutable) version of this file that existed when I created this file-handle".

Also, am I correct in assuming that once write-caps have been distributed, they cannot be revoked, and a new file handle must be created?

Currently, yes. An improvement that I would like to make in the next version of Tahoe-LAFS is to allow the holder of a write-cap to revoke it. While some kinds of revocation are tantamount to DRM ("Digital Restrictions Management") and seem to be sufficiently difficult that we're not even going to try to implement them, the specific kind of revocation that you asked about seems to be quite doable. Also, it happens to be the kind of revocation that I have already wanted for my own personal use of Tahoe-LAFS (to host my blog). :-)

Here is a letter about that which explains why I needed this and how I envision it working: [2]

Stronger defenses against rollback attack, and revocation of write- caps -- these are only a few of the many possible extensions to the Tahoe-LAFS secure storage design. We have a rich library of such designs documented on our issue tracker and our wiki. We are currently having a detailed design discussion on the tahoe-dev list to which several cryptographers are contributing [e.g. 3, 4]. The primary goal for the next version of Tahoe-LAFS caps is to reduce the size of the caps and improve performance, but we're also cataloguing new features such as these to see if we can work them in. Here is the wiki page where we're keeping our notes: [5].

If any smart cryptographer or hacker reading this wants to create secure, decentralized storage, please join us! We could use the help! :-)



[1] http://allmydata.org/~zooko/lafs.pdf
[2] http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html
[3] http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html
[4] http://allmydata.org/pipermail/tahoe-dev/2009-September/002808.html
[5] http://allmydata.org/trac/tahoe/wiki/NewCapDesign

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to