[tahoe-dev] a crypto puzzle about digital signatures and future compatibility
zooko at zooko.com
Mon Aug 31 16:57:48 UTC 2009
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
> 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://
Hey, that's interesting. I'll study your prefix-free encoding format
More information about the tahoe-dev