GOST ECC pubkey

Werner Koch wk at gnupg.org
Fri Sep 20 11:00:15 CEST 2013

On Thu, 19 Sep 2013 20:40, dbaryshkov at gmail.com said:

> I'm currently looking into implementing GOST R 34.10 digital signatures.
> Basically they are Weierstrass elliptic curves. Two main differences from ECDSA:
> 1) Different equations to calculate r and s.

Which makes them different from ECDSA.  You may have noticed that I am
working on Ed25519 and for that I changed quite some stuff to support
different ECC models.

> 2) Different set of curves defined in standards/RFCs.

All curves should go into ecc-curves.c.

> What would you recommend me as the user interface for this pubkey?
> Would just a flag (like it is done for EdDSA) be enough? Should I

I am currently wondering how this can be done best.  One of the problems
I am facing is that we use those GCRY_PK_ECDSA et al identifiers.  They
have their origin in OpenPGP but I am not sure whether they make lot of
sense these days.  With the old algorithm like RSA we only had one
parameter (key size) to fully describe the algorithm. Implementations of
RSA usually supported all key sizes up to a an upper limit.  With ECC
this is not anymore the case.  An implementation may for example support
only a certain curve and describing each curve using an algorithm
identifier would end up in the same big mess as the combined TLS
algorithms ids.

The idea for the "eddsa" flag stems from the use of flags to describe
the RSA encodings ("pkcs1", "pss", etc.)  it does not go nicely with
ecdsa and ecdh algorithm descriptions.  An option would be to always use
the tag "ecc" for the key proper and "ecdsa", "ecdh", "eddsa" for the
signature and encryption schemes.  "gostsig" or whatever would be easy
to add.

Given that 1.6 is an API break, we could also decide to remove
GCRY_PK_ECDSA and GCRY_PK_ECDH and replace them by a genericGCRY_PK_ECC.
The different ECC schemes would then be identified by flags like we do
it for RSA encodings.

I am currently working on moving the s-expression parsing from pubkey.c
into the modules implementing the algorithms.  This saves a lot of
overhead and would be a prerequisite to maybe drop the algorithm ids for
public key algorithms in their entire.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gcrypt-devel mailing list