[tahoe-dev] "Elk Point" design for mutable, add-only, and immutable files
David-Sarah Hopwood
david-sarah at jacaranda.org
Sat Oct 10 20:25:33 PDT 2009
Zooko Wilcox-O'Hearn wrote:
> I've started a matrix of ways that an immutable file cap format could
> break: http://allmydata.org/trac/tahoe/wiki/NewCaps/WhatCouldGoWrong
>
> Unfortunately I can't conveniently replicate the data into an email
> message (except by sending HTML-formatted email, which I assume most
> of you would hate and which I don't even know how to do).
>
> So go read this page! http://allmydata.org/trac/tahoe/wiki/NewCaps/
> WhatCouldGoWrong
OK, I've added everything I can think of right now.
Note the question in footnote 5:
# 5. Brute force costs assume a single-target attack that is expected to
# succeed with high probability. Costs will be lower for attacking
# multiple targets or for a lower success probability.
# (Should we give explicit formulae for this?)
> Also pay attention to the "what crypto property do we rely on"
> column. I wouldn't be surprised if SHA-256's collision-resistance is
> increasingly called into question in future years. (On the other
> hand I would be rather shocked if SHA-256's second-pre-image
> resistance were called into question in the forseeable future.)
I agree. Only attack #1 depends on collision resistance.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the tahoe-dev
mailing list