confusion with rsa_meth_st in a custom RSA engine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

confusion with rsa_meth_st in a custom RSA engine

Brett R. Nicholas

I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation. 


Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext. For decryption, it takes as inputs the base, and modulus. It does not need a private key, as this is stored in hardware, and can only be configured through an out-of-band channel. I already have a kernel module that exposes an API to userspace programs to use the accelerator. Now I just need to integrate it into openSSL.


I've already created a similar engine for AES and SHA256, however I'm struggling with RSA. Ideally, I'd like to not have to worry about anything other than just performing the modular exponentiation on a pre-padded and prepared chunk of data. For SHA and AES, this is straightforward: all that was taken care of by the EVP interface, so all I needed to worry about was getting the data two and from my accelerators. But it doesn't appear to be as simple for RSA (pls correct me if I'm wrong).


I'm confused as to which RSA_METHOD function pointers that my engine needs to implement.  I show the structure below for reference:

struct rsa_meth_st {
    char *name;
    int (*rsa_pub_enc) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_pub_dec) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_enc) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_dec) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);

    int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);

    int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
                       const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
    /* ....stuff.... */
    int flags;
    /* .... stuff ... */
};  // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h


So, three questions:


  1. Is it possible for the standard OpenSSL RSA implementation to use my engine's "modular exponentiation" function, without having to rewrite the RSA_[public|private]_[encrypt|decrypt] family of functions from /include/openssl/rsa.h
  2. If so, does it suffice to only implement the rsa_mod_exp function? Or must I implement both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for the old Intel RSAX engine (https://gist.github.com/bigbrett/91903f773f9d150b7329c7d462cd220a) does this, but I can't figure out how and when in the "RSA flow" the engine's function gets invoked.
  3. In  /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):
/*
 * This flag means the private key operations will be handled by rsa_mod_exp
 * and that they do not depend on the private key components being present:
 * for example a key stored in external hardware. Without this flag
 * bn_mod_exp gets called when private key components are absent.
 */
# define RSA_FLAG_EXT_PKEY               0x0020

Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT need to implement rsa_pub_enc/dec and friends? I guess I'm just confused as to at what point in the RSA encryption/decryption process my engine should be invoked at.


FWIW I'm planning on releasing a comprehensive engine tutorial and some documentation for all this stuff once I finish (will already be written up in my thesis), so I want to make sure I get these details ironed out!


Any words of wisdom would be greatly appreciated.

Best,

Brett



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Wed, 23 Aug 2017 01:50:04 +0000, "Brett R. Nicholas" <[hidden email]> said:

> I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions
> about the RSA_METHOD stucture implementation.
...

> I'm confused as to which RSA_METHOD function pointers that my engine needs to implement. I
> show the structure below for reference:
>
> struct rsa_meth_st {
> char *name;
> int (*rsa_pub_enc) (int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding);
> int (*rsa_pub_dec) (int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding);
> int (*rsa_priv_enc) (int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding);
> int (*rsa_priv_dec) (int flen, const unsigned char *from,
> unsigned char *to, RSA *rsa, int padding);
>
> int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);
>
> int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
> const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
> /* ....stuff.... */
> int flags;
> /* .... stuff ... */
> }; // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h
>
> So, three questions:
>
> 1 Is it possible for the standard OpenSSL RSA implementation to use my engine's
>  "modular exponentiation" function, without having to rewrite the RSA_
>  [public|private]_[encrypt|decrypt] family of functions from /include/openssl/rsa.h?

Yes.

