Re: [openssl-dev] [PATCH] GOST engine and custom paramsets
15.08.2015 19:29, Victor Wagner: On Sat, 15 Aug 2015 14:52:29 +0300 Dmitry Belyavsky beld...@gmail.com wrote: Hello Arseniy, On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov a.ankudi...@drweb.com wrote: We strictly need use our custom paramsets for GOST algorithms (all of cipher, hash and signature, including X509 and TLS). If most of the functionality may be implemented by dirty overriding initialization methods, X509 requires ccgost engine sources patching. Seems 2 ways: 1. Put our paramsets into ccgost sources and simple support for several paramsets in ASN1 hash params serializing. 2. Allow set any paramset from outside. First way seems the simplest, but second - more universal and useful. The 2nd way is not universal until the GOST algorithms become the 1st-class citizens. And becoming the 1st-class citizens is hardly possible. So the patch you suggest is engine-specific, and it means that it will be unsuitable for any other implementation. I think it would be nice to provide ability to set parameters from the parameter file same way as dsa and ec keys do. I don't like the idea of running separate command to create parameter file which contain just curve OID, it is why currently GOST engine accept paramset name as key generation parameter. But accepting either paramset name or parameter file with actual curve parameters seems to be feasible. S-Blocks for algorithms, derived from GOST 28147-89 also can be handled this way. For MAC it would look like openssl dgst -mac gost-mac -macopt paramfile:filename -macopt key:... Digest and encryption algorithms now do not have support for calling control function with arbitrary command from the command line utility, but control functions present in EVP_MD and EVP_CIPHER structures. ASN.1 structures for parameters are defined in the RFC 4357. So presence of such feature in the reference implementation may influence authors of other implementations. There are various legacy software packages which use non RFC 4357 parameters for all algorithms, So support for explicitely specifying parameters would greatly help people who need to interoperate with them, Hmm, your suggestion looks interesting. Yet seen an unsolved problem. Pkey, X509 and key exchange asn1 structures for GOST algorithms store paramsets as OIDs, without parameters embedding. So peers must know mapping from OID to parameters, but I don't see good way to set these mappings through high-level APIs. Or set it for s_client tool (non-authenticated), for example. Maybe make it through config? Add sections for 281473411/3410-94/3410-2001 paramsets, like this: [new_oids] id-Gost28147-89-My-Paramset = 1.3.6.1.4.1.29690.2.2.1 id-GostR3410-2001-My-Paramset = 1.3.6.1.4.1.29690.2.2.2 [gost_section] paramsets_28147 = my_gost_sblocks paramsets_3410_2001 = my_gost_curves ... [my_gost_sblocks] # similar to X509v3 extensions conf id-Gost28147-89-My-Paramset = ASN1:UTF8String:... [my_gost_curves] id-GostR3410-2001-My-Paramset = ASN1:UTF8String:... Our current implementation for second way (see attached patch) requires ccgost engine directly using, not only through high-level APIs. Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94, with one paramset for cipher and hash): 1. Add custom paramsets to chains: gost2001_paramset_append( gost2001_custom_paramset ); gost_cipher_list_append( gost89_custom_paramset ); 2. Make private key for certificate: EC_KEY *ec( EC_KEY_new() ); BN_CTX *ctx( BN_CTX_new() ); BN_CTX_start( ctx ); EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p, gost2001_custom_paramset-a, gost2001_custom_paramset-b, ctx ) ); EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet ); EC_POINT *P( EC_POINT_new( grp ) ); EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x, gost2001_custom_paramset-y, ctx ); EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 ); EC_KEY_set_group( ec, grp ); BN_CTX_end( ctx ); EVP_PKEY *pkey( EVP_PKEY_new() ); EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec ); GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey ); ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet; ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet; Can this feature be useful for the community? And which way seems be more useful? -- With best regards, Arseniy Ankudinov Software Engineer, Doctor Web Ltd ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- With best regards, Arseniy Ankudinov Software Engineer, Doctor Web Ltd ___ openssl-dev mailing list To unsubscribe:
Re: [openssl-dev] [PATCH] GOST engine and custom paramsets
Hello Arseniy, On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov a.ankudi...@drweb.com wrote: We strictly need use our custom paramsets for GOST algorithms (all of cipher, hash and signature, including X509 and TLS). If most of the functionality may be implemented by dirty overriding initialization methods, X509 requires ccgost engine sources patching. Seems 2 ways: 1. Put our paramsets into ccgost sources and simple support for several paramsets in ASN1 hash params serializing. 2. Allow set any paramset from outside. First way seems the simplest, but second - more universal and useful. The 2nd way is not universal until the GOST algorithms become the 1st-class citizens. And becoming the 1st-class citizens is hardly possible. So the patch you suggest is engine-specific, and it means that it will be unsuitable for any other implementation. Our current implementation for second way (see attached patch) requires ccgost engine directly using, not only through high-level APIs. Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94, with one paramset for cipher and hash): 1. Add custom paramsets to chains: gost2001_paramset_append( gost2001_custom_paramset ); gost_cipher_list_append( gost89_custom_paramset ); 2. Make private key for certificate: EC_KEY *ec( EC_KEY_new() ); BN_CTX *ctx( BN_CTX_new() ); BN_CTX_start( ctx ); EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p, gost2001_custom_paramset-a, gost2001_custom_paramset-b, ctx ) ); EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet ); EC_POINT *P( EC_POINT_new( grp ) ); EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x, gost2001_custom_paramset-y, ctx ); EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 ); EC_KEY_set_group( ec, grp ); BN_CTX_end( ctx ); EVP_PKEY *pkey( EVP_PKEY_new() ); EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec ); GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey ); ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet; ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet; Can this feature be useful for the community? And which way seems be more useful? -- With best regards, Arseniy Ankudinov Software Engineer, Doctor Web Ltd ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- SY, Dmitry Belyavsky ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] GOST engine and custom paramsets
On Sat, 15 Aug 2015 14:52:29 +0300 Dmitry Belyavsky beld...@gmail.com wrote: Hello Arseniy, On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov a.ankudi...@drweb.com wrote: We strictly need use our custom paramsets for GOST algorithms (all of cipher, hash and signature, including X509 and TLS). If most of the functionality may be implemented by dirty overriding initialization methods, X509 requires ccgost engine sources patching. Seems 2 ways: 1. Put our paramsets into ccgost sources and simple support for several paramsets in ASN1 hash params serializing. 2. Allow set any paramset from outside. First way seems the simplest, but second - more universal and useful. The 2nd way is not universal until the GOST algorithms become the 1st-class citizens. And becoming the 1st-class citizens is hardly possible. So the patch you suggest is engine-specific, and it means that it will be unsuitable for any other implementation. I think it would be nice to provide ability to set parameters from the parameter file same way as dsa and ec keys do. I don't like the idea of running separate command to create parameter file which contain just curve OID, it is why currently GOST engine accept paramset name as key generation parameter. But accepting either paramset name or parameter file with actual curve parameters seems to be feasible. S-Blocks for algorithms, derived from GOST 28147-89 also can be handled this way. For MAC it would look like openssl dgst -mac gost-mac -macopt paramfile:filename -macopt key:... Digest and encryption algorithms now do not have support for calling control function with arbitrary command from the command line utility, but control functions present in EVP_MD and EVP_CIPHER structures. ASN.1 structures for parameters are defined in the RFC 4357. So presence of such feature in the reference implementation may influence authors of other implementations. There are various legacy software packages which use non RFC 4357 parameters for all algorithms, So support for explicitely specifying parameters would greatly help people who need to interoperate with them, Our current implementation for second way (see attached patch) requires ccgost engine directly using, not only through high-level APIs. Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94, with one paramset for cipher and hash): 1. Add custom paramsets to chains: gost2001_paramset_append( gost2001_custom_paramset ); gost_cipher_list_append( gost89_custom_paramset ); 2. Make private key for certificate: EC_KEY *ec( EC_KEY_new() ); BN_CTX *ctx( BN_CTX_new() ); BN_CTX_start( ctx ); EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p, gost2001_custom_paramset-a, gost2001_custom_paramset-b, ctx ) ); EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet ); EC_POINT *P( EC_POINT_new( grp ) ); EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x, gost2001_custom_paramset-y, ctx ); EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 ); EC_KEY_set_group( ec, grp ); BN_CTX_end( ctx ); EVP_PKEY *pkey( EVP_PKEY_new() ); EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec ); GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey ); ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet; ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet; Can this feature be useful for the community? And which way seems be more useful? -- With best regards, Arseniy Ankudinov Software Engineer, Doctor Web Ltd ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [PATCH] GOST engine and custom paramsets
We strictly need use our custom paramsets for GOST algorithms (all of cipher,
hash and signature,
including X509 and TLS). If most of the functionality may be implemented by
dirty overriding
initialization methods, X509 requires ccgost engine sources patching.
Seems 2 ways:
1. Put our paramsets into ccgost sources and simple support for several
paramsets in ASN1 hash
params serializing.
2. Allow set any paramset from outside.
First way seems the simplest, but second - more universal and useful.
Our current implementation for second way (see attached patch) requires ccgost
engine directly
using, not only through high-level APIs.
Example of usage for X509 (GOST 28147-89, GOST R 34.10-2001 and GOST R
34.11-94, with one paramset
for cipher and hash):
1. Add custom paramsets to chains:
gost2001_paramset_append( gost2001_custom_paramset );
gost_cipher_list_append( gost89_custom_paramset );
2. Make private key for certificate:
EC_KEY *ec( EC_KEY_new() );
BN_CTX *ctx( BN_CTX_new() );
BN_CTX_start( ctx );
EC_GROUP *grp( EC_GROUP_new_curve_GFp( gost2001_custom_paramset-p,
gost2001_custom_paramset-a,
gost2001_custom_paramset-b, ctx ) );
EC_GROUP_set_curve_name( grp, NID_id_GostR3410_2001_DrWebParamSet );
EC_POINT *P( EC_POINT_new( grp ) );
EC_POINT_set_affine_coordinates_GFp( grp, P, gost2001_custom_paramset-x,
gost2001_custom_paramset-y, ctx );
EC_GROUP_set_generator( grp, P, gost2001_custom_paramset-q, 0 );
EC_KEY_set_group( ec, grp );
BN_CTX_end( ctx );
EVP_PKEY *pkey( EVP_PKEY_new() );
EVP_PKEY_assign( pkey, NID_id_GostR3410_2001, ec );
GOST3410_EX_DATA *ex_data = GOST3410_get_ex_data( pkey );
ex_data-hash_params_nid = NID_id_Gost28147_89_DrWebParamSet;
ex_data-cipher_params_nid = NID_id_Gost28147_89_DrWebParamSet;
Can this feature be useful for the community? And which way seems be more
useful?
--
With best regards, Arseniy Ankudinov
Software Engineer, Doctor Web Ltd
You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: text/x-patch;
name=tls_gost_custom_paramsets.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=tls_gost_custom_paramsets.patch
diff -Naur --no-dereference openssl-1.0.2d/crypto/crypto.h openssl-1.0.2d.new/crypto/crypto.h
--- openssl-1.0.2d/crypto/crypto.h 2015-07-09 11:53:21.0 +
+++ openssl-1.0.2d.new/crypto/crypto.h 2015-08-07 06:09:44.0 +
@@ -332,6 +332,7 @@
# define CRYPTO_EX_INDEX_ECDH13
# define CRYPTO_EX_INDEX_COMP14
# define CRYPTO_EX_INDEX_STORE 15
+# define CRYPTO_EX_INDEX_GOST341016
/*
* Dynamically assigned indexes start from this value (don't use directly,
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/Makefile openssl-1.0.2d.new/engines/ccgost/Makefile
--- openssl-1.0.2d/engines/ccgost/Makefile 2015-07-09 12:03:07.0 +
+++ openssl-1.0.2d.new/engines/ccgost/Makefile 2015-08-07 06:09:44.0 +
@@ -8,9 +8,9 @@
CFLAGS= $(INCLUDES) $(CFLAG)
LIB=$(TOP)/libcrypto.a
-LIBSRC= gost2001.c gost2001_keyx.c gost89.c gost94_keyx.c gost_ameth.c gost_asn1.c gost_crypt.c gost_ctl.c gost_eng.c gosthash.c gost_keywrap.c gost_md.c gost_params.c gost_pmeth.c gost_sign.c
+LIBSRC= gost2001.c gost2001_keyx.c gost89.c gost94_keyx.c gost_ameth.c gost_asn1.c gost_crypt.c gost_ctl.c gost_eng.c gosthash.c gost_keywrap.c gost_lib.c gost_md.c gost_params.c gost_pmeth.c gost_sign.c
-LIBOBJ= e_gost_err.o gost2001_keyx.o gost2001.o gost89.o gost94_keyx.o gost_ameth.o gost_asn1.o gost_crypt.o gost_ctl.o gost_eng.o gosthash.o gost_keywrap.o gost_md.o gost_params.o gost_pmeth.o gost_sign.o
+LIBOBJ= e_gost_err.o gost2001_keyx.o gost2001.o gost89.o gost94_keyx.o gost_ameth.o gost_asn1.o gost_crypt.o gost_ctl.o gost_eng.o gosthash.o gost_keywrap.o gost_lib.o gost_md.o gost_params.o gost_pmeth.o gost_sign.o
SRC=$(LIBSRC)
@@ -274,3 +274,4 @@
gost_sign.o: e_gost_err.h gost89.h gost_lcl.h gost_params.h gost_sign.c
gost_sign.o: gosthash.h
gosthash.o: gost89.h gosthash.c gosthash.h
+gost_lib.o: e_gost_err.h gost89.h gost_lcl.h gost_lib.c gosthash.h
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/e_gost_err.c openssl-1.0.2d.new/engines/ccgost/e_gost_err.c
--- openssl-1.0.2d/engines/ccgost/e_gost_err.c 2015-07-09 11:53:21.0 +
+++ openssl-1.0.2d.new/engines/ccgost/e_gost_err.c 2015-08-07 06:09:44.0 +
@@ -115,6 +115,8 @@
{ERR_FUNC(GOST_F_PUB_ENCODE_GOST01), PUB_ENCODE_GOST01},
{ERR_FUNC(GOST_F_UNPACK_CC_SIGNATURE), UNPACK_CC_SIGNATURE},
{ERR_FUNC(GOST_F_UNPACK_CP_SIGNATURE), UNPACK_CP_SIGNATURE},
+{ERR_FUNC(GOST_F_ECGOST_DATA_NEW_METHOD), ECGOST_DATA_NEW_METHOD},
+{ERR_FUNC(GOST_F_GOST3410_EX_DATA_NEW_METHOD), GOST3410_EX_DATA_NEW_METHOD},
{0, NULL}
};
diff -Naur --no-dereference openssl-1.0.2d/engines/ccgost/e_gost_err.h openssl-1.0.2d.new/engines/ccgost/e_gost_err.h
---
