Open Stack

You answered your own question when you said

"The problem is that crypto is hard, and considering all the 
implications of how algorithms interact is something few can master."

So if you hard code in a single (set of) algoriths, and then a 
vulnerability is found in it (which happens all the time), then you are 
screwed because you have no alternatives to switch to.

Some applications still have MD5 hard coded in, which is why many root 
CAs with MD5 are still configured into most browsers. And that provided 
the attack hole for APTs sending out "microsoft" updates with spoofed 
MD5 certs.

regards

David

On 25/04/2013 15:51, Simo Sorce wrote:
> On Thu, 2013-04-25 at 15:38 +0100, David Chadwick wrote:
>>
>> On 25/04/2013 14:51, Simo Sorce wrote:
>>> On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:
>>>> Simo,
>>>>
>>>> Nice! feedback after a quick browse and compare with xml-dsig
>>>>
>>>> 1. Can we please allow additional algorithms? (see DigestMethod in
>>>> [1]). HMAC-SHA-256 can definitely be the default
>>>
>>> Well as a principle I like keeping security code *simple* and well
>>> defined, at least for an initial implementation. We might add additional
>>> metadata in the future to specify different algorithms, but I would see
>>> that as an additional feature to allow in the future.
>>
>> I think you should differentiate between the code that implements
>> different algorithms, and the mechanism that is used to choose between
>> algorithms.
>
> The problem is that crypto is hard, and considering all the implications
> of how algorithms interact is something few can master.
> so I tend to subscribe to the cabal :) that wants to dictate a very
> strict set and not give much choice to the implementer when it comes to
> how crypto is handled.
>
> So my question really is: why do you want choice in this matter ?
>
>>   The initial implementation should not be hard coded with any
>> specific algorithm, but should have the mechanism for choosing between
>> algorithms built into it from the start,
>
> I object in principle to this :)
>
>>   even if the initial
>> implementation only supports one algorithm. It then becomes relatively
>> straight forward to plug in new algorithms.
>
> Yes, which is not necessarily a good thing. I am not saying we will not
> end up doing this, but I want to hear a good reason for allowing
> non-experts (ie the users or the packagers) choice in this matter.
>
> The more options you add the more avenues of attack you add ...
>
> Simo.
>