Dear Max, You can take a look at https://github.com/gost-engine/engine as an example of providing new algorithms via engine.
On Fri, Aug 24, 2018 at 10:45 AM Dr. Pala <direc...@openca.org> wrote: > Hi all, > > I am working on providing a new Public Key method that will handle > Composite Keys (i.e., multiple keys with different algos - e.g., one RSA > and one EC) and Composite Signatures (i.e., multiple signatures generated > with the corresponding Composite Keys). In particular, I would like to be > able to add a method that will, in turn, call the methods supported by the > different keys that form the COMPOSITE_PKEY structure. > > I have looked around how to do it and I am a bit confused about how to > proceed as there are some conflicting implementations for different > algorithms. > > Here's some high-level questions related to the EVP_PKEY interface, in > particular: > > - *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two > different types of methods are used? Shall both be implemented? > > The 1st one is for processing ASN1 structures and the 2nd is for crypto-operations. > > - > - *After providing the implementation for the ameth/pmeth, how does > the integration work with openssl?* In particular, should I add them > to the list of the default ameth/pmeth supported? Here's some more specific > questions: > > - It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD - > how do I add the method there (in case I will use a user-level - i.e., > not > integrated into OpenSSL code - approach by using the functions in the > crypto/asn1/ameth_lib.c file). Will the EVP_PKEY_asn1_add0() function > call > be sufficient? > > - It seems there is an standard_methods stack of > EVP_PKEY_ASN1_METHOD - how do I add the method there if we need to have > a > more tight integration with the core of the library (in case we can not > do > our proof-of-concept without touching the openssl's code / requiring a > fork) > > See register_ameth/register_pmeth in GOST engine. > - > - *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed > that, for example, both RSA and EC implement some form of _CTX and _PKEY > structures. Are these used only internally or should they be implemented > and integrated with the METHOD(s) ? > > I suspect you need your own representation of key owning RSA and EC keys and manage themselves. > > - > - *Given the above is implemented correctly - will this enable the use > of the method for processing signatures with the new (pseudo-)algorithm for > different structures (e.g., CRLs, X509, X509_REQ, OCSP_REQ, OCSP_RESP, > etc.)* ? I see that there is some sort of different usages that can be > implemented in the CTRL of the ameth (e.g., rsa_pkey_ctrl), however this > seems to be targeted to the following operations: > > ASN1_PKEY_CTRL_PKCS7_SIGN > ASN1_PKEY_CTRL_PKCS7_ENCRYPT > ASN1_PKEY_CTRL_CMS_SIGN > ASN1_PKEY_CTRL_CMS_ENVELOPE > ASN1_PKEY_CTRL_CMS_RI_TYPE > ASN1_PKEY_CTRL_DEFAULT_MD_NID > > - Last but not least, since the EVP_PKEY has a union that points to > the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) where, > besides the rsa, dsa, dh, and ec pointers, a void * ptr is defined. Shall I > use that pointer to reference the composite_pkey_st (at least for the > user-space implementation) ? > > Yes. > > > Thanks for any help for understanding all these details... :D > > Cheers, > Max > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- SY, Dmitry Belyavsky
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
