[tahoe-dev] "Elk Point" design for mutable, add-only, and immutable files

David-Sarah Hopwood david-sarah at jacaranda.org
Sun Oct 11 03:25:33 UTC 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