Re: ECC vs RSA, and Similar Conflicts

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
>
>
>