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.



The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to