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
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
