ECC code now in GnuPG master

[Sébastien Lorquet]

the proliferation of curves is a barrier to interoperability,
specially with smart cards.
</rant>
apart from that ECC is a very nice PK scheme.

Sebastien

On Fri, Feb 4, 2011 at 9:55 AM, Sergi Blanch i Torné <sergi at calcurco.cat> wrote:
> On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch <wk at gnupg.org> wrote:
>> On Thu,  3 Feb 2011 19:27, calestyo at scientia.net said:
>>> What's the suggested keysizes,... and which are supported by gpg?
>>
>> The default is 256, which uses the NIST P-256 curve.  Other supported
>> curves are NIST P-384 and NIST P-521.  We could also add other curves as
>> long as an OID is available and a user interface is written.  However, I
>> believe that proliferation of curves is a bad idea.  In contrast to RSA
>> key sizes, the application needs to know the curve parameters as they
>> are not part of the key.
>
> IMHO, the proliferation of curves is a feature of the ecc. The
> X9.62-1998 (section 5.1) evaluates as a security risk the multiple
> users sharing of the same elliptic curve domain parameters. An
> probably they has not thinking that this can be three curves for all
> the users.
>
> With ecc you have the feature to change the cyclic subgroup (change
> 'a', 'b') without increase the size of the base field. Over prime
> finite fields the unique option you have is to increase the size of
> 'p'.
>
> I understand the bigger issue that this proliferation can make. But,
> step by step, some day this is a feature that will be need.
> Cryptography programming must be like satellite navigation
> programming, the cost of a mistake is huge!
>
> /Sergi.
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>