Re: error: redefinition of ‘struct rsa_meth_st’

[Shariful Alam]

Mr, Matt,
Thanks for the link. It was helpful. However, I'm encountering some weird
issues while compiling.
I have two machines. In one machine The following code is compiling and
working file whereas in another machine I'm receiving *"warning: implicit
declaration of function ‘RSA_meth_new’" *during compilation. Both of my
machine is running

   - *Linux 4.15.0-140-generic,*
   - *gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609*
   - *OpenSSL 1.1.1c  28 May 2019*


My simple code is below.

//rsa-engine.c
===
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* Engine Id and Name */
static const char *engine_dasync_id = "dasync";
static const char *engine_dasync_name = "Dummy Async engine support";

static int dasync_pub_enc(int flen, const unsigned char *from, unsigned
char *to, RSA *rsa, int padding) {
  printf("dasync_pub_enc\n");
  return 0;
}

static int dasync_pub_dec(int flen, const unsigned char *from, unsigned
char *to, RSA *rsa, int padding) {
  printf("dasync_pub_dec\n");
  return 0;
}

static int dasync_rsa_priv_enc(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding){
printf("dasync_rsa_priv_enc\n");
return 0;
}

static int dasync_rsa_priv_dec(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding){
printf("dasync_rsa_priv_dec\n");
return 0;
}

static RSA_METHOD *dasync_rsa_method = NULL;
static int bind_dasync(ENGINE *e){
/* Setup RSA_METHOD */
if ((dasync_rsa_method = RSA_meth_new("Dummy Async RSA method", 0)) ==
NULL
|| RSA_meth_set_pub_enc(dasync_rsa_method, dasync_pub_enc) == 0
|| RSA_meth_set_pub_dec(dasync_rsa_method, dasync_pub_dec) == 0
|| RSA_meth_set_priv_enc(dasync_rsa_method, dasync_rsa_priv_enc) ==
0
|| RSA_meth_set_priv_dec(dasync_rsa_method, dasync_rsa_priv_dec) ==
0
) {
return 0;
}

if (!ENGINE_set_id(e, engine_dasync_id)
|| !ENGINE_set_name(e, engine_dasync_name)
|| !ENGINE_set_RSA(e, dasync_rsa_method)
 ) {
 return 0;
}
return 1;
}

static int bind_helper(ENGINE *e, const char *id){
if (!bind_dasync(e)){
printf("2_Error: Inside Bind helper\n");
return 0;
}
return 1;
}

IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)
IMPLEMENT_DYNAMIC_CHECK_FN()


===

In the machine where this engine is working, I use the following command to
compile my code,

   -
*gcc -fPIC -c rsa-engine.c *
   - *gcc -shared -o librsa_engine.so -lcrypto rsa-engine.o*

And Following command to load my engine,

   - *openssl engine -t -c `pwd`/librsa_engine.so*


The same code on the other machine upon running,  *gcc -fPIC -c
rsa-engine.c, *I get the following warning,

