[openssl-dev] [PATCH] GOST engine and custom paramsets

[Arseniy Ankudinov]

15.08.2015 19:29, Victor Wagner:
> On Sat, 15 Aug 2015 14:52:29 +0300
> Dmitry Belyavsky <beldmit at gmail.com> wrote:
> 
>> Hello Arseniy,
>>
>> On Fri, Aug 7, 2015 at 9:37 AM, Arseniy Ankudinov
>> <a.ankudinov at 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 28147&3411/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