ECC and smartcards

[Andrey Jivsov]

The main issue arising from this is interoperability.

IMO any other curve as a standard curve for digital signastures will 
split already thin ecosystem of ECC to the degree that it's 
insignificant. Users will continue to use RSA/DSA keys as a result.

Note that the situation regarding encryption is more forgiving. It's 
only with signatures when we need the widest interoperability base, 
because when I create a message or a key, I don't typically know who my 
verifies are.

SuiteB curves are basically Neil Koblitz, a no-NSA-friend, curves with 
parameters a,b following standard rules, but which method of choice is 
unpublished.

People would want to see curves generated as some sort of hash output, 
but if the hash is SHA, some of them will remain unconvinced.

The bet against SuiteB weakness is that:
1) NSA knows about a (fundamental?) flaw in ECC
2) NSA is convinced that nobody will discover it, so that the US 
government data protection at TOP SECRET level is not at risk
3) the alternatives (i.e. Edwards curves) don't have this flaw and don't 
have other flaws related to special structure of the new curves
4) SHA2 algorithm is secure

This thread is started about ECDSA, so +
5) you are worrying about NSA forging OpenPGP signatures (as opposed to 
breaking encryption)

Also, many people are thinking that entire ECC is flawed, so +
6) RSA, DSA is stronger.

My approach at this point is wait and see. In the calm 8 years between 
SuiteB announcement until NSA revelations ECC got some traction, but far 
from universal adoption. It's hard to see Edwards curves (or any other 
ECC curve) having much success (unless you have a closed system and 
don't care about anybody else, or an online protocol).

On 10/01/2013 05:27 AM, Werner Koch wrote:
> On Thu, 26 Sep 2013 07:27, gniibe at fsij.org said:
>
>> Since then, I did some part of ECDSA in GnuPG 2.1.x.  I tested it with
>> Gnuk development version for authentication.
>
> I have more and more doubts that using ECDSA by default in GnuPG is the
> Right Thing.  Although I don't think that the NIST curves have been
> selected for possible future algorithm break or a chance for broken
> implementations, we can't be sure about it and many people will probably
> not trust them for non-technical reasons.  Thus a released 2.1.0 will
> likely use Bernstein et al.'s curves by default.
>
> Given that it is unlikely that we will find an implementation of
> Curve25519 in a proprietary smartcard any time soon, I am bit lost on
> what do do with ECC and smartcards.  Given that Gnuk would actually
> benefit from a fast software implementable curve, it might be a good
> idea to take the first step and do just that.  Ed22519 is now
> implemented in Libgcrypt and a next step could be to squeeze it into the
> RFC-6637 format (using non-compressed points) and make it the default
> ECC signing algorithm.
>
>
> Shalom-Salam,
>
>     Werner
>