ECC code now in GnuPG master

[Sergi Blanch i Torné]

I understand this, but I feel it as a barrier to surpass. The
mathematical methods to operate ec points in libgcrypt, has been
programmed in the generic way that the P1363 says. They should work
with other curves, and they had not problem with the brainpool curves.

Not tomorrow, neither the day after, but I think is good to have on
mind the possibility to work on the direction to have this elliptic
curve feature available. Specially for the smart cards, due to an
attack to an specific elliptic curve can be aborted changing the curve
without affect the design of the card for one length to a bigger one.

Also, against side channel attack, it's proposed to use isogenies to
avoid zero-value points. And this means that the implementation must
work fine with more curves than a few selected.

/Sergi.

On Fri, Feb 4, 2011 at 11:45 AM, Sébastien Lorquet <squalyl at gmail.com> wrote:
> 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
>>
>