On Thursday,2009-08-27, at 19:14 , James A. Donald wrote: > Zooko Wilcox-O'Hearn wrote: >> Right, and if we add algorithm agility then this attack is >> possible even if both SHA-2 and SHA-3 are perfectly secure! >> Consider this variation of the scenario: Alice generates a >> filecap and gives it to Bob. Bob uses it to fetch a file, reads >> the file and sends the filecap to Carol along with a note saying >> that he approves this file. Carol uses the filecap to fetch the >> file. The Bob-and- Carol team loses if she gets a different file >> than the one he got. ... > So the leading bits of the capability have to be an algorithm > identifier. If Bob's tool does not recognize the algorithm, it > fails, and he has to upgrade to a tool that recognizes more > algorithms. > > If the protocol allows multiple hash types, then the hash has to > start with a number that identifies the algorithm. Yet we want > that number to comprise of very, very few bits.
Jim, I'm not sure you understood the specific problem I meant -- I'm concerned (for starters) with the problems that arise if we support more than one secure hash algorithm *even* when none of the supported secure hash algorithms ever becomes crackable! So much so that I currently intend to avoid having a notion of algorithm agility inside the current Tahoe-LAFS code base, and instead plan for an algorithm upgrade to require a code base upgrade and a separate, syntactically distinct, type of file capability. > This is almost precisely the example problem I discuss in <http:// > jim.com/security/prefix_free_number_encoding.html> Hey, that's interesting. I'll study your prefix-free encoding format some time. Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
