Welcome to the "Hack Tahoe-LAFS!" contest.
Januarty
July 20, 2008 through October 2, 2012 — four years of new releases of Tahoe-LAFS have come out and nobody has reported a serious security flaw in any of them. (Well, actually we have found a couple of serious security flaws that we had accidentally put in, but we didn't design t-shirts for ourselves to celebrate.) Surely the fourth ever "Hack Tahoe-LAFS!" prize is waiting to be awarded to a deserving investigator. Hurry and win it before someone else does! See the catalog of open tickets for some possible avenues of attack…
August 22, 2008 — a paper about Tahoe-LAFS, the Least-Authority Filesystem has been accepted into the Storage Security and Survivability Workshop.
July 21, 2008 — Tahoe-LAFS 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, 2014 — The "Hack Tahoe-LAFS!" contest is announced. Read the announcement.
The security flaws that have been discovered in earlier versions of Tahoe-LAFS 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 . Note: the back of the t-shirt contains an alternate version of the same nominally-hashed message, illustrating the bug. |
| -1 | Drew Perttula | | convergent encryption reconsidered |
| -2 | Nathan Wilcox | | CSRF attacks |
[*] 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.
Thanks to Kevin Reid for suggestions to improve the layout of this page.