Re: ECC vs RSA, and Similar Conflicts

On Wed, May 9, 2012 at 10:33 AM, 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.
>

Exclusively implementing a single algorithm, particularly one with IP
ambiguity, makes it difficult to ensure that cryptographic agility is both
built in and functional. I strongly believe that at least two algorithms
must be implemented, and would be happy to see those two be ECC and RSA.


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

I believe a strong argument can be made for the exclusion of weak and
broken algorithms (eg: DES, MD5).

However, I believe overall that it is somewhat contingent both upon the Use
Cases and the level of detail the API attempts to expose. If implementing
at the medium to lower layer (per my previous message), then in order to
support protocols which themselves have legacy issues (eg: PGP, S/MIME),
UAs may wish to expose broken/weak algorithms to permit interoperability.

That said, I would gladly sacrifice interoperability for security, and
believe this is reasonable given this is a "new" API. I would prefer not to
implement weak/broken algorithms, and would like for the flexibility of UAs
to be able to phase out algorithms if/as/when cryptographic issues are
discovered.


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