W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2012

Re: ECC vs RSA, and Similar Conflicts

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 9 May 2012 15:00:25 -0700
Message-ID: <CACvaWvbaQe-kbV=Zx0ucbLLUgjcFPRPXELRGd3-fdzvgsuU+nQ@mail.gmail.com>
To: Nadim <nadim@nadim.cc>
Cc: Jarred Nicholls <jarred@webkit.org>, public-webcrypto@w3.org
On Wed, May 9, 2012 at 2:55 PM, Nadim <nadim@nadim.cc> wrote:

>  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

UAs should be free to decide and scripts should be able to detect this.

This also serves as a perfect example of why trying to define "good" or
"safe" algorithms is a problematic area. SHA-1 vs SHA-2 is actually a
controversial point - or MD5 vs SHA-1, is actually controversial regarding
the performance and efficiency of the algorithms. This is equally being
reflected in the ongoing SHA-3 competition, where the algorithms appear to
be both stronger than and more robust than SHA-2, but are
also noticeably less efficient. For that reason, it's not unreasonable to
think that SHA-2 will be around up to and until it's declared "broken".

Having the API proscribe the use of SHA-3, as a "good" algorithm, would
thus be a source of understandable controversy. Having an API that can
implement SHA-1, SHA-2, or SHA-3, and allow UAs to decide, would thus be
the 'robust' solution and one I would support.

> 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> 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
Received on Thursday, 10 May 2012 15:48:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:01 UTC