> 2 If so, does it suffice to only implement the rsa_mod_exp function? Or must I implement
>  both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for
>  the old Intel RSAX engine
>  (https://gist.github.com/bigbrett/91903f773f9d150b7329c7d462cd220a) does this, but I can't
>  figure out how and when in the "RSA flow" the engine's function gets invoked.

I'd like to point out this part of the code, which is relevant:

    #ifndef OPENSSL_NO_RSA
    meth1 = RSA_PKCS1_SSLeay();
    e_rsax_rsa.rsa_pub_enc = meth1->rsa_pub_enc;
    e_rsax_rsa.rsa_pub_dec = meth1->rsa_pub_dec;
    e_rsax_rsa.rsa_priv_enc = meth1->rsa_priv_enc;
    e_rsax_rsa.rsa_priv_dec = meth1->rsa_priv_dec;
    e_rsax_rsa.bn_mod_exp = meth1->bn_mod_exp;
    e_rsax_rsa.finish = meth1->finish;
    #endif

You you see, you don't need to actually *reimplement* the
public/private encrypt/decrypt functions, but you need to make sure
there's *some* implementation available through the method you build
up.  Incidently, in more modern OpenSSLs, you should use
RSA_PKCS1_OpenSSL() rather than RSA_PKCS1_SSLeay().

Anyhow, the standard public/private encrypt/decrypt functions will
call the mod_exp functions that you implement

> 3 In /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):
>
> /*
> * This flag means the private key operations will be handled by rsa_mod_exp
> * and that they do not depend on the private key components being present:
> * for example a key stored in external hardware. Without this flag
> * bn_mod_exp gets called when private key components are absent.
> */
> # define RSA_FLAG_EXT_PKEY 0x0020
>
> Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT
> need to implement rsa_pub_enc/dec and friends? I guess I'm just confused as to at what
> point in the RSA encryption/decryption process my engine should be invoked at.

That flag means that the standard public/private encrypt/decrypt won't
try to access the p, q, dmp1 and iqmp components of the RSA structure,
i.e. the components that make up the private part.  Instead, that's
left entirely to the mod_exp function (i.e. what you actually do
implement).

If you want to see for yourself what's happening, I suggest a study of
crypto/rsa/rsa_ossl.c (OpenSSL 1.1.0 and up) or crypro/rsa/rsa_eay.c
(OpenSSL 1.0.2).

Cheers,
Richard

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

Re: confusion with rsa_meth_st in a custom RSA engine

Douglas E Engert
In reply to this post by Brett R. Nicholas
You can use  RSA_meth_dup to copy the default RSA_METHOD,then use the RSA_meth_set* routines to point to your own routines.
it only overrides  RSA_meth_set1_name, RSA_meth_set_priv_enc RSA_meth_set_priv_dec RSA_meth_set_finish see:

https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c

But You will have to populate the key with the public parts of the key.



On 8/22/2017 8:50 PM, Brett R. Nicholas wrote:

> I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation.
>
>
> Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext. For decryption, it takes as inputs the base, and modulus. It
> does not need a private key, as this is stored in hardware, and can only be configured through an out-of-band channel. I already have a kernel module that exposes an API to userspace programs to use
> the accelerator. Now I just need to integrate it into openSSL.
>
>
> I've already created a similar engine for AES and SHA256, however I'm struggling with RSA. Ideally, I'd like to not have to worry about anything other than just performing the modular exponentiation
> on a pre-padded and prepared chunk of data. For SHA and AES, this is straightforward: all that was taken care of by the EVP interface, so all I needed to worry about was getting the data two and from
> my accelerators. But it doesn't appear to be as simple for RSA (pls correct me if I'm wrong).
>
>
> I'm confused as to which RSA_METHOD function pointers that my engine needs to implement.  I show the structure below for reference:
>
> struct rsa_meth_st {
>      char *name;
>      int (*rsa_pub_enc) (int flen, const unsigned char *from,
>                          unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_pub_dec) (int flen, const unsigned char *from,
>                          unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_priv_enc) (int flen, const unsigned char *from,
>                           unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_priv_dec) (int flen, const unsigned char *from,
>                           unsigned char *to, RSA *rsa, int padding);
>
>      int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);
>
>      int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
>                         const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
>      /* ....stuff.... */
>      int flags;
>      /* .... stuff ... */
> };  // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h
>
>
> *So, three questions:
> *
>
> *
> *
>
>  1. *Is it possible for the standard OpenSSL RSA implementation to use my engine's "modular exponentiation" function, without having to rewrite the RSA_[public|private]_[encrypt|decrypt] family of
>     functions from /include/openssl/rsa.h?
>     *
>  2. *If so, does it suffice to only implement the rsa_mod_exp function? *Or must I implement both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for the old Intel
>     RSAX engine (https://gist.github.com/bigbrett/91903f773f9d150b7329c7d462cd220a) does this, but I can't figure out how and when in the "RSA flow" the engine's function gets invoked.
>  3. In /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):
>
> /*
>   * This flag means the private key operations will be handled by rsa_mod_exp
>   * and that they do not depend on the private key components being present:
>   * for example a key stored in external hardware. Without this flag
>   * bn_mod_exp gets called when private key components are absent.
>   */
> # define RSA_FLAG_EXT_PKEY               0x0020
>
> *Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT need to implement rsa_pub_enc/dec and friends? *I guess I'm just confused as to at what point in the RSA
> encryption/decryption process my engine should be invoked at.
>
>
> FWIW I'm planning on releasing a comprehensive engine tutorial and some documentation for all this stuff once I finish (will already be written up in my thesis), so I want to make sure I get these
> details ironed out!
>
>
> Any words of wisdom would be greatly appreciated.
>
> Best,
>
> Brett
>
>
>
>

