ECC code now in GnuPG master
squalyl at gmail.com
Fri Feb 4 11:45:18 CET 2011
the proliferation of curves is a barrier to interoperability,
specially with smart cards.
apart from that ECC is a very nice PK scheme.
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
> 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!
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
More information about the Gnupg-devel