ss@ss:~/Downloads/test_engine$ gcc -fPIC -c rsa-engine.c
rsa-engine.c: In function ‘bind_dasync’:
rsa-engine.c:64:30: warning: implicit declaration of function
‘RSA_meth_new’ [-Wimplicit-function-declaration]
 if ((dasync_rsa_method = RSA_meth_new("Dummy Async RSA method", 0)) ==
NULL
  ^
rsa-engine.c:64:28: warning: assignment makes pointer from integer without
a cast [-Wint-conversion]
 if ((dasync_rsa_method = RSA_meth_new("Dummy Async RSA method", 0)) ==
NULL
^
rsa-engine.c:65:12: warning: implicit declaration of function
‘RSA_meth_set_pub_enc’ [-Wimplicit-function-declaration]
 || RSA_meth_set_pub_enc(dasync_rsa_method, dasync_pub_enc) == 0
^
rsa-engine.c:66:12: warning: implicit declaration of function
‘RSA_meth_set_pub_dec’ [-Wimplicit-function-declaration]
 || RSA_meth_set_pub_dec(dasync_rsa_method, dasync_pub_dec) == 0
^
rsa-engine.c:67:12: warning: implicit declaration of function
‘RSA_meth_set_priv_enc’ [-Wimplicit-function-declaration]
 || RSA_meth_set_priv_enc(dasync_rsa_method, dasync_rsa_priv_enc)
== 0
^
rsa-engine.c:68:12: warning: implicit declaration of function
‘RSA_meth_set_priv_dec’ [-Wimplicit-function-declaration]
 || RSA_meth_set_priv_dec(dasync_rsa_method, dasync_rsa_priv_dec)
== 0



can you please tell me why the same code is throwing two different results
in different machines?


Regards,
Shariful Alam







On Mon, Apr 12, 2021 at 10:42 AM Matt Caswell  wrote:

> You can look at the dummy async engine which wraps the standard RSA
> functions inside an engine (as well as various other crypto primitives).
> You can see it here:
>
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c
>
> Matt
>
> On 12/04/2021 17:32, Shariful Alam wrote:
> > Dr. Pauli,
> > Goodmorning. Thank you for replying. I found the documentation a bit
> > difficult for me to understand. I was wondering if you can direct me to
> > a sample skeleton code for creating a custom RSA engine.
> >
> > Regards,
> > Shariful Alam
> >
> > On Sun, Apr 11, 2021 at 

FW: Strange warnings while linking to openssl version 1.1.1k

[Michael Wojcik]

> From: openssl-users  On Behalf Of Robert 
> Smith via openssl-users
> Sent: Monday, 12 April, 2021 14:52

Your message has a Reply-to header set, directing replies to you rather than to 
the list. Don't do that; it's rude. Ask a question here, read the reply here. 
Other people may be interested in the responses.

> I am getting the following warning while linking my app to openssl version 
> 1.1.1k.
> Could you advise what can cause these warnings and how to resolve them?
> ../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
> function `ASYNC_is_capable':
> async_posix.c:(.text+0x48): warning: warning: getcontext is not implemented 
> and will always fail

DuckDuckGo is your friend. The first hit for "getcontext is not implemented and 
will always fail" explains that this is an ARM issue, not an OpenSSL one. 
Another hit a little further down provides more details. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369453

No one has implemented getcontext, etc, for ARM yet. Consequently they don't 
work. The warning messages are emitted by the GNU toolchain, which knows the 
context functions are not available on this platform.

OpenSSL can detect this at runtime - see ASYNC_is_capable() in async_posix.c, 
and its use in e.g. speed.c. Since there is no viable async implementation on 
Linux-ARM, you won't be able to use the OpenSSL async-job APIs, as described in 
the OpenSSL docs. If you don't need those APIs, these warnings are irrelevant.

--
Michael Wojcik

Re: Strange warnings while linking to openssl version 1.1.1k

[Matt Caswell]

On 12/04/2021 21:52, Robert Smith via openssl-users wrote:

Hi,

I am getting the following warning while linking my app to openssl 
version 1.1.1k. Could you advise what can cause these warnings and how 
to resolve them? Thanks


It looks like your environment cannot support the async functionality. 
Compile OpenSSL with the "no-async" compile time option to squash these 
warnings.


Matt





../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `ASYNC_is_capable':
async_posix.c:(.text+0x48): warning: warning: getcontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In function 
`async_fibre_swapcontext':
async.c:(.text+0x248): warning: warning: setcontext is not implemented 
and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':
async_posix.c:(.text+0xe8): warning: warning: makecontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `ASYNC_is_capable':
async_posix.c:(.text+0x48): warning: warning: getcontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In function 
`async_fibre_swapcontext':
async.c:(.text+0x248): warning: warning: setcontext is not implemented 
and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':
async_posix.c:(.text+0xe8): warning: warning: makecontext is not 
implemented and will always fail

Strange warnings while linking to openssl version 1.1.1k

[Robert Smith via openssl-users]

Hi,

I am getting the following warning while linking my app to openssl version 
1.1.1k. Could you advise what can cause these warnings and how to resolve them? 
Thanks

../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In function 
`ASYNC_is_capable':
async_posix.c:(.text+0x48): warning: warning: getcontext is not implemented and 
will always fail../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In 
function `async_fibre_swapcontext':async.c:(.text+0x248): warning: warning: 
setcontext is not implemented and will always 
fail../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':async_posix.c:(.text+0xe8): warning: 
warning: makecontext is not implemented and will always 
fail../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `ASYNC_is_capable':async_posix.c:(.text+0x48): warning: warning: 
getcontext is not implemented and will always 
fail../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In function 
`async_fibre_swapcontext':async.c:(.text+0x248): warning: warning: setcontext 
is not implemented and will always 
fail../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':async_posix.c:(.text+0xe8): warning: 
warning: makecontext is not implemented and will always fail

Re: EVP_MAC_init() in 3.0 alpha 13

[Hal Murray]

to...@openssl.org said:
> We would have to introduce the special semantics similar to EVP_CipherInit()
> with EVP_MAC_init(). I.e., that the EVP_CipherInit() with NULL key keeps the
> key schedule from the previous initialization. 

Seems like a good idea to me.  The current code doesn't crash and doesn't 
generate an error return.  Is there any other useful thing that a NULL key 
could do?

I don't have a big picture view.  Is there any reason that all of the crypto 
init type procedures can't keep the current key schedule if called with a NULL 
key?

Am I the only one (so far) that is interested in reusing the current key 
schedule to save CPU cycles?



-- 
These are my opinions.  I hate spam.

Re: error: redefinition of ‘struct rsa_meth_st’

[Matt Caswell]

On 12/04/2021 18:06, Blumenthal, Uri - 0553 - MITLL wrote:

Is there an analog of the "dummy async engine" for the OpenSSL-3.0 Provider?


There isn't a simple analog for RSA specifically.

There's the test "tls-provider" which implements a toy KEX and KEM 
algorithm:


https://github.com/openssl/openssl/blob/master/test/tls-provider.c

For a bare bones skeleton do-nothing provider you can look at the null 
provider:


https://github.com/openssl/openssl/blob/master/providers/nullprov.c

You can also have a look at the legacy provider for a (relatively) 
simple example of how to do ciphers and digests:


https://github.com/openssl/openssl/blob/master/providers/legacyprov.c

Of course you should also look at the documentation:

https://www.openssl.org/docs/manmaster/man7/provider.html

If the interest is RSA specifically you may want to look at the provider 
asymmetric cipher documentation:


https://www.openssl.org/docs/manmaster/man7/provider-asym_cipher.html

as well as the provider signatures documentation:

https://www.openssl.org/docs/manmaster/man7/provider-signature.html

and the provider key management documentation:

https://www.openssl.org/docs/manmaster/man7/provider-keymgmt.html


Matt



TNX
--
Regards,
Uri
  
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

  -  C. A. R. Hoare
  


On 4/12/21, 12:43, "openssl-users on behalf of Matt Caswell" 
 wrote:

 You can look at the dummy async engine which wraps the standard RSA
 functions inside an engine (as well as various other crypto primitives).
 You can see it here:

 
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

 Matt

 On 12/04/2021 17:32, Shariful Alam wrote:
 > Dr. Pauli,
 > Goodmorning. Thank you for replying. I found the documentation a bit
 > difficult for me to understand. I was wondering if you can direct me to
 > a sample skeleton code for creating a custom RSA engine.
 >
 > Regards,
 > Shariful Alam
 >
 > On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale  > wrote:
 >
 > You shouldn't be accessing the internal of a private structure. That
 > structure was made private for a reason and duplicating it in your
 > engine will break when we change the structure's contents.
 >
 > Your engine should be using the EVP_PKEY_meth_set_* function to do
 > what you want (for 1.1.1).  For 3.0, you should be writing a
 > provider instead.
 >
 >
 > Pauli
 >
 > On 12/4/21 5:04 am, Shariful Alam wrote:
 >> Hello,
 >> Hope you guys are doing well. I'm trying to develop an RSA engine.
 >> My engine was somewhat working until I try to integrate my engine
 >> with an apache httpd server. After installing the httpd from the
 >> source code, it turns out that, I can't compile my engine anymore.
 >> I get the following error while I try to compile (it was compiling
 >> before and I did not make any changes to my engine code).
 >>
 >> ==
 >>
 >> *$gcc -fPIC -c r_engine.c*
 >> *r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
 >>  struct rsa_meth_st {
 >> ^
 >> In file included from /usr/include/openssl/crypto.h:131:0,
 >>  from r_engine.c:7:
 >> /usr/include/openssl/ossl_typ.h:147:16: note: originally defined 
here
 >>  typedef struct rsa_meth_st RSA_METHOD;*
 >>
 >> =
 >>
 >> and my *struct rsa_meth_st *looks like the following,
 >>
 >> 

 >>
 >> *struct rsa_meth_st {
 >>
 >> const 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);
 >>
 >> int (*init) (RSA *rsa);
 >>
 >> int (*finish) (RSA 

Re: PKCS7_decrypt vs RSA OAEP padding

[Eliot Lear]

Hi Michal,

CMS has limited backward compatibility with PKCS#7.  This is discussed 
in RFC 5652 , and 
includes some suggestions as to how to some issues that might crop up.   
At least the old draft of SCEP very specifically does NOT specify CMS, 
but that might not have stopped someone from using it.  These docs tend 
to be quite sloppy.  For example, I know one that uses both PEM and DER 
encodings on the wire.  Drives me batty.


For enrolment this is particularly embarrassing, considering its 
sensitivity.  As a sysadmin, you might try wrapping this stuff in PHP 
and just trying both the pkcs_decrypt and cms_decrypt calls and seeing 
if either work.


Eliot

On 12.04.21 14:13, Michal Moravec wrote:

Hello,

I am a system administrator trying to integrate two pieces of software 
using the SCEP protocol (more on that later in the More Context section) .
Integration was working but one side (SaaS product) changed the 
algorithms it uses for signing and encryption within the PKCS7 message.
After that I am unable to decrypt the PKCS7 messages on my end and get 
the error: "ERROR 139701710696896:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:597:

message_static_functions.c:221: decryption failed"

From my current state of investigation it looks highly likely there is 
a problem with PKCS7_decrypt method which might be unable decrypt the 
PKCS7/CMS payload if the RSA is used together with OAEP padding.


1. What is a diffrences between pkcs7 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7 
 and 
CMS 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/cms 
 implementations?


If I understand correctly CMS is just newer name for PKCS7 adopted by 
newer RFCs?

Do these two implementations overlap?
Or are there some kind of major diffrence like PKCS7 module being 
there for compatibility with older code and CMS is basically 
replacement to use for the future?


2. Is PKCS7_decrypt method in 
https://github.com/openssl/openssl/blob/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7/pk7_smime.c 
 capable 
of decrypting the PKCS7 payload whebf OAEP padding is used together 
with RSA to encrypt it? If it is indeed not capable of doing that 
would it be a bug or desired behavior?


If found a few pointers:

- 
https://stackoverflow.com/questions/56941480/how-to-set-padding-oaep-for-pkcs7-decrypt-function-using-openssl 
 <- 
Developer is unable to use PKCS7_decrypt with RSA OAEP and forced to 
switch to CMS_decrypt method.
- 
https://stackoverflow.com/questions/34304570/how-to-resolve-the-evp-decryptfinal-ex-bad-decrypt-during-file-decryption 
 <- 
Padding being a source problem of EVP_DecryptFinal_ex:bad decrypt 
error message.


3. How to replace PKCS7_decrypt method CMS_decrypt as easily as possible?

I have no hard proof of the PKCS7_decrypt being the culprit here so I 
started working on simple C program to reproduce the issue.
Problem is my C skills are very rusty and I have no experience working 
with OpenSSL C library.


int PKCS7_decrypt(PKCS7 *p7,  EVP_PKEY *pkey, X509 *cert, BIO *data, 
             int flags);
int CMS_decrypt    (CMS_ContentInfo *cms, EVP_PKEY *pkey, X509 *cert, 
BIO *dcont, BIO *out, unsigned int flags);


Methods are very similiar but input data format it different. It there 
an easyway to convert PKCS7 struct into CMS_ContentInfo struct?


Original usage of PKCS7_decrypt here -> 
https://github.com/openxpki/libscep/blob/4067eae283ce0b3025d414e9d3b6af30def8c093/src/message_static_functions.c 
 




# More Context

My goal is to obtain signed client certificate using the SCEP protocol.

SCEP server: OpenXPKI https://github.com/openxpki/openxpki 
 (Perl) with libscep 
https://github.com/openxpki/libscep 
 library (C). libscep used the 
OpenSSL.
SCEP client: VMware Workspace ONE UEM SaaS (WSO). Black box. From the 
error codes client produces I strongly suspect they use OpenSSL within 
.Net code.


Originally WSO SCEP client used these three algorithms for PKCS7 
operation: SHA-1, RSA (PKCS 1.5 padding or no padding <- can't tell 
which) and 3DES-CBC.
They made some sort of change (unannouced) and since 

Re: error: redefinition of ‘struct rsa_meth_st’

[Blumenthal, Uri - 0553 - MITLL]

Is there an analog of the "dummy async engine" for the OpenSSL-3.0 Provider?

TNX
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare
 

On 4/12/21, 12:43, "openssl-users on behalf of Matt Caswell" 
 wrote:

You can look at the dummy async engine which wraps the standard RSA 
functions inside an engine (as well as various other crypto primitives). 
You can see it here:


https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

Matt

On 12/04/2021 17:32, Shariful Alam wrote:
> Dr. Pauli,
> Goodmorning. Thank you for replying. I found the documentation a bit 
> difficult for me to understand. I was wondering if you can direct me to 
> a sample skeleton code for creating a custom RSA engine.
> 
> Regards,
> Shariful Alam
> 
> On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale  > wrote:
> 
> You shouldn't be accessing the internal of a private structure. That
> structure was made private for a reason and duplicating it in your
> engine will break when we change the structure's contents.
> 
> Your engine should be using the EVP_PKEY_meth_set_* function to do
> what you want (for 1.1.1).  For 3.0, you should be writing a
> provider instead.
> 
> 
> Pauli
> 
> On 12/4/21 5:04 am, Shariful Alam wrote:
>> Hello,
>> Hope you guys are doing well. I'm trying to develop an RSA engine.
>> My engine was somewhat working until I try to integrate my engine
>> with an apache httpd server. After installing the httpd from the
>> source code, it turns out that, I can't compile my engine anymore.
>> I get the following error while I try to compile (it was compiling
>> before and I did not make any changes to my engine code).
>>
>> ==
>>
>> *$gcc -fPIC -c r_engine.c*
>> *r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
>>  struct rsa_meth_st {
>> ^
>> In file included from /usr/include/openssl/crypto.h:131:0,
>>  from r_engine.c:7:
>> /usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
>>  typedef struct rsa_meth_st RSA_METHOD;*
>>
>> =
>>
>> and my *struct rsa_meth_st *looks like the following,
>>
>> 

>>
>> *struct rsa_meth_st {
>>
>> const 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);
>>
>> int (*init) (RSA *rsa);
>>
>> int (*finish) (RSA *rsa);
>>
>> int flags;
>>
>> char *app_data;
>>
>> int (*rsa_sign) (int type, const unsigned char *m, unsigned
>> int m_length, unsigned char *sigret, unsigned int *siglen, const
>> RSA *rsa);
>>
>> int (*rsa_verify) (int dtype, const unsigned char *m, unsigned
>> int m_length, const unsigned char *sigbuf, unsigned int siglen,
>> const RSA *rsa);
>>
>> int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb);
>>
>> };
>> *
>>
>> 
=
>>
>> My sample skeleton code is here https://pastebin.com/uNXYknEA
>> 
>>
>> Can anyone please tell me what I'm I doing wrong?
>>
>> Regards,
>> Shariful Alam
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: error: redefinition of ‘struct rsa_meth_st’

[Matt Caswell]

You can look at the dummy async engine which wraps the standard RSA 
functions inside an engine (as well as various other crypto primitives). 
You can see it here:


https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

Matt

On 12/04/2021 17:32, Shariful Alam wrote:

Dr. Pauli,
Goodmorning. Thank you for replying. I found the documentation a bit 
difficult for me to understand. I was wondering if you can direct me to 
a sample skeleton code for creating a custom RSA engine.


Regards,
Shariful Alam

On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale > wrote:


You shouldn't be accessing the internal of a private structure. That
structure was made private for a reason and duplicating it in your
engine will break when we change the structure's contents.

Your engine should be using the EVP_PKEY_meth_set_* function to do
what you want (for 1.1.1).  For 3.0, you should be writing a
provider instead.


Pauli

On 12/4/21 5:04 am, Shariful Alam wrote:

Hello,
Hope you guys are doing well. I'm trying to develop an RSA engine.
My engine was somewhat working until I try to integrate my engine
with an apache httpd server. After installing the httpd from the
source code, it turns out that, I can't compile my engine anymore.
I get the following error while I try to compile (it was compiling
before and I did not make any changes to my engine code).

==

*$gcc -fPIC -c r_engine.c*
*r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
 struct rsa_meth_st {
        ^
In file included from /usr/include/openssl/crypto.h:131:0,
                 from r_engine.c:7:
/usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
 typedef struct rsa_meth_st RSA_METHOD;*

=

and my *struct rsa_meth_st *looks like the following,




*struct rsa_meth_st {

    const 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);

    int (*init) (RSA *rsa);

    int (*finish) (RSA *rsa);

    int flags;

    char *app_data;

    int (*rsa_sign) (int type, const unsigned char *m, unsigned
int m_length, unsigned char *sigret, unsigned int *siglen, const
RSA *rsa);

    int (*rsa_verify) (int dtype, const unsigned char *m, unsigned
int m_length, const unsigned char *sigbuf, unsigned int siglen,
const RSA *rsa);

    int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb);

};
*


=

My sample skeleton code is here https://pastebin.com/uNXYknEA


Can anyone please tell me what I'm I doing wrong?

Regards,
Shariful Alam

Re: PEM_read_bio_RSAPublicKey equivalent API which returns EVP_PKEY

[Richard Levitte]

On Mon, 12 Apr 2021 06:24:32 +0200,
Paramashivaiah, Sunil wrote:
> 
> But, I couldn't find equivallent API to replace "PEM_read_bio_RSAPublicKey" 
> to get EVP_PKEY for 
> creating EVP ctx(EVP_PKEY_CTX_new) to use in "EVP_PKEY_encrypt" and 
> "EVP_PKEY_decrypt".

I believe that one of these functions would help you:

EVP_PKEY_CTX *EVP_PKEY_CTX_new(EVP_PKEY *pkey, ENGINE *e);

EVP_PKEY_CTX *EVP_PKEY_CTX_new_from_pkey(OSSL_LIB_CTX *libctx,
 EVP_PKEY *pkey, const char *propquery);

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: error: redefinition of ‘struct rsa_meth_st’

[Shariful Alam]

Dr. Pauli,
Goodmorning. Thank you for replying. I found the documentation a bit
difficult for me to understand. I was wondering if you can direct me to a
sample skeleton code for creating a custom RSA engine.

Regards,
Shariful Alam

On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale  wrote:

> You shouldn't be accessing the internal of a private structure.  That
> structure was made private for a reason and duplicating it in your engine
> will break when we change the structure's contents.
>
> Your engine should be using the EVP_PKEY_meth_set_* function to do what
> you want (for 1.1.1).  For 3.0, you should be writing a provider instead.
>
>
> Pauli
>
> On 12/4/21 5:04 am, Shariful Alam wrote:
>
> Hello,
> Hope you guys are doing well. I'm trying to develop an RSA engine. My
> engine was somewhat working until I try to integrate my engine with an
> apache httpd server. After installing the httpd from the source code, it
> turns out that, I can't compile my engine anymore. I get the
> following error while I try to compile (it was compiling before and I did
> not make any changes to my engine code).
>
> ==
>
> *$gcc -fPIC -c r_engine.c*
>
>
>
>
>
>
> *r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’  struct
> rsa_meth_st { ^ In file included from
> /usr/include/openssl/crypto.h:131:0,  from r_engine.c:7:
> /usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
>  typedef struct rsa_meth_st RSA_METHOD;*
>
> =
>
> and my *struct rsa_meth_st *looks like the following,
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *struct rsa_meth_st { const 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);
> int (*init) (RSA *rsa); int (*finish) (RSA *rsa); int flags;
> char *app_data; int (*rsa_sign) (int type, const unsigned char *m,
> unsigned int m_length, unsigned char *sigret, unsigned int *siglen, const
> RSA *rsa); int (*rsa_verify) (int dtype, const unsigned char *m,
> unsigned int m_length, const unsigned char *sigbuf, unsigned int siglen,
> const RSA *rsa); int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e,
> BN_GENCB *cb); }; *
>
>
> =
>
> My sample skeleton code is here https://pastebin.com/uNXYknEA
>
> Can anyone please tell me what I'm I doing wrong?
>
> Regards,
> Shariful Alam
>
>
>

Re: EVP_MAC_init() in 3.0 alpha 13

[Tomas Mraz]

On Mon, 2021-04-12 at 05:48 -0700, Hal Murray wrote:
> > Did you attempt to pass NULL for the key and zero for it's length
> > to the
> > EVP_MAC_init() call? 
> 
> Yes.
> 
> We can do better.  If we have to use dup/free, we can move the
> EVP_MAC_init() 
> to before the dup, out of the timing path.
> 
> My model is that initialization is 2 parts.  The first is turning the
> key into 
> a big table.  The second is initializing a small amount of state that
> is 
> whatever is needed/updated by EVP_MAC_update().
> 
> I was hoping that EVP_MAC_init() with NULL key would bypass the first
> step and 
> do the second.

We would have to introduce the special semantics similar to
EVP_CipherInit() with EVP_MAC_init(). I.e., that the EVP_CipherInit()
with NULL key keeps the key schedule from the previous initialization.

> If the second step involves a lot of computation we get into the
> space/time 
> tradeoff of computing it during step one and saving it in case
> EVP_MAC_init is 
> called with NULL key.
> 
> If there was a copy operation we could use it instead of dup/free.

I do not think we want to introduce the copy operation. We are trying
to get out of the copy() pattern as it is much harder to handle
correctly than the dup().

> Where is the code that does the key setup?  I expect it will be
> obvious after 
> I see it, but I don't know my way around that linkage yet.  I'm using
> the 
> default AES-128-CBC.
> 
> -
> 
> I don't think I've said it explicitly, but thanks for the change to
> the API 
> for EVP_MAC_init()
> 
> --
> 
> Should PKEY be a potentially interesting approach for something like
> this?  I 
> think it was suggested months ago.  One advantage is that the code
> works with 
> 1.1.1.
> 
> It's horribly slow in 3.0
> 
> alpha14:
> 0.777 CMAC
> 7.533 PKEY
> 3.323 PKEY preload
> 0.392 EVP_MAC
> 0.308 EVP_MAC Preload with dup+free
> 0.102 EVP_MAC Preload (no dup, wrong answer)
> 
> 1.1.1k:
> 0.285 CMAC
> 0.550 PKEY
> 0.196 PKEY preload
> 
> 
> 
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: EVP_MAC_init() in 3.0 alpha 13

[Hal Murray]

> Did you attempt to pass NULL for the key and zero for it's length to the
> EVP_MAC_init() call? 

Yes.

We can do better.  If we have to use dup/free, we can move the EVP_MAC_init() 
to before the dup, out of the timing path.

My model is that initialization is 2 parts.  The first is turning the key into 
a big table.  The second is initializing a small amount of state that is 
whatever is needed/updated by EVP_MAC_update().

I was hoping that EVP_MAC_init() with NULL key would bypass the first step and 
do the second.

If the second step involves a lot of computation we get into the space/time 
tradeoff of computing it during step one and saving it in case EVP_MAC_init is 
called with NULL key.

If there was a copy operation we could use it instead of dup/free.

Where is the code that does the key setup?  I expect it will be obvious after 
I see it, but I don't know my way around that linkage yet.  I'm using the 
default AES-128-CBC.

-

I don't think I've said it explicitly, but thanks for the change to the API 
for EVP_MAC_init()

--

Should PKEY be a potentially interesting approach for something like this?  I 
think it was suggested months ago.  One advantage is that the code works with 
1.1.1.

It's horribly slow in 3.0

alpha14:
0.777 CMAC
7.533 PKEY
3.323 PKEY preload
0.392 EVP_MAC
0.308 EVP_MAC Preload with dup+free
0.102 EVP_MAC Preload (no dup, wrong answer)

1.1.1k:
0.285 CMAC
0.550 PKEY
0.196 PKEY preload



-- 
These are my opinions.  I hate spam.

PKCS7_decrypt vs RSA OAEP padding

[Michal Moravec]

Hello,

I am a system administrator trying to integrate two pieces of software using 
the SCEP protocol (more on that later in the More Context section) .
Integration was working but one side (SaaS product) changed the algorithms it 
uses for signing and encryption within the PKCS7 message.
After that I am unable to decrypt the PKCS7 messages on my end and get the 
error: "ERROR 139701710696896:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:597:
message_static_functions.c:221: decryption failed"

>From my current state of investigation it looks highly likely there is a 
>problem with PKCS7_decrypt method which might be unable decrypt the PKCS7/CMS 
>payload if the RSA is used together with OAEP padding.

1. What is a diffrences between pkcs7 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7
 and CMS 
https://github.com/openssl/openssl/tree/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/cms
 implementations?

If I understand correctly CMS is just newer name for PKCS7 adopted by newer 
RFCs?
Do these two implementations overlap?
Or are there some kind of major diffrence like PKCS7 module being there for 
compatibility with older code and CMS is basically replacement to use for the 
future?

2. Is PKCS7_decrypt method in 
https://github.com/openssl/openssl/blob/681618cfc18b4f01f2c07e823308d30f6f47504b/crypto/pkcs7/pk7_smime.c
 capable of decrypting the PKCS7 payload whebf OAEP padding is used together 
with RSA to encrypt it? If it is indeed not capable of doing that would it be a 
bug or desired behavior?

If found a few pointers:

- 
https://stackoverflow.com/questions/56941480/how-to-set-padding-oaep-for-pkcs7-decrypt-function-using-openssl
 <- Developer is unable to use PKCS7_decrypt with RSA OAEP and forced to switch 
to CMS_decrypt method.
- 
https://stackoverflow.com/questions/34304570/how-to-resolve-the-evp-decryptfinal-ex-bad-decrypt-during-file-decryption
 <- Padding being a source problem of EVP_DecryptFinal_ex:bad decrypt error 
message.

3. How to replace PKCS7_decrypt method CMS_decrypt as easily as possible?

I have no hard proof of the PKCS7_decrypt being the culprit here so I started 
working on simple C program to reproduce the issue.
Problem is my C skills are very rusty and I have no experience working with 
OpenSSL C library.

int PKCS7_decrypt(PKCS7 *p7,EVP_PKEY *pkey, X509 *cert, BIO 
*data,  int flags);
int CMS_decrypt(CMS_ContentInfo *cms, EVP_PKEY *pkey, X509 *cert, BIO 
*dcont, BIO *out, unsigned int flags);

Methods are very similiar but input data format it different. It there an 
easyway to convert PKCS7 struct into CMS_ContentInfo struct?

Original usage of PKCS7_decrypt here -> 
https://github.com/openxpki/libscep/blob/4067eae283ce0b3025d414e9d3b6af30def8c093/src/message_static_functions.c


# More Context

My goal is to obtain signed client certificate using the SCEP protocol.

SCEP server: OpenXPKI https://github.com/openxpki/openxpki (Perl) with libscep 
https://github.com/openxpki/libscep library (C). libscep used the OpenSSL.
SCEP client: VMware Workspace ONE UEM SaaS (WSO). Black box. From the error 
codes client produces I strongly suspect they use OpenSSL within .Net code.

Originally WSO SCEP client used these three algorithms for PKCS7 operation: 
SHA-1, RSA (PKCS 1.5 padding or no padding <- can't tell which) and 3DES-CBC.
They made some sort of change (unannouced) and since the last SaaS upgdate WSO 
client uses SHA-2 (256bit), RSA with OAEP padding and AES-256-CBC.
Compare the attached PKCS7 messages (libscep_wso*.p7b). I use 
https://lapo.it/asn1js to decode them easily.
After the change I am unable to decrypt the PKIOperation message on the server 
side.

I suspect the RSA with OAEP is the cause of the problem because using different 
client with SHA-256, AES-256-CBC and RSA decryption works without any problem 
(libscep_sscep_ok.p7b).

Best Regards,
Michal Moravec




libscep_wso_after_broken.p7b
Description: libscep_wso_after_broken.p7b


libscep_wso_before_ok.p7b
Description: libscep_wso_before_ok.p7b


libscep_sscep_ok.p7b
Description: libscep_sscep_ok.p7b

Fwd: Question about RSA key access mechanism

[Danis Ozdemir]

Hi all,

I hope all is good. My name is Danis Ozdemir, I'm a PhD student in Trinity
College (Ireland) and I'm studying computer security. I'm trying to
reproduce the meltdown attack as an effort to dive deep into the known
attack types with some specific scenarios and "trying to see whether
Meltdown could have been used against a web server making use of openssl
libraries, running on an old, non-patched Linux kernel" is one of them. *Please
notice that the intentions are purely academic here, rather than performing
a real attack.*

Before investigating a more realistic scenario, I started with an 'open
box' approach in which the openssl server process reveals the addresses of
the sub fields of its private key (The private key and the certificate used
below were created using the command 'openssl req -x509 -nodes -days 1000
-newkey rsa:2048 -keyout priv.pem -out cert.pem', so they are RSA based.
And I just used good, old printf in the function "ssl_set_pkey" in the file
"ssl/ssl_rsa.c"):

# *LD_LIBRARY_PATH=${PWD} ./apps/openssl s_server -accept 54321 -cert
my_keys/cert.pem -key my_keys/priv.pem -www*
Could not read params of DH parameters from my_keys/cert.pem
Using default temp DH parameters








*DANIS - ssl_set_pkey - c->pkeys[0].privatekey : 0x55e4f9f01670  -
 144Danis - ssl_set_pkey - pkey->keydata->n   : 0x55e4f9f13d50Danis -
ssl_set_pkey - pkey->keydata->e   : 0x55e4f9f131e0Danis - ssl_set_pkey
- pkey->keydata->d   : 0x55e4f9f05790Danis - ssl_set_pkey -
pkey->keydata->p   : 0x55e4f9f05670Danis - ssl_set_pkey -
pkey->keydata->q   : 0x55e4f9f058b0Danis - ssl_set_pkey -
pkey->keydata->dmp1: 0x55e4f9f18850Danis - ssl_set_pkey -
pkey->keydata->dmq1: 0x55e4f9f13800Danis - ssl_set_pkey -
pkey->keydata->iqmp: 0x55e4f9f13820*
ACCEPT

Once the server is up and running, I get the real address of the sub field
p using gdb:

# *ps -ef | grep -v grep | grep openssl*
adminq*1421*  1280  0 16:55 pts/100:00:00 ./apps/openssl s_server
-accept 54321 -cert my_keys/cert.pem -key my_keys/priv.pem -www
# *gdb*
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) *attach 1421*
Attaching to process 1421
Reading symbols from /home/adminq/Workspace/openssl/apps/openssl...(no
debugging symbols found)...done.
Reading symbols from /home/adminq/Workspace/openssl/libssl.so.3...(no
debugging symbols found)...done.
Reading symbols from /home/adminq/Workspace/openssl/libcrypto.so.3...(no
debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols
from
/usr/lib/debug/.build-id/d3/583c742dd47aaa860c5ae0c0c5bdbcd2d54f61.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading
symbols from
/usr/lib/debug/.build-id/e9/1114987a0147bd050addbd591eb8994b29f4b3.debug...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from
/usr/lib/debug/.build-id/18/b9a9a8c523e5cfe5b5d946d605d09242f09798.debug...done.
done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug/.build-id/f2/5dfd7b95be4ba386fd71080accae8c0732b711.debug...done.
done.
0x7efd06acd631 in __libc_accept (fd=4, addr=..., len=0x7ffca292907c) at
../sysdeps/unix/sysv/linux/accept.c:26
26 ../sysdeps/unix/sysv/linux/accept.c: No such file or directory.
(gdb) *x/6x 0x55e4f9f05670*
0x55e4f9f05670: *0xf9f06b70 0x55e4* *0x0010* 0x0010
0x55e4f9f05680: 0x 0x000d
(gdb) *watch * (unsigned long *) 0x55e4f9f06b70*
Hardware watchpoint 1: * (unsigned long *) 0x55e4f9f06b70
(gdb) c
Continuing.

So, this output tells me that the content of p starts from the address
*0x55e4f9f06b70* and it's length is 16*sizeof(unsigned long) bytes as p is
of type bignum_st which has the following layout:

*struct bignum_st {*
* BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit*
* * chunks. */*
* int top; /* Index of last used d +1. */*
* /* The next are internal book keeping for bn_expand. */*
* int dmax; /* Size of the d array. */*
* int neg; /* one if the number is negative */*
* int flags;*
*};*

When I define a watchpoint for that address to verify that it has been
accessed when a new client connects to the server