Hope, you are referring to
https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html
Use PEM_read_bio_PUBKEY to get EVP_PKEY.
eng is for engine reference. If you have no engine, it can be NULL.
Thanks,
Thulasi.
On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar
wrote:
> Dear Openssl
Dear Openssl team,
While migrating from 1.0.2 to 3.0 we observe that
RSA_public_decrypt() API been deprecated in 3.0.
We referred the example provided in man page but we are not clear in generating
the initial ‘key’ required to create CTX.
Please suggest on (key , eng) params to
"Reality" ought not be defined this way.
On 29/01/2021 02:38, Jakob Bohm via openssl-users wrote:
If only one or a few parsers are broken, they need to be fixed.
If many broken parsers have proliferated due to generators
semi-violating DER by not omitting the empty field, that has become the
If only one or a few parsers are broken, they need to be fixed.
If many broken parsers have proliferated due to generators
semi-violating DER by not omitting the empty field, that has become the
new reality that generators must deal with.
PKIX arbitrarily limiting serial numbers to 159 bits has
“OPTIONAL” means the parser must deal with complete absence, not only encoded
as ASN.1 NULL.
Broken parsers should be fixed.
--
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
Also note that the official ASN.1 declaration for
AlgorithmIdentifier (from X.509 (2012), section 7.2) marks
the parameters field as OPTIONAL, so parsers really should
accept its absence.
However if broken parsers are common (this thread
only found one such parser), maybe it would be
good
On Fri, Jan 29, 2021 at 12:37:18AM +0530, Thulasi Goriparthi wrote:
> I am trying to provide a test certificate generated by
> openssl-3.0.0-alpha10 to a third party certificate parser/manager.
> This software expects AlgorithmIdentifier to either have parameters or
> to have null encoded (05 00)
RFC 4055 says:
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-224 is:
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-256 is:
I am trying to provide a test certificate generated by
openssl-3.0.0-alpha10 to a third party certificate parser/manager. This
software expects AlgorithmIdentifier to either have parameters or to have
null encoded (05 00) parameters which seems to be missing in the
certificate.
Certificate
Hi, I have experience with python but absolutely none with c/c++ so any
help would be greatly appreciated!
I am running python 3.9.1 for windows 10 (x64). I have noticed the openssl
dll files shipped with python (libcrypto-1_1.dll & libssl-1_1.dll) are only
version 1.1.7. I would therefore like
Hi,
I keep seeing growth in memory usage.. suspecting a leak. Want to disable
reference counting as well as stop caches so that i can isolate the issue.
It's all happening on client side. I will try disabling cache..
Mean while if any other inputs/pointers would be helpful.
-thanks
harish
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
OpenSSL version 3.0 alpha 11 released
=
OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/
OpenSSL 3.0 is currently in alpha.
OpenSSL 3.0 alpha 11 has now been made
Of course OpenSSL 3.0 will support a strict FIPS mode and this will be
the recommended set up. By setting the default query to "fips=yes" or
(better) setting up a library context that has no non-FIPS cryptographic
implementations and you are in a strictly compliant FIPS mode.
If you want to
If that is a hypothetical context, what context is the official design
goal of the OpenSSL Foundation for their validation effort?
On 2021-01-28 11:26, Tomas Mraz wrote:
This is a purely hypothetical context. Besides, as I said below - the
PKCS12KDF should not be used with modern PKCS12 files.
This is a purely hypothetical context. Besides, as I said below - the
PKCS12KDF should not be used with modern PKCS12 files. Because it can
be used only with obsolete encryption algorithms anyway - the best one
being 3DES for the encryption and SHA1 for the KDF.
Tomas
On Thu, 2021-01-28 at 11:08
If the context does not limit the use of higher level compositions, then
OpenSSL 3.0 provides no way to satisfy the usual requirement that a
product can be set into "FIPS mode" and not invoke the non-validated
lower level algorithms in the "default" provider.
The usual context is to "sell"
There is unfortunately no simple straightforward answer to this
question. It really depends on the context.
Anyway OpenSSL 3.0 gives you all the flexibility needed.
Tomas
On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
> Does FIPS 140 or the related legal requirements
Does FIPS 140 or the related legal requirements limit the use of higher
level compositions such as PKCS12KDF, when using only validated
cryptography for the underlying operations?
On 2021-01-28 09:36, Tomas Mraz wrote:
I do not get how you came to this conclusion. The "true" FIPS mode can
be
On 28/01/2021 08:26, Jakob Bohm via openssl-users wrote:
> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode" where
> all the non-FIPS algorithms are disabled, but the FIPS-independent
> schemes/protocols in the "default" provider remains available?
>
> Remember that in other
I do not get how you came to this conclusion. The "true" FIPS mode can
be easily achieved with OpenSSL 3.0 - either by loading just the fips
and base provider, or by loading both default and fips providers but
using the "fips=yes" default property (without the "?").
The PKCS12KDF does not work
Does that mean that OpenSSL 3.0 will not have a true "FIPS mode" where
all the non-FIPS algorithms are disabled, but the FIPS-independent
schemes/protocols in the "default" provider remains available?
Remember that in other software systems, such as OpenSSL 1.0.x and MS
CryptoAPI, FIPS mode
21 matches
Mail list logo
