How to Implement a new PubKey method correctly

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to Implement a new PubKey method correctly

Dr. Pala

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?

  • 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)

  • 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) ?

  • 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) ?

Thanks for any help for understanding all these details... :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to Implement a new PubKey method correctly

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Wed, 22 Aug 2018 08:55:02 -0600, "Dr. Pala" <[hidden email]> said:

director> Hi all,
director>
director> I am working on providing a new Public Key method that will handle
director> Composite Keys (i.e., multiple keys with different algos - e.g., one RSA
director> and one EC) and Composite Signatures  (i.e., multiple signatures
director> generated with the corresponding Composite Keys). In particular, I would
director> like to be able to add a method that will, in turn, call the methods
director> supported by the different keys that form the COMPOSITE_PKEY structure.
director>
director> I have looked around how to do it and I am a bit confused about how to
director> proceed as there are some conflicting implementations for different
director> algorithms.
director>
director> Here's some high-level questions related to the EVP_PKEY interface, in
director> particular:
director>
director>   * *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two
director>     different types of methods are used? Shall both be implemented?

Frankly, I'm a bit confused by this myself at times, so you have my
understanding.

The way I understand it is that:

- EVP_PKEY_ASN1_METHOD is related to the type itself, and defines
  everything that deals with manipulating the type itself and its
  contents.  This is also much more focused on ASN.1, i.e. encoding
  and decoding to/from DER, or printing out in a human readable form.

- EVP_PKEY_METHOD is about operations using the type.  The type itself
  is simply context to perform the operations in.  This is where the
  common operations (encryption, decryption, signing, verifying)
  belong.  These methods also usually combine the pkey type with
  appropriate digest algos.

It can be argued that these two methods have methods that might belong
in the other, and one might also wonder why there is a pkey check in both...

director>   * *After providing the implementation for the ameth/pmeth, how does
director>     the integration work with openssl?* In particular, should I add them
director>     to the list of the default ameth/pmeth supported? Here's some more
director>     specific questions:
director>
director>       o It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD
director>         - how do I add the method there (in case I will use a user-level
director>         - i.e., not integrated into OpenSSL code - approach by using the
director>         functions in the crypto/asn1/ameth_lib.c file). Will the
director>         EVP_PKEY_asn1_add0() function call be sufficient?

A call to EVP_PKEY_asn1_add0() should be sufficient.

director>       o It seems there is an standard_methods stack of
director>         EVP_PKEY_ASN1_METHOD - how do I add the method there if we need
director>         to have a more tight integration with the core of the library
director>         (in case we can not do our proof-of-concept without touching the
director>         openssl's code / requiring a fork)

If you want to integrate it more tightly, you will have to include
some code called att init time that does the EVP_PKEY_asn1_add0() call
mentioned above, or you will have to bite the bullet and fork (hey,
PRs welcome!)

director>   * *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed
director>     that, for example, both RSA and EC implement some form of _CTX and
director>     _PKEY structures. Are these used only internally or should they be
director>     implemented and integrated with the METHOD(s) ?

EVP_PKEY and EVP_PKEY_CTX?  Is that what you're talking about?

director>   * *Given the above is implemented correctly - will this enable the use
director>     of the method for processing signatures with the new
director>     (pseudo-)algorithm for different structures (e.g., CRLs, X509,
director>     X509_REQ, OCSP_REQ, OCSP_RESP, etc.)* ? I see that there is some
director>     sort of different usages that can be implemented in the CTRL of the
director>     ameth (e.g., rsa_pkey_ctrl), however this seems to be targeted to
director>     the following operations:
director>
director>                 ASN1_PKEY_CTRL_PKCS7_SIGN
director>                 ASN1_PKEY_CTRL_PKCS7_ENCRYPT
director>                 ASN1_PKEY_CTRL_CMS_SIGN
director>                 ASN1_PKEY_CTRL_CMS_ENVELOPE
director>                 ASN1_PKEY_CTRL_CMS_RI_TYPE
director>                 ASN1_PKEY_CTRL_DEFAULT_MD_NID

(I'm currently digging through that, and am not quite done)

director>   * Last but not least, since the EVP_PKEY has a union that points to
director>     the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st)
director>     where, besides the rsa, dsa, dh, and ec pointers, a void * ptr is
director>     defined. Shall I use that pointer to reference the composite_pkey_st
director>     (at least for the user-space implementation) ?

Use the ->ptr field, or even better (because evp_int.h is internal so
you shouldn't look), use EVP_PKEY_get0().

director> Thanks for any help for understanding all these details... :D

Let's keep talking...  I need to dig deeper anyway ;-)

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to Implement a new PubKey method correctly

Matt Caswell-2
In reply to this post by Dr. Pala


On 22/08/18 15:55, Dr. Pala 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?

It's a bit confusing and not particularly well defined, with some anomalies.

EVP_PKEY_ASN1_METHOD generally contain functions that operate *on* keys
and parameters.

EVP_PKEY_METHOD generally contains functions that *use* keys and
parameters to perform their operations.

A significant distinction is that (almost) all the EVP_PKEY_METHOD
functions operate within the context of an EVP_PKEY_CTX while none of
the EVP_PKEY_ASN1_METHOD functions do.

Typically you would define both method types for a particular algorithm.

>
>   * *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:
>
>       o 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?

Yes, that is the purpose of that function. See:

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_add0.html

>
>       o 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)


It's defined in crypto/asn1/standard_methods.h, so you just need to add
your custom method in there. Obviously, you will then need to also add
an implementation of that method and integrate it into the OpenSSL build
system.

It's probably worth looking at how other methods have been integrated,
e.g. you could look at ed448_asn1_meth which was recently added to 1.1.1.

>
>   * *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) ?

These are used internally only. You don't *need* to have them - but you
may want to have them if you have algorithm specific data that you need
to store.

>
>   * *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

In general once the methods are in place they should be useable
throughout the library. However you may find that some areas may need
additional tweaks to get them working, e.g. see the
X509_certificate_type() function. If integration into TLS was an
objective then that would definitely require additional custom code.


>
>   * 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. If you go down the tighter integration route then you can add your
own custom type there.

Matt


>
> Thanks for any help for understanding all these details... :D
>
> Cheers,
> Max
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to Implement a new PubKey method correctly

Dmitry Belyavsky-3
In reply to this post by Dr. Pala
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 <[hidden email]> 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

--
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

eonooiokingombaf.png (4K) Download Attachment
eonooiokingombaf.png (4K) Download Attachment