--

  Douglas E. Engert  <[hidden email]>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Brett R. Nicholas
In reply to this post by Brett R. Nicholas
Great, thank you for the responses. I will get working on it, and report back if there are any issues.

 Thanks!

Brett


On Aug 23 2017, at 5:13 pm, [hidden email] wrote:
Send openssl-dev mailing list submissions to
	[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
	https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-dev&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961633322&sdata=cGd%2FAYdOx1enuZMSFZh1xtwApciFg4%2BqkOTFhXFmY%2Fk%3D&reserved=0
or, via email, send a message with subject or body 'help' to
	[hidden email]

You can reach the person managing the list at
	[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-dev digest..."


Today's Topics:

   1. Upgrading OpenSSL (Leon Brits)
   2. Re: confusion with rsa_meth_st in a custom RSA engine
      (Douglas E Engert)
   3. Re: Work on a new RNG for OpenSSL (Blumenthal, Uri - 0553 - MITLL)
   4. Re: Work on a new RNG for OpenSSL (Paul Kehrer)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Aug 2017 09:52:28 +0000
From: Leon Brits <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: [openssl-dev] Upgrading OpenSSL
Message-ID:
	<[hidden email]>
Content-Type: text/plain; charset="windows-1252"

Hi all,

I am task to update two machines from v0.9.8z to v1.0.2 (since it is LTS).

With the minimal changes, I've been able to get the application on the machines to compile with the newer version and generate RSA 4096 key pairs. The applications are able to successfully use their respective private keys and certificates to establish TLS connection between them. However, when I used the CLI to check a dumped privatekey i got the following output:

% openssl rsa -check -in privkey.pem
unable to load Private Key
1995859152:error:0D078079:asn1 encoding routines:ASN1_ITEM_EX_D2I:field missing:tasn_dec.c:489:Field=d, Type=RSA
1995859152:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib:rsa_ameth.c:121:
1995859152:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:evp_pkey.c:92:
1995859152:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:pem_pkey.c:141:

Any suggestions at what is wrong with the key?
Note that an ID is stored in the RSA extended data since the private key may be stored in HSM.

Thanks for your time
LJB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2Fattachments%2F20170823%2F3299f773%2Fattachment-0001.html&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=hhsuzGTYu4%2FEWXxC8XsP8awoCNWtBeUYzih0scpm2Zs%3D&reserved=0>

------------------------------

Message: 2
Date: Wed, 23 Aug 2017 09:15:47 -0500
From: Douglas E Engert <[hidden email]>
To: [hidden email]
Subject: Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA
	engine
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

You can use  RSA_meth_dup to copy the default RSA_METHOD,then use the RSA_meth_set* routines to point to your own routines.
it only overrides  RSA_meth_set1_name, RSA_meth_set_priv_enc RSA_meth_set_priv_dec RSA_meth_set_finish see:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOpenSC%2Flibp11%2Fblob%2Fmaster%2Fsrc%2Fp11_rsa.c&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=A56VNycqEEhDb8kmEP9fOSKgC%2Boh4GxYhw0vM23QpnM%3D&reserved=0

But You will have to populate the key with the public parts of the key.



On 8/22/2017 8:50 PM, Brett R. Nicholas wrote:
> I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation.
> 
> 
> Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext. For decryption, it takes as inputs the base, and modulus. It 
> does not need a private key, as this is stored in hardware, and can only be configured through an out-of-band channel. I already have a kernel module that exposes an API to userspace programs to use 
> the accelerator. Now I just need to integrate it into openSSL.
> 
> 
> I've already created a similar engine for AES and SHA256, however I'm struggling with RSA. Ideally, I'd like to not have to worry about anything other than just performing the modular exponentiation 
> on a pre-padded and prepared chunk of data. For SHA and AES, this is straightforward: all that was taken care of by the EVP interface, so all I needed to worry about was getting the data two and from 
> my accelerators. But it doesn't appear to be as simple for RSA (pls correct me if I'm wrong).
> 
> 
> I'm confused as to which RSA_METHOD function pointers that my engine needs to implement.  I show the structure below for reference:
> 
> struct rsa_meth_st {
>      char *name;
>      int (*rsa_pub_enc) (int flen, const unsigned char *from,
>                          unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_pub_dec) (int flen, const unsigned char *from,
>                          unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_priv_enc) (int flen, const unsigned char *from,
>                           unsigned char *to, RSA *rsa, int padding);
>      int (*rsa_priv_dec) (int flen, const unsigned char *from,
>                           unsigned char *to, RSA *rsa, int padding);
> 
>      int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);
> 
>      int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
>                         const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
>      /* ....stuff.... */
>      int flags;
>      /* .... stuff ... */
> };  // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h
> 
> 
> *So, three questions:
> *
> 
> *
> *
> 
>  1. *Is it possible for the standard OpenSSL RSA implementation to use my engine's "modular exponentiation" function, without having to rewrite the RSA_[public|private]_[encrypt|decrypt] family of
>     functions from /include/openssl/rsa.h?
>     *
>  2. *If so, does it suffice to only implement the rsa_mod_exp function? *Or must I implement both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for the old Intel
>     RSAX engine (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fbigbrett%2F91903f773f9d150b7329c7d462cd220a&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=psS%2B1hO3fPdpbx2eJ3IsCum0Gws2O7leIK8hGz4hRzU%3D&reserved=0) does this, but I can't figure out how and when in the "RSA flow" the engine's function gets invoked.
>  3. In /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):
> 
> /*
>   * This flag means the private key operations will be handled by rsa_mod_exp
>   * and that they do not depend on the private key components being present:
>   * for example a key stored in external hardware. Without this flag
>   * bn_mod_exp gets called when private key components are absent.
>   */
> # define RSA_FLAG_EXT_PKEY               0x0020
> 
> *Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT need to implement rsa_pub_enc/dec and friends? *I guess I'm just confused as to at what point in the RSA 
> encryption/decryption process my engine should be invoked at.
> 
> 
> FWIW I'm planning on releasing a comprehensive engine tutorial and some documentation for all this stuff once I finish (will already be written up in my thesis), so I want to make sure I get these 
> details ironed out!
> 
> 
> Any words of wisdom would be greatly appreciated.
> 
> Best,
> 
> Brett
> 
> 
> 
> 

