Hack Tahoe!

Welcome to the "Hack Tahoe!" contest.

News

May 7, 2009 -- Christian Grothoff has been properly honored on the Hall of Fame -- see below!

February 13, 2009 -- Tahoe v1.3.0 has been released. There are no security fixes in this release, because nobody has found any major issues since the crypto flaw that Christian Grothoff discovered in Tahoe v1.1. Come on guys, you can do better than that! (See this thread on tahoe-dev for a promising start...)

August 22, 2008 -- a paper about Tahoe, the Least-Authority Filesystem has been accepted into the Storage Security and Survivability Workshop.

July 21, 2008 -- Tahoe v1.2.0 has been released, fixing the flaw that Christian Grothoff discovered. Please see The Release Notes for details.

July 20, 2008 -- Christian Grothoff has discovered a flaw in the cryptographic integrity check for immutable files. See his note to tahoe-dev. It is not too severe, but we're definitely going to fix it. More details will be forthcoming.

July 18, 2008 -- The "Hack Tahoe!" contest is announced. Read the announcement.

The Hall of Fame

The security flaws that have been discovered in earlier versions of Tahoe may generalize to other systems -- if you are a security hacker you may be interested in the specific attacks and defenses because they may be applicable to your work. See the "details" links below.

number	winner	picture	details
0	Christian Grothoff		more than one file can match an immutable file cap
-1	Drew Perttula		convergent encryption reconsidered
-2	Nathan Wilcox		CSRF attacks

How to Get Started

• Everything about what Tahoe is, how it works, how to compile it, and so on is at http://allmydata.org.
• Discussion is on the tahoe-dev mailing list.
• Here is a web interface to a live Tahoe grid hosted on http://hacktahoe.org -- http://hacktahoe.org:8123. (Using that you can experiment with Tahoe without first installing the software on your own system.)
• To connect your own local Tahoe node to the hacktahoe grid, put the following string in your introducer.furl file: pb://xhn3ev45nglq4iusaxvzqcwx3imk7noy@introducer.hacktahoe.org:49419/introducer.

Examples

• Here are all of the shares produced by uploading a secret file. If you were running a storage server you would see one of those shares. If you were running all of the storage servers then you could see all of the shares. However, even having all of those shares should not allow you to learn anything about the file that we uploaded other than its length in bytes, and when it was uploaded. If you can discern any other information about that file, then you will have violated Tahoe's confidentiality guarantee.
• Here is the read-cap to a directory on the hacktahoe grid. We're not publishing the write-cap, which means that while you can see the current contents of the directory you can't change the contents of the directory (although those who know the write-cap can). If you can find a way to change the contents of this directory without being given the write-cap to the directory, then you will have violated our intended properties of data integrity and access control. [*]
• This is a read-write cap to a different directory. Since the read-write cap is published on this page, anyone who can read this page can change the contents of this directory. There's no particular security challenge associated with this page, but it can be a convenient way to experiment with the system.

[*] Note that there is a kind of failure of directories which we're already aware of -- rollback to an earlier version of the directory state. It would be difficult for an attacker to make this failure happen. If 6 out of the 10 storage servers were malicious and in cahoots, or if 3 of them were malicious and conspiring, and 5 of the remaining good ones were unreachable (for example, due to a Denial of Service attack against those other 7), or if enough of the servers were to crash and accidentally revert to an earlier state of their local filesystem, then the directory would revert to an earlier state.

Sponsored By

Sponsored by http://allmydata.com, providers of secure backup services.

Thanks to Kevin Reid for suggestions to improve the layout of this page.