On Sat, 15 Aug 2015 14:52:29 +0300 Dmitry Belyavsky <[email protected]> wrote:
> Hello Arseniy, > > On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov > <[email protected]> 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