-- 

  Douglas E. Engert  <[hidden email]>



------------------------------

Message: 3
Date: Wed, 23 Aug 2017 16:27:49 +0000
From: "Blumenthal, Uri - 0553 - MITLL" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

>    So I guess you want an interface that can both add things to the
>   "entropy" pool, and to the "additional data" pool? It shouldn't
>    be that hard, I'll try to come up with some proposal soon.
  
I?d say the interface that  Rich Salz proposed would be good enough:

> ?  But I think a new API, RAND_add_ex() that took a flag that had values like
> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
> RAND_LOCAL_PRIVATE indicating which to seed.     Thoughts?

It exposes what?s necessary, but nothing more. Another benefit ? malicious input would not compromise the entropy pool.

> We should think carefully about what API?s we are exposing, and might want to wait for 1.1.2

Nothing wrong with thinking about what API to expose, and how. Since 1.1.1 is what?s currently being shaped ? there?s no reason to postpone that thinking. Especially since the RNG/DRBG work is being done on 1.1.1 now, and this is a part of it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2Fattachments%2F20170823%2F3e3ce563%2Fattachment-0001.bin&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=TTGU%2FqlZN0ECz5uyisCNoBGXCLH559z%2FGDJk2kCh36w%3D&reserved=0>

------------------------------

