[tahoe-dev] a crypto puzzle about digital signatures and future compatibility

[Zooko Wilcox-O'Hearn]

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