[PATCH 3/3] Add support for GOST R 34.10-2001/-2012 signatures
NIIBE Yutaka
gniibe at fsij.org
Thu Oct 3 15:11:14 CEST 2013
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.
--
More information about the Gcrypt-devel
mailing list