Message: 4
Date: Wed, 23 Aug 2017 17:12:56 -0400
From: Paul Kehrer <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
Message-ID:
	<[hidden email]>
Content-Type: text/plain; charset="utf-8"

On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
[hidden email]) wrote:


I think the safest thing is for us to not change the default. Programs that
know they are going to fork can do the right/safe thing. It would be nicer
if we could automatically always do the right thing, but I don?t think it?s
possible.


It appears the current position is that since there will be edge cases
where a reseed would fail (thus either halting the RNG or silently not
reseeding it) that we should not attempt to reseed? I would argue it is
better to attempt to reseed and document that edge cases may need to reseed
themselves. This dramatically narrows the window from "everybody needs to
do it" to "users in certain scenarios that are becoming rarer by the day
need to do it". Given that backwards compatibility is a concern maybe
failure to reseed on fork should only drop an error on the child process's
error queue though? That behavior could potentially be a separate flag that
OpenSSL uses by default (OPENSSL_TRY_TO_INIT_ATFORK), and then
OPENSSL_INIT_ATFORK can be more strict about reseed failures if desired.

-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2Fattachments%2F20170823%2F8f227038%2Fattachment.html&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=tss3AXQYhrevslbQIISDga%2Fv0iP%2FFiBB%2B%2BORoO5f3iM%3D&reserved=0>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-dev mailing list
[hidden email]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-dev&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C57191a844b63437aa66d08d4ea6bc313%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636391195961789578&sdata=Kt9hKcaUQDqBnEqskEQ9W30lXAD9MOAqVjxwqOakgWQ%3D&reserved=0


------------------------------

End of openssl-dev Digest, Vol 33, Issue 15
*******************************************

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Brett R. Nicholas
In reply to this post by Brett R. Nicholas

I just realized that my reply to Richard and Douglas didn't go through....I had the emails bundled to a digest, so not sure how to properly reply to an individual thread.  My prior email should have said "Thanks, I"ll give it a try and let you know how it goes". Disabled the digest now, though.


@Richard, I've looked at the source like you suggested. One more question......quoting your reply below:

> That flag means that the standard public/private encrypt/decrypt won't
> try to access the p, q, dmp1 and iqmp components of the RSA structure,
> i.e. the components that make up the private part. Instead, that's > left entirely to the mod_exp function (i.e. what you actually do implement).
This makes sense to me, and it seems that is the desired behavior. However, if I *only* reimplement the rsa_mod_exp() function, and leave the encrypt/decrypt functions to the default openSSL implementations, how can my engine know which of the four of those functions called its rsa_mod_exp function()? To put it another way: my accelerator will need to know whether it is meant to perform public key or private key operations, since the inputs will be written to different memory addresses. From within rsa_mod_exp(), the only way I can think of determining whether the function has been called by private_encrypt/decrypt() or public_encrypt/decrypt would be to check if the  p and q fields of the RSA *rsa struct passed into the function are NULL? But I can't tell from the source code if this will be guaranteed just by having  RSA_FLAG_EXT_PKEY set in the "flags" field of my engine's RSA_METHOD.


Thanks for the help so far!


Brett


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Dr. Stephen Henson
On Sun, Aug 27, 2017, Brett R. Nicholas wrote:

>
> This makes sense to me, and it seems that is the desired behavior. However,
> if I *only* reimplement the rsa_mod_exp() function, and leave the
> encrypt/decrypt functions to the default openSSL implementations, how can my
> engine know which of the four of those functions called its rsa_mod_exp
> function()? To put it another way: my accelerator will need to know whether
> it is meant to perform public key or private key operations, since the
> inputs will be written to different memory addresses. From within
> rsa_mod_exp(), the only way I can think of determining whether the function
> has been called by private_encrypt/decrypt() or public_encrypt/decrypt would
> be to check if the  p and q fields of the RSA *rsa struct passed into the
> function are NULL? But I can't tell from the source code if this will be
> guaranteed just by having  RSA_FLAG_EXT_PKEY set in the "flags" field of my
> engine's RSA_METHOD.
>

