Re: Help with i2d_CMS_bio_stream from OpenSSL 1.0 to OpenSSL 1.1.1j

Hi, no one have some hints? Il giorno gio 8 apr 2021 alle ore 10:53 Fabio ha scritto: > Hi all, > I have a problem upgrading my code from openssl 1.0 to the last 1.1.1j. > Using an older version, I exported the CMS code in order to extend and > modify some calculations. I used i2d_CMS_bio_stream

Re: error: redefinition of ‘struct rsa_meth_st’

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’" *duri

FW: Strange warnings while linking to openssl version 1.1.1k

> 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

Re: Strange warnings while linking to openssl version 1.1.1k

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 function

Strange warnings while linking to openssl version 1.1.1k

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): w

Re: EVP_MAC_init() in 3.0 alpha 13

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 an

Re: error: redefinition of ‘struct rsa_meth_st’

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/

Re: PKCS7_decrypt vs RSA OAEP padding

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

Re: error: redefinition of ‘struct rsa_meth_st’

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.

Re: error: redefinition of ‘struct rsa_meth_st’

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.

Re: PEM_read_bio_RSAPublicKey equivalent API which returns EVP_PKEY

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 functio

Re: error: redefinition of ‘struct rsa_meth_st’

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 shoul

Re: EVP_MAC_init() in 3.0 alpha 13

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

Re: EVP_MAC_init() in 3.0 alpha 13

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

PKCS7_decrypt vs RSA OAEP padding

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 t

Fwd: Question about RSA key access mechanism

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 Meltdow