On 2004.11.09 at 12:36:56 +0100, Nils Larsch wrote: > > b) A method which should be stored in the method field of DSA or RSA > > structure. There are additional problems concerning the ec_key_st > > structure which doesn't contain the method field and which is the same > > for two algorithm types - ECDSA and ECDH. These problems need further > > investigation. > > the fact that EC_KEY doesn't contain a method pointer is intentional as > the EC_KEY structure is/should be (ec) method indepent. Method depend > information should be stored in the derived objects (i.e ECDSA_DATA and > ECDH_DATA).
Yes. Problem is how to pass an information from the PKCS8/X509 parsing to real implementation of method. If EVP_PKEY structure contains pointer to the method, it is easy. With EC_KEY there are two possibilities yet: 1. We don't need to distinguish between ECDH and ECDSA during key loading. Given the EVP_PKEY structure which contain nid of algoritm in the save_type field, we can find out appropriate ECDSA or ECDH method later. 2. We need to store algorithm specific parameters somewhere. In this case current EVP_PKEY structure is inappropriate for passing information from the PKCS8 to actual method implementation. > ... > >3. To generalize the table of elliptic curves. > > > >In the current version of OpenSSL a set of the supported elliptic curve > >parameters is hardcoded in crypto/ec/ec_curve.c > > > >We propose to use the lhash table to handle elliptic curve parameters. > > I would prefer I linked list instead of lhash Why? lhash tables are already used in OpenSSL to store various tables. Why invent something new instead of reusing existing infrastructure? > > >That would allow engines to add new elliptic curves with their names and > >OIDs similar to the table of asymmetric algorithms described above. This is > >necessary because national cryptographic algorithms typically use their > >own curves. > > what parameter do the GOST signatures curve have ? (I guess there's no > non-russian description of this alg) GOST doesn't specify set of parameters. There are various implementations with different parameters. These parameters are typically choosen by vendors of cryptographic software, and should be approved by appropriate authorities if software is being certified. Several parameter sets are published, others are considered more or less trade secret of vendors. > >5. To associate a particular message digest with a digital signature > >algorithm > > > >Also, some asymmetric algorithms require a particular message digest to > >be used when signing the (self-signed) certificate request. This > >digest type is required by the established standards and should override > >the one specified in the command line. > > don't know if it's good override a command line option but at least it > should be the default digest alg > OpenSSL already does so for DSA algorithm. Our proposal in this place aims for backward compatibility. > > > >For DSA it is dss1, for the GOST signature algorithms it is the GOST > >message > >digest and so on. > > > >This can be handled also by adding one more field for a message digest > >identifier to the EVP_ASYMMETRIC structure. > > this isn't really sufficient, better would something like > STACK_OF(digest id) as, for example, the next x9.62 (ecdsa) > standard will allow to restrict the use of a public key to a > set of digests. I.e. make relation between MDs and signature algorithms bi-directional? MD structure now contains an array of NIDs of appropriate signature algoritms. > > ... > >7. Provide callbacks for packing and unpacking the public keys. > > 8. Provide callbacks for packing and unpacking of a signature objects These callbacks already exist in the message digest structure. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