The rsa_mod_exp function is only called for private key operations. You can't
tell if it is a private encrypt or a private decrypt though but that
shouldn't matter because the operation performed at that level is the same for
both.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Brett R. Nicholas

> The rsa_mod_exp function is only called for private key operations. You can't
> tell if it is a private encrypt or a private decrypt though but that
> shouldn't matter because the operation performed at that level is the same for
> both.

Ah, I see. So to clarify (pls correct me if I'm wrong):

  • rsa_mod_exp() is the modular exponentiation function that openSSL will attempt to use for all private key operations (if RSA_FLAG_EXT_PKEY is set, or the private parameters of that method are non-null), before defaulting to bn_mod_exp().
  • And bn_mod_exp() is the modular exponentiation function used by all public key operations


So in my case, I should set RSA_FLAG_EX_PKEY in my engine's RSA_METHOD struct, and then implement my own versions of rsa_mod_exp (for the private key encryption/decryption), and bn_mod_exp (for the public key encryption/decryption).


Brett



From: openssl-dev <[hidden email]> on behalf of Dr. Stephen Henson <[hidden email]>
Sent: Sunday, August 27, 2017 6:45 PM
To: [hidden email]
Subject: Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA engine
 
On Sun, Aug 27, 2017, Brett R. Nicholas wrote:

>
> This makes sense to me, and it seems that is the desired behavior. However,
> if I *only* reimplement the rsa_mod_exp() function, and leave the
> encrypt/decrypt functions to the default openSSL implementations, how can my
> engine know which of the four of those functions called its rsa_mod_exp
> function()? To put it another way: my accelerator will need to know whether
> it is meant to perform public key or private key operations, since the
> inputs will be written to different memory addresses. From within
> rsa_mod_exp(), the only way I can think of determining whether the function
> has been called by private_encrypt/decrypt() or public_encrypt/decrypt would
> be to check if the  p and q fields of the RSA *rsa struct passed into the
> function are NULL? But I can't tell from the source code if this will be
> guaranteed just by having  RSA_FLAG_EXT_PKEY set in the "flags" field of my
> engine's RSA_METHOD.
>

The rsa_mod_exp function is only called for private key operations. You can't
tell if it is a private encrypt or a private decrypt though but that
shouldn't matter because the operation performed at that level is the same for
both.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C5374bb23132c4377080c08d4edb671de%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636394815232517002&sdata=AdSj9Ys%2FG%2FQ1VJIIaD5kZhAwbki5mcF0AL8b2UBxic4%3D&reserved=0
--
openssl-dev mailing list
To unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-dev&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7C5374bb23132c4377080c08d4edb671de%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636394815232517002&sdata=zzQB9AlLiORZC2btJ6zi1MZQxVzoB8pgWHTtAC8LHtM%3D&reserved=0

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Dr. Stephen Henson
On Mon, Aug 28, 2017, Brett R. Nicholas wrote:

> > The rsa_mod_exp function is only called for private key operations. You can't
> > tell if it is a private encrypt or a private decrypt though but that
> > shouldn't matter because the operation performed at that level is the same for
> > both.
>
> Ah, I see. So to clarify (pls correct me if I'm wrong):
>
>   *   rsa_mod_exp() is the modular exponentiation function that openSSL will attempt to use for all private key operations (if RSA_FLAG_EXT_PKEY is set, or the private parameters of that method are non-null), before defaulting to bn_mod_exp().
>   *   And bn_mod_exp() is the modular exponentiation function used by all public key operations
>
>
> So in my case, I should set RSA_FLAG_EX_PKEY in my engine's RSA_METHOD struct, and then implement my own versions of rsa_mod_exp (for the private key encryption/decryption), and bn_mod_exp (for the public key encryption/decryption).
>
>

Yes. Note also that if you set the public key components (n, e) you don't need
to perform the public key operations in your ENGINE if you keep the original
bn_mod_exp(): OpenSSL will do them for you. If possible you should set the
public key components anyway: some operations such as generating certificate
requests require them to be present.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Brett R. Nicholas

> Note also that if you set the public key components (n, e) you don't need
> to perform the public key operations in your ENGINE if you keep the original
> bn_mod_exp(): OpenSSL will do them for you

This is good to know. However, I think I will be implementing modular exponentiation for both public and private keys in hardware for proof of concept.


One more follow up question:      


> If possible you should set the public key components anyway: some operations

> such as generating certificate requests require them to be present

I'm confused what you mean here, since my engine doesn't "own" any instances of an RSA struct, it just has a static instance of RSA_METHOD struct defined. So therefore my engine never "sets" public or private key components. It just uses the modexp functions to write the public/private data (contained in the RSA struct passed as an argument from the higher level encrypt/decrypt functions) out to the hardware accelerator, and then return the result. So I could never "set the public key components anyway", as they would be set by whichever program calls RSA_public/private_encrypt/decrypt().


Is my implementing it in this way different than how you thought I was implementing it? It made sense to me to do it this way, however please let me know if you think I'm going about it wrong, or if there are issues with this particular strategy. I want to make sure I'm using the engine API in the most intuitive and efficient way!


Brett


From: openssl-dev <[hidden email]> on behalf of Dr. Stephen Henson <[hidden email]>
Sent: Monday, August 28, 2017 10:32:30 AM
To: [hidden email]
Subject: Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA engine
 
On Mon, Aug 28, 2017, Brett R. Nicholas wrote:

> > The rsa_mod_exp function is only called for private key operations. You can't
> > tell if it is a private encrypt or a private decrypt though but that
> > shouldn't matter because the operation performed at that level is the same for
> > both.
>
> Ah, I see. So to clarify (pls correct me if I'm wrong):
>
>   *   rsa_mod_exp() is the modular exponentiation function that openSSL will attempt to use for all private key operations (if RSA_FLAG_EXT_PKEY is set, or the private parameters of that method are non-null), before defaulting to bn_mod_exp().
>   *   And bn_mod_exp() is the modular exponentiation function used by all public key operations
>
>
> So in my case, I should set RSA_FLAG_EX_PKEY in my engine's RSA_METHOD struct, and then implement my own versions of rsa_mod_exp (for the private key encryption/decryption), and bn_mod_exp (for the public key encryption/decryption).
>
>

Yes. Note also that if you set the public key components (n, e) you don't need
to perform the public key operations in your ENGINE if you keep the original
bn_mod_exp(): OpenSSL will do them for you. If possible you should set the
public key components anyway: some operations such as generating certificate
requests require them to be present.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7Cb1b7883dd5584c8488d708d4ee3ac4e4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636395383568793933&sdata=wDesZm0QTSpMHyOtQyAaWQRzEVYFmp9ewgZaZDn6unI%3D&reserved=0
--
openssl-dev mailing list
To unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-dev&data=02%7C01%7Cbrett.r.nicholas.th%40dartmouth.edu%7Cb1b7883dd5584c8488d708d4ee3ac4e4%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C636395383568793933&sdata=g8dPj%2Fx9GwR6ldjezTCNKWkvcIOzy1nK0wSLK30ZjjY%3D&reserved=0

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: confusion with rsa_meth_st in a custom RSA engine

Dr. Stephen Henson
On Mon, Aug 28, 2017, Brett R. Nicholas wrote:

>
>
> One more follow up question:
>
>
> > If possible you should set the public key components anyway: some operations
>
> > such as generating certificate requests require them to be present
>
> I'm confused what you mean here, since my engine doesn't "own" any instances of an RSA struct, it just has a static instance of RSA_METHOD struct defined. So therefore my engine never "sets" public or private key components. It just uses the modexp functions to write the public/private data (contained in the RSA struct passed as an argument from the higher level encrypt/decrypt functions) out to the hardware accelerator, and then return the result. So I could never "set the public key components anyway", as they would be set by whichever program calls RSA_public/private_encrypt/decrypt().
>
>
> Is my implementing it in this way different than how you thought I was implementing it? It made sense to me to do it this way, however please let me know if you think I'm going about it wrong, or if there are issues with this particular strategy. I want to make sure I'm using the engine API in the most intuitive and efficient way!
>
>

Ah if you're performing crypto acceleration of already existing keys then
that's fine.

In some cases an ENGINE can load a private key (typically from an HSM) and
returns the EVP_PKEY structure: in that case it would initialise the RSA
structure for RSA keys. It's that case where (n, e) should be initialised
if possible.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev