Great, thank you for the responses. I will get working on it, and report back if there are any issues.<div><br></div><div> Thanks!</div><div><br></div><div>Brett<br></div><div><div><br></div><signature></signature></div><img class="n1-open" width="0" height="0" style="border:0; width:0; height:0;" src="https://n1.nylas.com/open/0a9d9b3b8c233a9c5301562b7bb4ffb1d62048b81fb4a7cff2197d8fdf89d32c">
<div class="gmail_quote nylas-quote nylas-quote-id-40ea797c662b682e81c72ab79e5dd759bd25a7291a7e2e6a074cbdd1115bcc10">
<br>
On Aug 23 2017, at 5:13 pm, openssl-dev-request@openssl.org wrote:
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<pre class="nylas-plaintext">Send openssl-dev mailing list submissions to
openssl-dev@openssl.org
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
openssl-dev-request@openssl.org
You can reach the person managing the list at
openssl-dev-owner@openssl.org
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 <leonb@parsec.co.za>
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
Subject: [openssl-dev] Upgrading OpenSSL
Message-ID:
<13e455db80e548888c9cd15424bb146a@EXCHANGESRV.PARSEC.local>
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 <deengert@gmail.com>
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA
engine
Message-ID: <d6eb406f-4515-4bce-3cb2-5ab73d0f4e94@gmail.com>
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 <DEEngert@gmail.com>
------------------------------
Message: 3
Date: Wed, 23 Aug 2017 16:27:49 +0000
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
Message-ID: <95605C33-9954-4726-B398-BAE394EA468C@ll.mit.edu>
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 <paul.l.kehrer@gmail.com>
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
Message-ID:
<CABj5TKTyzum11dk0i482b9sYVvB7eFg9z8AmvrjmiA-xfr-feQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
openssl-dev@openssl.org) 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
openssl-dev@openssl.org
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
*******************************************
</pre>
</blockquote>
</div>