[PATCH 3/3] Add support for GOST R 34.10-2001/-2012 signatures

[NIIBE Yutaka]

Hello,

Let me explain my thought.  When I see the portion of your code:

--- a/cipher/ecc-curves.c
+++ b/cipher/ecc-curves.c
@@ -263,6 +263,34 @@ static const ecc_domain_parms_t domain_parms[] =
       "0x7dde385d566332ecc0eabfa9cf7822fdf209f70024a57b1aa000c55b881f8111"
       "b2dcde494a5f485e5bca4bd88a2763aed1ca2b2fa8f0540678cd1e0f3ad80892"
     },
+    {
+      "GOST2001-test", 256, 0,
+      MPI_EC_WEIERSTRASS, ECC_DIALECT_STANDARD,
+      "0x8000000000000000000000000000000000000000000000000000000000000431", /* p */
+      "0x0000000000000000000000000000000000000000000000000000000000000007", /* a */
+      "0x5fbff498aa938ce739b8e022fbafef40563f6e6a3472fc2a514c0ce9dae23b7e", /* b */
+      "0x8000000000000000000000000000000150fe8a1892976154c59cfc193accf5b3", /* q */
+
+      "0x0000000000000000000000000000000000000000000000000000000000000002", /* x */
+      "0x08e2a8a0e65147d4bd6316030e16d19c85c97f0a9ca267122b96abbcea7e8fc8", /* y */
+    },

I felt, it's not correct to uses ECC_DIALECT_STANDARD.  Then, I
thought that if it uses ECC_DIALECT_GOST_R34_10, it will be
correct.

That is, the interpretation of p, a, b, g (q for GOST R34.10), x, y
(of generator) is determined by the combination of curve model and
dialect.

On 2013-10-03 at 13:43 +0400, Dmitry Eremin-Solenikov wrote:
> Hmm. Interesting suggestion. Maybe I failed to understand the purpose
> of the domain field. From my understanding it is used only for key generation,
> isn't it? Does it have any other usecases?

ecc_domain_parms_t is only used internally in ecc-curves.c, but it is
the basis of the type elliptic_curve_t (defined in ecc-common.h),
which also has model and dialect.

> I thought about gost r 34.10 signatures as if they are 'just another format' of
> ecdsa signatures. Thus I added a (flag gost) to data/signature generation.
> IIUC, there is no any significant difference between ECDSA and GOST
> curves/keys.

I understand your approach of adding routines for GOST R 34.10.  I
have no objection for that.  I agree about similarity between 
computation of ECDSA signature and one of GOST signature.

My point is that the semantics of a curve definition can be different.

    Common:
        p, a, b defines a curve.

    ECC_DIALECT_STANDARD:
        g is order of the group.
        G is the generator, where gG = O 

    ECC_DIALECT_GOST_R34_10:
        q is order of the subgroup.
        P is the generator of the subgroup, where qP = O

If q = g and P = G for a GOST curve, there is nothing to distinguish
ECC_DIALECT_STANDARD and ECC_DIALECT_GOST_R34_10.

If q < g and P /= G for a GOST curve, we need to distinguish dialects.

If we have optional fields and let GOST curve has g and G too, we can
compute ECDSA signature with GOST curve.

Usually, with curve for ECDSA, the order g is prime, so, meaningful
subgroup is the group itself.  We can compute GOST signature with this
ECDSA curve with q = g, P = G.
--