Re: ECC vs RSA, and Similar Conflicts

Here's an interesting question, then: 
Let's assume, for the sake of argument, that SHA2 is widely recognized as being a better alternative to SHA1. However, SHA1 is not only far from broken, but is also as widely used as SHA2, if not more.

What happens in such a scenario? Do we implement only SHA2 (knowing it to be more secure) or do we still include SHA1, even if it's the less secure alternative? 

NK


On Wednesday, 9 May, 2012 at 5:52 PM, Jarred Nicholls wrote:

> On Wed, May 9, 2012 at 1:33 PM, Nadim <nadim@nadim.cc (mailto:nadim@nadim.cc)> wrote:
> > Hi everyone, 
> > I think we need to have a discussion regarding whether the API will exclusively implement (and rely on) newer, faster standards (such as ECDH, ECDSA) or whether there will be a larger dependence on RSA, either for fallback or stronger compatibility reasons.
> > 
> > If it is eventually decided that not only the best available per-task algorithm is implemented, but rather, all possible algorithms, where do we draw the line? Do we implement SHA1 in addition to SHA2? Does that also warrant an MD5 implementation? 
> > 
> > Personally, I believe that focusing only on the newer, more efficient standards (such as ECC) is a better idea, but I stand very humbly by my opinion and a much more interested in listening to the group's opinions. 
> > 
> > Thank you,
> > NK
> > 
> > 
> 
> 
> 
> It might be difficult for the API spec to attempt to enforce certain algorithms as normative, where a vendor must implement support for that algorithm or be declared non-compliant; versus suggesting/recommending particular support.  I'll admit I am naive in this area, but I see this somewhat analogous to HTML5 <video> and codecs that browser vendors choose to support.  This is of course why the API should be as agnostic as possible, which is difficult to do and quite a different situation than HTML5 <video> & codec support. 
> 
> So it is of my opinion that the browser vendor could choose to support the new standards, or RSA, or both.  The API ought to allow for this.
> 
> Cheers,
> Jarred