Re: [External] : Re: BIO_read() crash
On Mon, 2022-12-05 at 16:14 -0800, Benjamin Kaduk via openssl-users
wrote:
> On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote:
> > Why does EVP_get_digestbyname("md4") return non-NULL if the legacy
> > provider
> > isn't loaded? Similarly, why does it return non-NULL for "md5"
> > after doing
> > EVP_set_default_properties(NULL, "fips=yes")? This seems
> > unintuitive. Legacy
> > code that does not know about EVP_MD_fetch() checks the return
> > value of
> > EVP_get_digestbyname(). Isn't that where the error should be
> > detected? Why
> > let it get all the way to BIO_set_md() (or EVP_DigestInit() or
> > whatever)
> > before the error is detected?
>
> To do so would introduce a time-of-check/time-of-use race, as the set
> of
> providers available may change in the intervening period.
Not just that. IMO the primary motivation was to keep the digests (and
similarly ciphers) returned by the EVP_md4() (and similar) or
EVP_get_digestbyname() calls still constant. I.e., they would not
change based on the providers involved, etc. This implied the implicit
fetching done inside the EVP_DigestInit() and similar init routines.
As any correct code required checking result of EVP_DigestInit() and
thus also the result of BIO_set_md(), it was the least of all evils in
how to implement these legacy EVP_MD functions returning constant
EVP_MDs.
--
Tomáš Mráz, OpenSSL
Re: BIO_read() crash
Hi,
there is an error in your code - see my comment below.
On Mon, 2022-12-05 at 08:45 +, Zhongyan Wang wrote:
...
> md = EVP_get_digestbyname(dgst);
> if (!md) {
> printf("Error EVP_get_digestbyname %s\n", dgst);
> goto err_exit;
> }
>
> in = BIO_new_file(datain, "rb");
> if (!in) {
> printf("Error BIO_new_file %s\n", datain);
> goto err_exit;
> }
>
> out = BIO_new(BIO_s_mem());
> if (!out) {
> printf("Error BIO_new out\n");
> goto err_exit;
> }
>
> rbio = in;
>
> bmd = BIO_new(BIO_f_md());
> if (!bmd){
> printf("Error BIO_new bmd\n");
> goto err_exit;
> }
>
> BIO_set_md(bmd, md);
You do not check the return value here. This call will return <= 0
return value in case the legacy provider is not loaded.
--
Tomáš Mráz, OpenSSL
Re: OpenSSL version 3.1.0-alpha1 published
That is the master branch CHANGES.md. It will be synced later. For the 3.1 changes please look at the CHANGES.md in the openssl-3.1 branch and/or inside the alpha tarball. Tomas On Thu, 2022-12-01 at 15:15 +, Kenneth Goldman wrote: > The changes show a jump from 3.0 to 3.2 > > https://github.com/openssl/openssl/blob/master/CHANGES.md > -- Tomáš Mráz, OpenSSL
Re: OpenSSL version 3.1.0-alpha1 published
Hmm, good point. Though when migrating from 1.1.1 the 3.0 guide still applies and migration from 3.0 to 3.1 should be just seamless. Tomas On Thu, 2022-12-01 at 09:40 -0500, Felipe Gasper wrote: > AFAICT, the migration guide doesn’t actually seem to mention upgrades > to 3.1. > > -FG > > > > On Dec 1, 2022, at 09:00, OpenSSL wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > > > OpenSSL version 3.1 alpha 1 released > > > > > > OpenSSL - The Open Source toolkit for SSL/TLS > > https://www.openssl.org/ > > > > OpenSSL 3.1 is currently in alpha. > > > > OpenSSL 3.1 alpha 1 has now been made available. > > > > Note: This OpenSSL pre-release has been provided for testing > > ONLY. > > It should NOT be used for security critical purposes. > > > > Specific notes on upgrading to OpenSSL 3.1 from previous versions > > are > > available in the OpenSSL Migration Guide, here: > > > > > > https://www.openssl.org/docs/man3.0/man7/migration_guide.html > > > > The alpha release is available for download via HTTPS and FTP > > from the > > following master locations (you can find the various FTP mirrors > > under > > https://www.openssl.org/source/mirror.html): > > > > * https://www.openssl.org/source/ > > * ftp://ftp.openssl.org/source/ > > > > The distribution file name is: > > > > o openssl-3.1.0-alpha1.tar.gz > > Size: 15343477 > > SHA1 checksum: 91a7cbcb761c4bb8a460899bccddcbd5d047d3c3 > > SHA256 checksum: > > ef10f70023f4e3f701c434db0b4b0c8cfea1e1e473a0eb3c9ccbc5c54f5f5566 > > > > The checksums were calculated using the following commands: > > > > openssl sha1 openssl-3.1.0-alpha1.tar.gz > > openssl sha256 openssl-3.1.0-alpha1.tar.gz > > > > Please download and check this alpha release as soon as possible. > > To report a bug, open an issue on GitHub: > > > > https://github.com/openssl/openssl/issues > > > > Please check the release notes and mailing lists to avoid > > duplicate > > reports of known issues. (Of course, the source is also available > > on GitHub.) > > > > Yours, > > > > The OpenSSL Project Team. > > > > -BEGIN PGP SIGNATURE- > > > > iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmOIqpASHHRvbWFzQG9w > > ZW5zc2wub3JnAAoJEFJ0ZqIcp55tWrIQAJHT40JekEs3DacHjQrTmGLc56TmzaFD > > oDp8Md2E0RpX/vuANdIVGB89zGQMag13TPa9CzT1yk7wFBilPoiuapolmo8N0nvF > > OnMLIQjF+sbsQN0gqchuMKKD98omc1ZNNcijq/GlKM9wH6ey1uHnFAi2aXF4f6ai > > 2SviauJvHQDgDOe9tFfA5lDF1EdYZt20D46Yc+yJf/zr4MJZFcX2T2qmo+oew6VA > > djZ+cRPeeNmRXrl5Banqpfcy2iH4N57wvEcM4dtGaGY+4Pwr0H9XN6MxfamGUbLv > > oSySdFpTagPENPGDBPoRilPSXdapCD5m8Xd2FERM1HF5E1GaemqaQKUYiXbANqL/ > > SDBftayilhYf+tXg3/22xksZVEkEjFD79M0mj75dn+UgQilOTR/AOdup2imTB7PG > > 7Cgq2HGz93ppO3kG0iuTS5uc95Gfu9AfkjgfcydA2eZf+rmHAoocm8kpThdxD/a5 > > avpMudgklyXysmO+2MJ16806Sa27L8N52YTPzy4Zthx/SLR/RA//bXBnlSlguRGw > > 7+hIDPncmaCfegaI65yq/TgtU9z/OLhNTPmYaUQi3IFtsCrAahZNVYg8qZtnMtgC > > iaVYQkNZsqE0wSDalgJANJkZUa8VHdh2O3sOBSYbZvHWEiYJJ+9ATgLSLDjiGq0e > > l9cvtybysQsx > > =upN5 > > -END PGP SIGNATURE- > > -- Tomáš Mráz, OpenSSL
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On Fri, 2022-11-11 at 16:01 +0100, Jakob Bohm via openssl-users wrote: > On 2022-11-06 23:14, raf via openssl-users wrote: > > On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik > > wrote: > > > > > > From: openssl-users On > > > > Behalf Of raf via > > > > openssl-users > > > > Sent: Friday, 4 November, 2022 18:54 > > > > > > > > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via > > > > openssl-users > > > > wrote: > > > > > > > > > I'm inclined to agree. While there's an argument for backward > > > > > compatibility, > > > > > C99 was standardized nearly a quarter of a century ago. > > > > > OpenSSL 1.x is > > > > > younger than C99. It doesn't seem like an unreasonable > > > > > requirement. > > > > Would this be a choice between backwards-compatibility with C90 > > > > compilers and compatibility with 32-bit architectures? > > > I don't see how. > > > > > > It's a question of the C implementation, not the underlying > > > architecture. A C implementation for a 32-bit system can > > > certainly > > > provide a 64-bit integer type. If that C implementation conforms > > > to > > > C99 or later, it ought to do so using long long and unsigned long > > > long. (I'm excluding C implementations for exotic systems where, > > > for > > > example, CHAR_BIT != 8, such as some DSPs; those aren't going to > > > be > > > viable targets for OpenSSL anyway.) > > > > > > > Is there another way to get 64-bit integers on 32-bit systems? > > > Sure. There's a standard one, which is to include and > > > use int64_t and uint64_t. That also requires C99 or later and an > > > implementation which provides those types; they're not required. > > Sorry. I assumed that it was clear from context that I was only > > thinking about C90-compliant 64-bit integers on 32-bit systems. > > > > > And for some implementations there are implementation-specific > > > extensions, which by definition are not standard. > > > > > > And you can roll your own. In a non-OO language like C, this > > > would > > > be intrusive for the parts of the source base that rely on a 64- > > > bit > > > integer type. > > > > > > > I suspect that that there are more 32-bit systems than there > > > > are > > > > C90 compilers. > > > Perhaps, but I don't think it's relevant here. In any case, > > > OpenSSL is > > > not in the business of supporting every platform and C > > > implementation > > > in existence. There are the platforms supported by the project, > > > and > > > there are contributed platforms which are included in the code > > > base > > > and supported by the community (hopefully), and there are > > > unsupported > > > platforms. > > > > > > If someone wants OpenSSL on an unsupported platform, then it's up > > > to > > > them to do the work. > > So it sounds like C90 is now officially unsupported. > > I got the impression that, before this thread, it was believed > > that C90 was supported, and the suggestion of a pull request > > indicated a willingness to retain/return support for C90. > > Perhaps it just indicated a willingness to accept community > > support for it. > > > > I'd be amazed if anyone could actually still be using a > > 30 year old C90 compiler, rather than a compiler that > > just gives warnings about C90. :-) > > > Regarding C90 compilers, it is important to realize that some system > vendors kept providing (arbitrarily extended) C90 compiler long after > 1999. Microsoft is one example, with many of their system compilers > for "older" OS versions being based on Microsoft's C90 compilers. > These compilers did not provide a good stdint.h, but might be > coached > to load a porter provided stdint.h that maps int64_t and uint64_t to > their vendor specific C90 extensions (named __int64 and unsigned > __int64). > > Even worse, I seem to recall at least one of those compilers > miscompiling > 64 bit integer arithmetic, but working acceptably with the older > OpenSSL > 1.0.x library implementations of stuff like bignums (BN) and various > pure > C algorithm implementations in OpenSSL 1.0.x, that happened to do > everything > by means of 32 and 16 bit types. > > As part of our company business is to provide software for the > affected > "older" systems, thus desiring the ability to compile OpenSSL 3.x > with > options indicating "compiler has no good integral types larger than > uint32_t, floating point is also problematic" > > Other major vendors with somewhat old C compilers include a few > embedded > platforms such as older ARM and MIPS chips that were mass produced in > vast quantities. > > Performance wise, using a newer compiler that implements int64_t etc. > via > frequent library calls, while technically correct, is going to run > unnecessarily slow compared to having algorithms that actually use > the > optimal integral sizes for the hardware/compiler combination. > > I seem to recall using at least one bignum library (not sure if > OpenSSL > or not) that could be configured to use
Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Red Hat backports security fixes to older versions so if you keep your RHEL installation up-to-date with 'yum update' you should not need to install newer upstream releases on the system. Regards, Tomas Mraz On Tue, 2022-11-08 at 08:51 +0100, Matthias Apitz wrote: > El día martes, noviembre 08, 2022 a las 08:26:54a. m. +0100, Tomas > Mraz escribió: > > > Hi, > > > > Red Hat patches its OpenSSL implementation with some additional API > > calls. That means you cannot use builds from an unpatched upstream > > OpenSSL tarball in place of the system libcrypto and libssl > > libraries. > > > > The proper way is to always obtain updated system packages from > > your > > vendor, i.e., Red Hat. Otherwise you would have to try to update > > the > > source rpm package from RHEL with new openssl version keeping the > > patches that Red Hat adds to it. That is definitely not a trivial > > endeavour. > > > > If, for some reason, you need newer OpenSSL package for some > > particular > > application that you install to the system, it should be possible > > to > > keep the system openssl package untouched, install the upstream > > OpenSSL > > package somewhere into /opt or /usr/local, and link that > > application > > against this installation of OpenSSL. > > > > The primary question to ask is - why do you need to install > > openssl 1.1.1l on RHEL-8.6? > > > > Tomas Mraz, OpenSSL > > Thanks for your answer and explanation. We updated all our server on > SuSE > Linux SLES and RedHat to openssl 1.1.1l due to an announced security > problem (do > not remember the CVE, perhaps you will know better). The RH 8.6 > server > has: > > # /usr/bin/openssl version > OpenSSL 1.1.1k FIPS 25 Mar 2021 > > we use: > > # /usr/local/sisis-pap/bin/openssl version > OpenSSL 1.1.1l 24 Aug 2021 > > and have linked all our application servers agains this version. > > matthias > > -- Tomáš Mráz, OpenSSL
Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Hi, Red Hat patches its OpenSSL implementation with some additional API calls. That means you cannot use builds from an unpatched upstream OpenSSL tarball in place of the system libcrypto and libssl libraries. The proper way is to always obtain updated system packages from your vendor, i.e., Red Hat. Otherwise you would have to try to update the source rpm package from RHEL with new openssl version keeping the patches that Red Hat adds to it. That is definitely not a trivial endeavour. If, for some reason, you need newer OpenSSL package for some particular application that you install to the system, it should be possible to keep the system openssl package untouched, install the upstream OpenSSL package somewhere into /opt or /usr/local, and link that application against this installation of OpenSSL. The primary question to ask is - why do you need to install openssl 1.1.1l on RHEL-8.6? Tomas Mraz, OpenSSL On Tue, 2022-11-08 at 07:17 +0100, Matthias Apitz wrote: > > Hello, > > We compile openssl 1.1.1l from the sources and run on RedHat 8.6 into > the > problem that the system shared lib /usr/lib64/libk5crypto.so.3 misses > a > symbol from openssl: > > # objdump -TC /usr/lib64/libk5crypto.so.3 | grep EVP_KDF > DF *UND* OPENSSL_1_1_1b > EVP_KDF_ctrl > DF *UND* OPENSSL_1_1_1b > EVP_KDF_CTX_new_id > DF *UND* OPENSSL_1_1_1b > EVP_KDF_CTX_free > DF *UND* OPENSSL_1_1_1b > EVP_KDF_derive > > # objdump -TC libssl.so.1.1 | grep EVP_KDF > (nix) > > I checked also the sources 1.1.1l and 1.1.1s, there are a lot of > 'EVP_*' > symbols, but not EVP_KDF_ctrl. > > What is the correct way to fix this. Thanks in advance. > > matthias > -- Tomáš Mráz, OpenSSL
Re: CVE-2022-3602 and CVE-2022-3786 Critical OpenSSL 3.0.x security vulnerabilities
In general unless you've built and installed your own build of OpenSSL you need to refer to the vendor of your operating system for patches. In particular the openssl packages in CentOS 7.9 are not affected given they are 1.0.2 version and not 3.0.x version. Tomas Mraz, OpenSSL On Wed, 2022-11-02 at 17:48 +1100, Turritopsis Dohrnii Teo En Ming wrote: > Subject: CVE-2022-3602 and CVE-2022-3786 Critical OpenSSL 3.0.x > security vulnerabilities > > Good day from Singapore, > > I refer to the following posts. > > [1] OpenSSL Gives Heads Up to Critical Vulnerability Disclosure, > Check Point Alerts Organizations to Prepare Now > Link: > https://blog.checkpoint.com/2022/10/30/openssl-gives-heads-up-to-critical-vulnerability-disclosure-check-point-alerts-organizations-to-prepare-now/ > > [2] 2022 OpenSSL vulnerability - CVE-2022-3602 - Spooky SSL > Link: https://github.com/NCSC-NL/OpenSSL-2022 > > [3] VMware Response to CVE-2022-3602 and CVE-2022-3786: > vulnerabilities in OpenSSL 3.0.x > Link: > https://blogs.vmware.com/security/2022/11/vmware-response-to-cve-2022-3602-and-cve-2022-3786-vulnerabilities-in-openssl-3-0-x.html > > I have 2 internet-facing CentOS 7.9 Linux servers in Europe. > > Are the patches available already? How do I patch OpenSSL on my > CentOS 7.9 Linux servers? > > Thank you. > > Regards, > > Mr. Turritopsis Dohrnii Teo En Ming > Targeted Individual in Singapore > Blogs: > https://tdtemcerts.blogspot.com > https://tdtemcerts.wordpress.com -- Tomáš Mráz, OpenSSL
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
No, long long and unsigned long long is required and it was required for quite some time. The code is mostly C90 but not strictly. I suppose on platforms with 64bit long type we could make it work without long long though. Pull requests are welcome. Tomas Mraz, OpenSSL On Tue, 2022-11-01 at 22:52 +, Dennis Clarke via openssl-users wrote: > > Good day : > > This always bites me when I try strict C90 : > > In file included from include/openssl/x509.h:41, > from apps/include/apps.h:29, > from apps/lib/app_libctx.c:10: > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:110:5: note: in expansion of macro 'SHA_LONG64' > 110 | SHA_LONG64 h[8]; > | ^~ > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:111:5: note: in expansion of macro 'SHA_LONG64' > 111 | SHA_LONG64 Nl, Nh; > | ^~ > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:113:9: note: in expansion of macro 'SHA_LONG64' > 113 | SHA_LONG64 d[SHA_LBLOCK]; > | ^~ > gmake[1]: *** [Makefile:3989: apps/lib/libapps-lib-app_libctx.o] > Error 1 > gmake[1]: Leaving directory '/opt/bw/build/openssl- > 3.0.7_debian_ppc64.002' > make: *** [Makefile:2958: build_sw] Error 2 > > > etc etc ... > > I can just as neatly go to C11 or some such but I thought the whole > code > base was C90 clean ? At least it was. > > > > -- Tomáš Mráz, OpenSSL
Re: PGP key
Hi Mike, the signing key is a sub key of the key listed on this web site: https://www.openssl.org/community/otc.html The primary key fingerprint is also mentioned at https://github.com/openssl/openssl/blob/master/doc/fingerprints.txt Regards, Tomas Mraz, OpenSSL On Tue, 2022-11-01 at 18:14 +, Mike Banahan wrote: > Hi Tomas - I received information today abut the buffer overflow fix, > signed with what I believe is your PGP key. > > There is no mention of your key on the OpenSSL website, I eventually > found it on a keyserver. > > I realize that this is not the most important thing in the world, but > I > think it would help the verification process if the public key was > easily visible on the website! > > Many thanks for all your work, which is most appreciated. > > Best wishes, > > Mike Banahan > -- Tomáš Mráz, OpenSSL
Re: CVE-2022-37454 SHA-3 buffer overflow
The implementation of SHA-3 in OpenSSL is different from the vulnerable one. There is a plain C implementation and also assembly implementation for various CPU architectures. See crypto/sha/keccak1600.c and crypto/sha/asm/keccak1600*.pl. None of these should suffer from the CVE-2022-37454. The SHA3 low level implementation is used at various places. For example there is also the SHAKE XOF hash function implementation which uses the low level SHA3 routines. There is also an implementation of the original Keccak algorithm in the master branch. Tomas Mraz, OpenSSL On Fri, 2022-10-21 at 11:33 -0700, Job Cacka wrote: > I was reading that SHA-3 has a buffer overflow in the C > implementation that is used by PHP and Python. > https://nvd.nist.gov/vuln/detail/CVE-2022-37454 > https://mouha.be/sha-3-buffer-overflow/ > > How does OpenSSL implement SHA-3 in the following algorithms? Is SHA3 > only used in SHA3-224, SHA3-256, SHA3-384, and SHA3-512? > > root:/ openssl list -digest-algorithms > RSA-MD4 => MD4 > RSA-MD5 => MD5 > RSA-MDC2 => MDC2 > RSA-RIPEMD160 => RIPEMD160 > RSA-SHA1 => SHA1 > RSA-SHA1-2 => RSA-SHA1 > RSA-SHA224 => SHA224 > RSA-SHA256 => SHA256 > RSA-SHA3-224 => SHA3-224 > RSA-SHA3-256 => SHA3-256 > RSA-SHA3-384 => SHA3-384 > RSA-SHA3-512 => SHA3-512 > RSA-SHA384 => SHA384 > RSA-SHA512 => SHA512 > RSA-SHA512/224 => SHA512-224 > RSA-SHA512/256 => SHA512-256 > RSA-SM3 => SM3 > BLAKE2b512 > BLAKE2s256 > id-rsassa-pkcs1-v1_5-with-sha3-224 => SHA3-224 > id-rsassa-pkcs1-v1_5-with-sha3-256 => SHA3-256 > id-rsassa-pkcs1-v1_5-with-sha3-384 => SHA3-384 > id-rsassa-pkcs1-v1_5-with-sha3-512 => SHA3-512 > MD4 > md4WithRSAEncryption => MD4 > MD5 > MD5-SHA1 > md5WithRSAEncryption => MD5 > MDC2 > mdc2WithRSA => MDC2 > ripemd => RIPEMD160 > RIPEMD160 > ripemd160WithRSA => RIPEMD160 > rmd160 => RIPEMD160 > SHA1 > sha1WithRSAEncryption => SHA1 > SHA224 > sha224WithRSAEncryption => SHA224 > SHA256 > sha256WithRSAEncryption => SHA256 > SHA3-224 > SHA3-256 > SHA3-384 > SHA3-512 > SHA384 > sha384WithRSAEncryption => SHA384 > SHA512 > SHA512-224 > sha512-224WithRSAEncryption => SHA512-224 > SHA512-256 > sha512-256WithRSAEncryption => SHA512-256 > sha512WithRSAEncryption => SHA512 > SHAKE128 > SHAKE256 > SM3 > sm3WithRSAEncryption => SM3 > ssl3-md5 => MD5 > ssl3-sha1 => SHA1 > whirlpool > > > Thanks, > Job > -- Tomáš Mráz, OpenSSL
Re: OpenSSL 3 ECC Key use question
What do you need the NID for? Maybe the code could be changed to use
names instead of NIDs? The NIDs are somehow legacy thing that might
eventually be completely internal at some point.
However, if you need the NID, you should be able to use OBJ_sn2nid() to
obtain the NID if the curve name is in the object database.
Tomas Mraz
On Sun, 2022-10-23 at 13:46 -0400, Martin via openssl-users wrote:
> Hi,
>
> How can I get the nid from the curve name for a EC key in OpenSSL 3?
> I’m porting code from OpenSSL 1.0.2.
>
> I’m converting this:
>
> ecc_curve_type = EC_GROUP_get_curve_name(EC_KEY_get0_group((const
> EC_KEY *)eckey));
> if(ecc_curve_type == NID_undef)
> {
>
> to
>
> EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME,
> curve_name, sizeof(curve_name), _len);
> ecc_curve_type = ossl_ec_curve_name2nid(curve_name);
>
> but ossl_ec_curve_name2nid() is internal and it is not defined in
> /include/openssl/ec.h but in /include/crypto/ec.h
>
> Thanks,
>
> Martin
--
Tomáš Mráz, OpenSSL
Re: libproviders.so file not found
This looks like you're actually trying to use the config file for OpenSSL-3.0 with OpenSSL-1.1.1 which does not understand the providers module and tries to load it as a conf shared library module. I'd suggest using different --openssldir= when configuring the openssl- 3.0 build if you need both openssl-3.0 and openssl-1.1.1 in your system. Tomas Mraz On Thu, 2022-10-20 at 05:26 +, Gahlot, Ashish Kumar wrote: > Hi everyone, > > I'm trying to enable fips provider in openssl3 by writing the > following lines into openssl.cnf file: > > openssl_conf = openssl_init > > .include fipsmodule.cnf > > [openssl_init] > providers = provider_sect > > [provider_sect] > fips = fips_sect > base = base_sect > > [base_sect] > activate = 1 > > Now when it is enabled, there is an error in syslog that > libproviders.so file not found: > > DSO support routines:dlfcn_load:could not load the shared > library:crypto/dso/dso_dlfcn.c:118:filename(libproviders.so): > libproviders.so: cannot open shared object file: No such file or > directory > 14066657192:error:25070067:DSO support routines:DSO_load:could > not load the shared library:crypto/dso/dso_lib.c:162: > 14066657192:error:0E07506E:configuration file > routines:module_load_dso:error loading > dso:crypto/conf/conf_mod.c:224:module=providers, path=providers > 14066657192:error:0E076071:configuration file > routines:module_run:unknown module > name:crypto/conf/conf_mod.c:165:module=providers > > And this seems to be a common issue in openssl3. I have seen > solutions like commenting outprovider_sect but I think I would need > it to enable fips provider. Is there any working solution for this? > > Thank you, > Ashish > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If > you are not the intended recipient, please notify the sender > immediately and then delete all copies, including any attachments. -- Tomáš Mráz, OpenSSL
Re: Secure Remote Password (SRP)
The SRP support will not be removed in 3.x releases. At the earliest it could be removed in 4.0 release. Whether there will be a replacement for the deprecated SRP APIs at that time we cannot currently say. So unless you absolutely require not using deprecated APIs you can still move to 3.x releases as the existing SRP API continues to be supported there. Tomas Mraz, OpenSSL On Mon, 2022-10-17 at 21:13 -0700, Norm Green wrote: > I'm also interested in the answer to these questions regarding SRP > in OpenSSL v3. > > Our project still uses OpenSSL v1.1.1 with plans to move to v3 next > year. > > However we use SRP extensively and will not be able to move to v3 if > SRP support is soon to be no longer available. > > Norm Green > GemTalk Systems LLC > > On 10/17/2022 2:49 PM, Rohit Khera [C] wrote: > > > I am trying to get information on versions and usage of the Secure > > Remote Password Protocol (SRP) APIs in OpenSSLv3. > > > > 1. Are SRPv3, v6, and/or v6a supported? > > > > 1. I found the following information in the OpenSSL documents on > > the following C API for SRP: SRP_create_verifier(), > > SRP_user_pwd_new(), SSL_CTX_set_srp_password() > > While the following documents the API : > > https://www.openssl.org/docs/man3.0/man3/SRP_VBASE_new.html > > Are there any examples of client and server programs that use these > > interfaces in order to register and authenticate a user? > > > > 1. The docs state that the APIs are deprecated - are new > > versions of the APIs planned or can we expect SRP functionality to > > be unavailable in future versions of OpenSSL? > > > > /R > > > > > -- Tomáš Mráz, OpenSSL
Re: CMAC not working
Could you please attach the diff from the original demo source for the changes you've done? Tomas On Thu, 2022-10-13 at 08:25 +, Fernando Elena Benavente wrote: > Hi Thomas, sorry for the screenshots, I will not send more > screenshots, sorry. > > I tried to initialize the data[] as u said (and as the same way in > the code of the demo with the Shakespeare text), but it still says : > > Generated MAC: > - 33 98 f8 a3 b9 47 af eb-19 e8 26 ff 34 4b 1e f8 > 3G&.4K.. > > Generated MAC does not match expected value > > C:\Users\TRFFEB\Desktop\PruebasOpenSSL\CryptoPruebas\x64\Debug\Consol > eApplication1.exe (process 9460) exited with code 1. > Press any key to close this window . . . > > So I suppose the demo code of the CMAC isn’t working properly, any > tips to make it work? > > Thank you for your time and help. > > -Fernando Elena Benavente. > > -Original Message- > From: Tomas Mraz > Sent: Wednesday, October 12, 2022 11:15 AM > To: Fernando Elena Benavente ; > openssl-users@openssl.org > Cc: Jorge Juan Tejero Fernández ; > Alberto Sendino Aragonés ; Esther > Marina Godoy Alves > Subject: Re: CMAC not working > > On Wed, 2022-10-12 at 11:02 +0200, Tomas Mraz wrote: > > On Tue, 2022-10-11 at 10:50 +, Fernando Elena Benavente wrote: > > > Hi guys, Im triying to use the EVP_MAC OpenSSL API with the > > > CMAC_AES256, I have been using some testing vectors I found on > > > github, but seems they doesn’t work on the CMAC of OpenSSl, as > > > the > > > expected output of the test vectors are different from the > > > OpenSSL > > > CMAC output. > > > > > > I attach a screenshot of the test vectors we are using, and how > > > we > > > are introducing it on our key and plaintext variables, the CMAC > > > code > > > is the demo code on OpenSSL github. > > > > > > > It is better not to use screenshots if possible and rather do > > copy to save mailbox space of all the recipients. > > > > Our demo is actually incorrect because the cipher name used should > > be > > 'AES-256-CBC' to produce a proper CMAC. > > Ahem... I am actually wrong, the demo is right although somewhat > misleading, because "aes256" (which is in the demo) is an alias for > "AES-256-CBC". > > Looking at the screenshots - you cannot use the hexadecimal value of > the input directly in the data[] as you do. You need to initialize > the data[] as an array similarly to how key is initialized. > > -- > Tomáš Mráz, OpenSSL > -- Tomáš Mráz, OpenSSL
Re: CMAC not working
On Wed, 2022-10-12 at 11:02 +0200, Tomas Mraz wrote: > On Tue, 2022-10-11 at 10:50 +, Fernando Elena Benavente wrote: > > Hi guys, Im triying to use the EVP_MAC OpenSSL API with the > > CMAC_AES256, I have been using some testing vectors I found on > > github, but seems they doesn’t work on the CMAC of OpenSSl, as the > > expected output of the test vectors are different from the OpenSSL > > CMAC output. > > > > I attach a screenshot of the test vectors we are using, and how we > > are introducing it on our key and plaintext variables, the CMAC > > code > > is the demo code on OpenSSL github. > > > > It is better not to use screenshots if possible and rather do > copy to save mailbox space of all the recipients. > > Our demo is actually incorrect because the cipher name used should be > 'AES-256-CBC' to produce a proper CMAC. Ahem... I am actually wrong, the demo is right although somewhat misleading, because "aes256" (which is in the demo) is an alias for "AES-256-CBC". Looking at the screenshots - you cannot use the hexadecimal value of the input directly in the data[] as you do. You need to initialize the data[] as an array similarly to how key is initialized. -- Tomáš Mráz, OpenSSL
Re: CMAC not working
On Tue, 2022-10-11 at 10:50 +, Fernando Elena Benavente wrote: > Hi guys, Im triying to use the EVP_MAC OpenSSL API with the > CMAC_AES256, I have been using some testing vectors I found on > github, but seems they doesn’t work on the CMAC of OpenSSl, as the > expected output of the test vectors are different from the OpenSSL > CMAC output. > > I attach a screenshot of the test vectors we are using, and how we > are introducing it on our key and plaintext variables, the CMAC code > is the demo code on OpenSSL github. > It is better not to use screenshots if possible and rather do copy to save mailbox space of all the recipients. Our demo is actually incorrect because the cipher name used should be 'AES-256-CBC' to produce a proper CMAC. -- Tomáš Mráz, OpenSSL
Re: RSA private key file created with Windows10
On Wed, 2022-10-05 at 16:35 +0900, Imazu Setsuo wrote: > Thank you immediately answer. > > PKCS8, PEM, and RFC4716 formats were created and tested with the ssh- > keygen command. > > PKCS8 and PEM formatting was successful. > > RFC4716 is the default on Windows10, and PEM is the default on > CentOS7. > > Does OpenSSL have any plans to support RFC4716 format in the future? No plans for that currently. Although OpenSSL-3.0 allows to plug in decoders in a separate provider so a third party support via a provider would be possible. > best regards, thank you > Setsuo Imazu > > On 2022/10/05 15:36, Tomas Mraz wrote: > > Hello, > > most probably the key is stored in the OpenSSH private key format. > > You'll need to use ssh-keygen -p -m PKCS8 to convert the key into a > > format that OpenSSL can read. > > > > Tomas Mraz, OpenSSL > > > > On Wed, 2022-10-05 at 15:00 +0900, Imazu Setsuo wrote: > > > Hello. > > > > > > When I read the RSA private key file created with the ssh-keygen > > > command that comes with Windows 10 with the PEM_read_PrivateKey() > > > function, the following error occurred. > > > > > > error: 0906D06C: lib(9): func(109): reason(108) > > > > > > The platform is CentOS7, OpenSSL 3.0.5. > > > Is the private key file created with Windows 10 not supported? > > > How can I use the private key file created in Windows 10 as well? > > > > > > > > > best regards, thank you > > > Setsuo Imazu > > -- Tomáš Mráz, OpenSSL
Re: RSA private key file created with Windows10
Hello, most probably the key is stored in the OpenSSH private key format. You'll need to use ssh-keygen -p -m PKCS8 to convert the key into a format that OpenSSL can read. Tomas Mraz, OpenSSL On Wed, 2022-10-05 at 15:00 +0900, Imazu Setsuo wrote: > Hello. > > When I read the RSA private key file created with the ssh-keygen > command that comes with Windows 10 with the PEM_read_PrivateKey() > function, the following error occurred. > > error: 0906D06C: lib(9): func(109): reason(108) > > The platform is CentOS7, OpenSSL 3.0.5. > Is the private key file created with Windows 10 not supported? > How can I use the private key file created in Windows 10 as well? > > > best regards, thank you > Setsuo Imazu -- Tomáš Mráz, OpenSSL
Re: BIO_flush Segmentation Fault Issue
Your analysis is correct. However the library is still correct in regards to refcounting even for an SSL BIO in the chain. The reason is that the decrement of refcount of the BIOs underlying the SSL BIO is handled through the actual freeing of the SSL BIO. If the refcount for the SSL BIO in the chain freed by BIO_free_all() drops to zero, it will, in ssl_free() call in bio_ssl.c, free the underlying SSL * object. And if the refcount of that SSL object drops to zero it will call BIO_free_all() on the underlying wbio and rbio. Which means also the chained BIOs underlying the SSL BIO will have their refcount dropped and they will be properly freed. Tomas Mraz, OpenSSL On Mon, 2022-10-03 at 09:35 -0700, Jay Foster wrote: > Your response makes sense. I am a bit puzzled by the BIO reference > counting. For example > > BIO_new() (or BIO_new_socket() which calls BIO_new()) produces a > BIO with a reference count of 1. > BIO_free() drops 1 reference and if the reference count is 0, > frees > the BIO. > > BIO_push() connects the BIO to the BIO chain. No references are > directly changed. However, the BIO_CTRL_PUSH command is sent to the > BIO. For the SSL BIO, this results in a call to SSL_set_bio() and > adding 1 to the next_bio reference (socket BIO). > BIO_pop() calls BIO_CTRL_POP and disconnects the BIO from the > BIO > chain. For the SSL BIO, the BIO_CTRL_POP subtracts one from the > next_bio reference (undoing BIO_push()). > > The problem case is calling BIO_free_all() on the BIO chain. > BIO_free_all() does not use BIO_pop(). It simply detaches each BIO > from > the chain, and calls BIO_free() for it. If the next_bio reference > count > is > 1 (which it will be for the SSL BIO next_bio), it stops > unlinking > and freeing BIOs. This seems asymmetrical with respect to the BIO > reference counting, and leaks the next_bio (socket BIO in this case). > > What am I missing here? > Jay > > > On 9/29/2022 11:50 PM, Tomas Mraz wrote: > > The SSL BIO should have the rbio from the SSL object as the next > > BIO. > > If you create the SSL BIO and then BIO_push() the TCP socket BIO > > into > > the SSL BIO, it will work correctly. > > > > Otherwise, you can just fix the next BIO of the SSL BIO by using > > > > BIO_up_ref(socketbio); > > BIO_set_next(sslbio, socketbio); > > > > The SSL BIO should always have a next BIO if properly initialized. > > > > Tomas Mraz, OpenSSL > > > > On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote: > > > I have an application that constructs a chain of BIOs. Sometimes > > > this > > > chain also includes an SSL BIO. Years ago, I ran into a problem > > > that > > > caused BIO_flush() to segfault on the SSL BIO. This turned out > > > to > > > happen because the SSL BIO is added using SSL_set_bio() instead > > > of > > > BIO_push(). SSL_set_bio() results in the SSL BIO always having a > > > NULL > > > bio_next value, so BIO_flush then crashes dereferencing this NULL > > > pointer when it calls BIO_copy_next_retry() on the SSL BIO (see > > > BIO_CTRL_FLUSH in ssl/bio_ssl.c). > > > > > > This was reported as ticket 2615 years ago. > > > > > > My question is, how could calling BIO_flush() on a BIO chain with > > > an > > > SSL > > > BIO ever work? Is there a way to add the SSL BIO using > > > BIO_push() > > > instead of SSL_set_bio()? > > > > > > Jay > > > > -- Tomáš Mráz, OpenSSL
Re: Regarding Encrypted datalength
As I wrote before, there is no such function. There is only the EVP_PKEY_get_size() which gives you the maximum length the encrypted data can have for a given key. If you do not know the length of the ciphertext for the EVP_PKEY_decrypt() call, you can use the EVP_PKEY_get_size() value, compare it with the data length of your data and if it is smaller, use it as the ciphertext length in the EVP_PKEY_decrypt() call. That should work fine - at least with the algorithms currently supported by OpenSSL. On Sat, 2022-10-01 at 22:16 +, ANUJ SHARMA wrote: > Hi, > Just wanted to know that is there any Openssl/EVP_PKEY function where > I pass the encrypted data and encryption method and get the size of > encrypted data. > Something like: > EncryptedDataLen=OpensslFunc(encrypted_data,encryption_method) > > Thanks for your helping in advance. -- Tomáš Mráz, OpenSSL
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
I am glad to hear that.
Regards,
Tomas Mraz, OpenSSL
On Fri, 2022-09-30 at 17:18 +, GonzalezVillalobos, Diego wrote:
> [AMD Official Use Only - General]
>
> Hello Tomas,
>
> There was a logic error in my code, I did not realize that the first
> iteration of the verification was supposed to fail. The verification
> is working correctly! I apologize for my last response. I really
> appreciate all your help!
>
> Thank you very much,
>
> Diego Gonzalez
> -
> -
>
>
> -Original Message-
> From: Tomas Mraz
> Sent: Friday, September 30, 2022 1:22 AM
> To: GonzalezVillalobos, Diego ;
> openssl-users@openssl.org
> Subject: Re: Updating RSA public key generation and signature
> verification from 1.1.1 to 3.0
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Hi,
>
> unfortunately I do not see anything wrong with the code. Does the
> EVP_DigestVerifyFinal return 0 or negative value? I do not think this
> is a bug in OpenSSL as this API is thoroughly tested and it is highly
> improbable that there would be a bug in the ECDSA verification
> through this API.
>
> I am currently out of ideas on what could be wrong or how to
> investigate further. Perhaps someone else can chime in on what can be
> wrong?
>
> Tomas
>
> On Thu, 2022-09-29 at 19:22 +, GonzalezVillalobos, Diego wrote:
> > [AMD Official Use Only - General]
> >
> > Hello Tomas,
> >
> > So, I made sure that px_size and py_size are equal to the group
> > order
> > (48). I was able to verify successfully using our previous method
> > (deprecated) with the new key generation method, but I'm still not
> > able to get the digestverify to work successfully. As a reminder
> > this
> > is how we were verifying before:
> >
> > // Determine if SHA_TYPE is 256 bit or 384 bit if
> > (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA256 ||
> > parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256
> > ||parent_cert-
> > > pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256)
> > {
> > sha_type = SHA_TYPE_256;
> > sha_digest = sha_digest_256;
> > sha_length = sizeof(hmac_sha_256);
> > }
> > else if (parent_cert->pub_key_algo == SEV_SIG_ALGO_RSA_SHA384 ||
> > parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384 ||
> > parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA384)
> > {
> > sha_type = SHA_TYPE_384;
> > sha_digest = sha_digest_384;
> > sha_length = sizeof(hmac_sha_512);
> > }
> > else
> > {
> > break;
> > }
> >
> > // 1. SHA256 hash the cert from Version through pub_key
> > parameters
> > // Calculate the digest of the input message rsa.c ->
> > rsa_pss_verify_msg()
> > // SHA256/SHA384 hash the cert from the [Version:pub_key]
> > params
> > uint32_t pub_key_offset = offsetof(sev_cert, sig_1_usage);
> > //
> > 16 + sizeof(SEV_PUBKEY)
> > if (!digest_sha((uint8_t *)child_cert, pub_key_offset,
> > sha_digest, sha_length, sha_type)) {
> > break;
> > }
> > if ((parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) ||
> > (parent_cert->pub_key_algo ==
> > SEV_SIG_ALGO_ECDSA_SHA384) ||
> > (parent_cert->pub_key_algo ==
> > SEV_SIG_ALGO_ECDH_SHA256) ||
> > (parent_cert->pub_key_algo ==
> > SEV_SIG_ALGO_ECDH_SHA384)) { // ecdsa.c -> sign_verify_msg
> > ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new();
> > BIGNUM *r_big_num = BN_new();
> > BIGNUM *s_big_num = BN_new();
> >
> > // Store the x and y components as separate BIGNUM
> > objects. The values in the
> > // SEV certificate are little-endian, must reverse
> > bytes before storing in BIGNUM
> > r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
> > sizeof(sev_ecdsa_sig::r), r_big_num); // LE to BE
> > s_big_num = BN_lebin2bn(cert_sig[i].ecdsa.s,
> > sizeof(sev_ecdsa_sig::s), s_big_num);
> >
> > // Calling ECDSA_SIG_set0() transfers the memory
> > management of the values to
> >
Re: Regarding EVP_PKEY_decrypt()
There is EVP_PKEY_get_size() function which will give you the maximum length the encrypted data can have. Unfortunately it cannot give you the exact length which might be smaller in some cases. Tomas Mraz On Thu, 2022-09-29 at 21:49 +, ANUJ SHARMA wrote: > Hi, > I am working on this function. > result = EVP_PKEY_decrypt(ctx, DecryptedData, , > EncryptedData,256); > > I am getting the encrypted data from a different location and code is > in such a way that we just have a pointer pointing to the starting of > Encrypted data. Meaning -We don't know the encrypted data length. > I passed a pointer of encrypted data to this function and decryption > is also happening properly. > My doubt is whether is there any openssl/EVP_PKEY function or any way > by which we can find the exact encrypted data length before doing the > decryption. > > Thanks in advance for helping me out! -- Tomáš Mráz, OpenSSL
Re: BIO_flush Segmentation Fault Issue
The SSL BIO should have the rbio from the SSL object as the next BIO. If you create the SSL BIO and then BIO_push() the TCP socket BIO into the SSL BIO, it will work correctly. Otherwise, you can just fix the next BIO of the SSL BIO by using BIO_up_ref(socketbio); BIO_set_next(sslbio, socketbio); The SSL BIO should always have a next BIO if properly initialized. Tomas Mraz, OpenSSL On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote: > I have an application that constructs a chain of BIOs. Sometimes > this > chain also includes an SSL BIO. Years ago, I ran into a problem that > caused BIO_flush() to segfault on the SSL BIO. This turned out to > happen because the SSL BIO is added using SSL_set_bio() instead of > BIO_push(). SSL_set_bio() results in the SSL BIO always having a > NULL > bio_next value, so BIO_flush then crashes dereferencing this NULL > pointer when it calls BIO_copy_next_retry() on the SSL BIO (see > BIO_CTRL_FLUSH in ssl/bio_ssl.c). > > This was reported as ticket 2615 years ago. > > My question is, how could calling BIO_flush() on a BIO chain with an > SSL > BIO ever work? Is there a way to add the SSL BIO using BIO_push() > instead of SSL_set_bio()? > > Jay > -- Tomáš Mráz, OpenSSL
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
56_DIGEST_LENGTH)/* ||
> (sha_type == SHA_TYPE_384 && digest_len !=
> SHA384_DIGEST_LENGTH)*/)
> break;
>
> if (sha_type == SHA_TYPE_256) {
> SHA256_CTX context;
>
> if (SHA256_Init() != 1)
> break;
> if (SHA256_Update(, (void *)msg, msg_len) != 1)
> break;
> if (SHA256_Final(digest, ) != 1)
> break;
> }
> else if (sha_type == SHA_TYPE_384) {
> SHA512_CTX context;
>
> if (SHA384_Init() != 1)
> break;
> if (SHA384_Update(, (void *)msg, msg_len) != 1)
> break;
> if (SHA384_Final(digest, ) != 1)
> break;
> }
>
> ret = true;
> } while (0);
>
> return ret;
> }
>
> This works using the new EC EVP key generation.
> The current verification method keeps failing:
>
> if ((parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDSA_SHA384) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA256) ||
> (parent_cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA384)) { // ecdsa.c -> sign_verify_msg
>
> ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new();
> BIGNUM *r_big_num = BN_new();
> BIGNUM *s_big_num = BN_new();
> uint32_t sig_len;
> unsigned char* der_sig = NULL;;
>
> // Store the x and y components as separate BIGNUM
> objects. The values in the
> // SEV certificate are little-endian, must reverse
> bytes before storing in BIGNUM
> r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
> sizeof(sev_ecdsa_sig::r), r_big_num); // LE to BE
> s_big_num = BN_lebin2bn(cert_sig[i].ecdsa.s,
> sizeof(sev_ecdsa_sig::s), s_big_num);
>
> // Calling ECDSA_SIG_set0() transfers the memory
> management of the values to
> // the ECDSA_SIG object, and therefore the values
> that have been passed
> // in should not be freed directly after this
> function has been called
> if (ECDSA_SIG_set0(tmp_ecdsa_sig,
> r_big_num,s_big_num) != 1) {
> BN_free(s_big_num); // FreesBIGNUMs manually here
> BN_free(r_big_num);
> ECDSA_SIG_free(tmp_ecdsa_sig);
> break;
> }
>
> int der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig,
> _sig);
> // der_sig = static_cast char*>(OPENSSL_malloc(der_sig_len));
> // unsigned char* der_iter = der_sig;
> // der_sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig,
> _iter); // <= bugfix here
>
>
> if (der_sig_len == 0) {
> cout << "sig length invalid" << endl;
> break;
> }
>
> if (der_sig == NULL) {
> cout << "sig generation failed" << endl;
> break;
> }
>
> // loop through the array elements
> for (size_t i = 0; i < der_sig_len; i++) {
> cout << der_sig[i] << ' ';
> }
>
> verify_md_ctx = EVP_MD_CTX_new();
>
>
> if (!verify_md_ctx) {
> cout << "Error md verify context " << endl;;
> break;
> }
>
> if (EVP_DigestVerifyInit(verify_md_ctx, NULL,
> (parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256) ?
> EVP_sha256(): EVP_sha384(), NULL, parent_signing_key) <= 0) {
> cout << "Init fails " << endl;
> break;
> }
>
> if (EVP_DigestVerifyUpdate(verify_md_ctx, (uint8_t
> *)child_cert, pub_key_offset) <= 0){ // Calls SHA256_UPDATE
> cout << "updating digest fails" << endl;
> break;
> }
>
> int ret = EVP_DigestVerifyFinal(verify_md_ctx,
> der_sig, der_sig_len);
> if (ret == 0) {
> cout << "EC Verify digest fails" << endl;
> break;
> } else if (ret < 0) {
>
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
Hi,
comments below.
On Wed, 2022-09-28 at 22:12 +, GonzalezVillalobos, Diego wrote:
> [AMD Official Use Only - General]
>
> Hello Tomas,
>
> I generated the key as you suggested, and I am no longer getting an
> error message! Thank you for that. Here is how I'm generating the key
> now:
>
> // SEV certificate are little-endian, must reverse bytes before
> generating key
> if ((cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256) ||
> (cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA384)) {
> //Grab x param and flip bytes to BE
> memcpy(px, >pub_key.ecdsa.qx, ec_group_order);
> if(!sev::reverse_bytes(px, sizeof(px)))
> break;
> //Grab y param and flip bytes to BE
> memcpy(py, >pub_key.ecdsa.qy, ec_group_order);
> if(!sev::reverse_bytes(py, sizeof(py)))
> break;
> }
> else if ((cert->pub_key_algo ==
> SEV_SIG_ALGO_ECDH_SHA256) ||
> (cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA384))
> {
> //Grab x param and flip bytes to BE
> memcpy(px, >pub_key.ecdh.qx, ec_group_order);
> if(!sev::reverse_bytes(px, sizeof(px)))
> break;
> //Grab y param and flip bytes to BE
> memcpy(py, >pub_key.ecdh.qy, ec_group_order);
> if(!sev::reverse_bytes(py, sizeof(py)))
> break;
> }
>
> int px_size = sizeof(px)/sizeof(*px);
> int py_size = sizeof(py)/sizeof(*py);
>
> // Will contain x and y components
> unsigned char public_key_xy[1 + px_size + py_size] = {0};
>
> //Add point conversion as first value
> public_key_xy[0] = POINT_CONVERSION_UNCOMPRESSED;
>
> //Add x components after point compression
> memcpy(public_key_xy + 1, px, px_size);
> //Add y components after x
> memcpy(public_key_xy + px_size + 1, py ,py_size);
>
> // int nid = EC_curve_nist2nid("P-384"); //
> NID_secp384r1
>
> OSSL_PARAM_BLD *params_build = OSSL_PARAM_BLD_new();
>
> if ( params_build == NULL ) {
> cout << "Params build fails" << endl;
> break;
> }
>
> if (!OSSL_PARAM_BLD_push_utf8_string(params_build,
> OSSL_PKEY_PARAM_GROUP_NAME, "P-384", 0)) {
> cout<< "Push EC curve to build fails" << endl;
> break;
> }
>
> if (!OSSL_PARAM_BLD_push_octet_string(params_build,
> OSSL_PKEY_PARAM_PUB_KEY, public_key_xy, sizeof(public_key_xy))) {
> cout << "Error: failed to push qx into param build."
> << endl;
> break;
> }
>
> OSSL_PARAM *params =
> OSSL_PARAM_BLD_to_param(params_build);
>
> if ( params == NULL ) {
> cout << "Error: building parameters." << endl;
> break;
> }
>
> OSSL_PARAM_BLD_free(params_build);
>
> key_gen_ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, NULL);
>
> if(EVP_PKEY_fromdata_init(key_gen_ctx) != 1) {
> cout << "failed to initialize key creation." << endl;
> break;
> }
>
> if(EVP_PKEY_fromdata(key_gen_ctx, _pub_key,
> EVP_PKEY_PUBLIC_KEY, params) != 1) {
> cout << "key generation breaks" << endl;
> printf("Failed Final Verify
> %s\n",ERR_error_string(ERR_get_error(),NULL));
> break;
> }
>
> if (EVP_PKEY_get_base_id(evp_pub_key) != EVP_PKEY_EC) {
> cout << "wrong key type" << endl;
> break;
> }
> }
>
> if (!evp_pub_key) {
> cout << "no evp pkey" << endl;
> break;
> }
> cout << "compile key succesful" << endl;
> cmd_ret = STATUS_SUCCESS;
>
> Although the key generation works and I'm not getting a verify error
> anymore, I am still unsuccessful on verifying the digest. It keeps
> failing (returning 0). Here is how I'm currently trying to do the
> verification.
Are you sure the px_size and py_size is equal to the group order? The x
and y values must be padded to the group order with 0 (at the start
because the values need to be BE).
> ECDSA_SIG *tmp_ecdsa_sig = ECDSA_SIG_new();
> BIGNUM *r_big_num = BN_new();
> BIGNUM *s_big_num = BN_new();
> uint32_t sig_len;
> unsigned char* der_sig;
>
> // Store the x and y components as separate BIGNUM
> objects. The values in the
> // SEV certificate are little-endian, must reverse
> bytes before storing in BIGNUM
> r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
>
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
new();
> uint32_t sig_len;
> unsigned char *p;
>
> // Store the x and y components as separate BIGNUM
> objects. The values in the
> // SEV certificate are little-endian, must reverse
> bytes before storing in BIGNUM
> r_big_num = BN_lebin2bn(cert_sig[i].ecdsa.r,
> sizeof(sev_ecdsa_sig::r), r_big_num); // LE to BE
> s_big_num = BN_lebin2bn(cert_sig[i].ecdsa.s,
> sizeof(sev_ecdsa_sig::s), s_big_num);
>
> // Calling ECDSA_SIG_set0() transfers the memory
> management of the values to
> // the ECDSA_SIG object, and therefore the values
> that have been passed
> // in should not be freed directly after this
> function has been called
> if (ECDSA_SIG_set0(tmp_ecdsa_sig, r_big_num,
> s_big_num) != 1) {
> BN_free(s_big_num); // Frees
> BIGNUMs manually here
> BN_free(r_big_num);
> ECDSA_SIG_free(tmp_ecdsa_sig);
> break;
> }
>
> sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, NULL);
> unsigned char signature[sig_len];
>
> p = signature;
>
> sig_len = i2d_ECDSA_SIG(tmp_ecdsa_sig, );
>
>
> if (signature == NULL) {
> cout << "sig mem failed" << endl;
> break;
> }
>
> if (sig_len == 0)
> cout << "sig length invalid" << endl;
>
> verify_md_ctx = EVP_MD_CTX_new();
>
>
> if (!verify_md_ctx) {
> cout << "Error md verify context " << endl;;
> break;
> }
>
> if (EVP_DigestVerifyInit(verify_md_ctx, NULL,
> (parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDSA_SHA256 ||
> parent_cert->pub_key_algo == SEV_SIG_ALGO_ECDH_SHA256) ? EVP_sha256()
> : EVP_sha384(), NULL, parent_signing_key) <= 0) {
> cout << "Init fails " << endl;
> break;
> }
>
> if (EVP_DigestVerifyUpdate(verify_md_ctx, child_cert,
> pub_key_offset) <= 0){ // Calls SHA256_UPDATE
> cout << "updating digest fails" << endl;
> break;
> }
>
> int ret = EVP_DigestVerifyFinal(verify_md_ctx,
> signature, sig_len);
> cout << ret << endl;
> if (ret == 0) {
> cout << "EC Verify digest fails" << endl;
> break;
> } else if (ret < 0) {
> printf("Failed Final Verify
> %s\n",ERR_error_string(ERR_get_error(),NULL));
> cout << "EC Verify error" << endl;
> break;
> }
>
> found_match = true;
> cout << "SEV EC verification Succesful" << endl;
>
>
> My current output when I reach EVP_DigestVerifyFinal is showing this
> error:
> Failed Final Verify error:0395:digital envelope routines::no
> operation set
>
> I have been playing around with it for a while, but I am stuck at
> this point. Any advice would be appreciated.
>
> Thank you,
>
> Diego Gonzalez Villalobos
> -
> -
>
>
> -Original Message-
> From: Tomas Mraz
> Sent: Friday, September 9, 2022 10:36 AM
> To: GonzalezVillalobos, Diego ;
> openssl-users@openssl.org
> Subject: Re: Updating RSA public key generation and signature
> verification from 1.1.1 to 3.0
>
> [CAUTION: External Email]
>
> On Thu, 2022-09-08 at 16:10 +, GonzalezVillalobos, Diego via
> openssl-users wrote:
> > [AMD Official Use Only - General]
> >
> > Hello everyone,
> >
> > I am currently working on updating a signature verification
> > function
> > in C++ and I am a bit stuck. I am trying to replace the deprecated
> > 1.1.1 functions to the appropriate 3.0 versions. The function takes
> > in
> > 2 certificate objects (parent and cert), which are not x509
> > certificates, but certificates the company had previously defined.
> > Using the contents from parent we create an RSA public key and
> > using
> > the contents from cert we create the digest and grab the signature
> > to
> > verify.
> >
> > In the 1.1.1 version we were using the RSA Object and the
> > rsa_set0_key
> > function to create the RSA public key and then used
> > RSA_public_decrypt
> > to decrypt the signature and RSA_verify_PKCS1_PSS to verify it.
> > This
> > whole workflow is now deprecated.
> >
> ...
> > Is this the correct way of creating RSA keys now? Where is my logic
> > failing? Can the same type of procedure even be done on 3.0? Any
> > advice would be really appreciated.
> >
>
> In the original code you seem to be using PSS padding for
> verification.
> Did you try to set the PSS padding on the digest verify context? See
> demos/signature/rsa_pss_hash.c on how to do it.
>
> --
> Tomáš Mráz, OpenSSL
--
Tomáš Mráz, OpenSSL
Re: Updating RSA public key generation and signature verification from 1.1.1 to 3.0
On Thu, 2022-09-08 at 16:10 +, GonzalezVillalobos, Diego via openssl-users wrote: > [AMD Official Use Only - General] > > Hello everyone, > > I am currently working on updating a signature verification function > in C++ and I am a bit stuck. I am trying to replace the deprecated > 1.1.1 functions to the appropriate 3.0 versions. The function takes > in 2 certificate objects (parent and cert), which are not x509 > certificates, but certificates the company had previously defined. > Using the contents from parent we create an RSA public key and using > the contents from cert we create the digest and grab the signature to > verify. > > In the 1.1.1 version we were using the RSA Object and the > rsa_set0_key function to create the RSA public key and then used > RSA_public_decrypt to decrypt the signature and RSA_verify_PKCS1_PSS > to verify it. This whole workflow is now deprecated. > ... > Is this the correct way of creating RSA keys now? Where is my logic > failing? Can the same type of procedure even be done on 3.0? Any > advice would be really appreciated. > In the original code you seem to be using PSS padding for verification. Did you try to set the PSS padding on the digest verify context? See demos/signature/rsa_pss_hash.c on how to do it. -- Tomáš Mráz, OpenSSL
Re: Loading raw EC and RSA keys with OpenSSL 3
On Tue, 2022-08-23 at 12:09 +, Jonathan Wernberg wrote: > TL;DR: With OpenSSL 3.x API, what is the recommended and safe way to > read in an EC private key from raw format into an EVP_PKEY object > ready to be used? What is the easiest way to convert an RSA public > key from raw modulus and exponent components to proper DER encoded > SubjectPublicKeyInfo data? > > Hi openssl-users mailing list. > > We are having some troubles converting some code from OpenSSL 1.x to > OpenSSL 3.x APIs, to get rid of deprecation warnings, and hope > someone may be able to give us some hints in the right direction. > > One thing we want to do is to convert an EC private key from raw > format into a EVP_PKEY. Today we do as below (error checking, freeing > and secure memory context things removed for brevity, private key is > in "privkey" and curve in "nid"): > > BIGNUM *privkey_bn = BN_bin2bn(privkey, privkey_len, NULL); > EC_KEY *eckey = EC_KEY_new_by_curve_name(nid); > const EC_GROUP *group = EC_KEY_get0_group(eckey); > EC_POINT *pubkey_point = EC_POINT_new(group); > EC_POINT_mul(group, pubkey_point, privkey_bn, NULL, NULL, NULL); > EC_KEY_set_private_key(eckey, privkey_bn); > EC_KEY_set_public_key(eckey, pubkey_point); > EVP_PKEY *pkey = EVP_PKEY_new(); > EVP_PKEY_assign_EC_KEY(pkey, eckey); > > Basically we chained a lot of operations because we could not find > any single function that did it for us. Some of these operations are > now deprecated, such as the EC_KEY ones. We tried experimenting with > the OSSL fromdata() function instead (omitted the mapping from "nid" > to "sn" for brevity): > > BIGNUM *privkey_bn = BN_bin2bn(privkey, privkey_len, NULL); > EC_GROUP *group = EC_GROUP_new_by_curve_name(nid); > EC_POINT *pubkey_point = EC_POINT_new(group); > EC_POINT_mul(group, pubkey_point, privkey_bn, NULL, NULL, NULL); > unsigned char pubkey_buf[65]; // size just an example > EC_POINT_point2oct(grp, pubkey_point, POINT_CONVERSION_UNCOMPRESSED, > pubkey_buf, sizeof(pubkey_buf), NULL); > OSSL_PARAM_BLD *param_bld = OSSL_PARAM_BLD_new(); > OSSL_PARAM_BLD_push_utf8_string(param_bld, > OSSL_PKEY_PARAM_GROUP_NAME, sn, 0); > OSSL_PARAM_BLD_push_BN(param_bld, OSSL_PKEY_PARAM_PRIV_KEY, > privkey_bn); > OSSL_PARAM_BLD_push_octet_string(param_bld, OSSL_PKEY_PARAM_PUB_KEY, > pubkey_buf, sizeof(pubkey_buf)); > OSSL_PARAM *params = OSSL_PARAM_BLD_to_param(param_bld); > EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "EC", NULL); > EVP_PKEY_fromdata_init(ctx); > EVP_PKEY *pkey = NULL; > EVP_PKEY_fromdata(ctx, , EVP_PKEY_KEYPAIR, params); > EVP_PKEY_CTX_free(ctx); > ctx = EVP_PKEY_CTX_new(pkey, NULL); > EVP_PKEY_check(ctx); > > Although it works, it does not feel right. We ended up chaining many > more operations than before. Our understanding was that the new > OpenSSL 3.x API was redesigned partially to remove low-level > manipulations like these. We have looked though both the migration > document and the reference API without finding anything that does our > job better. OSSL_DECODERs as frequently suggested in the migration > documentation do not seem to support raw EC key formats at all. The > EVP_PKEY_new_raw_private_key() functions mentioned in the reference > API does not appear to support NIST P curves, according to the > documentation. The OSSL fromdata() way above does not calculate the > public key from the private one itself, nor does it verify that the > points are on the curve, and we are uncertain if there are anything > else it does not do that we need to do to not compromise security. We > could use d2i_PrivateKey() or d2i_AutoPrivateKey(), which both seem > to read in the key data in a secure way and derive the public part > automatically. But that way would require us to implement custom > logic in our code to manually put together DER data from the raw key > data, for multiple curve types. > > What is the recommended and safe way to read in an EC private key > from raw format into an EVP_PKEY object ready to be used? > > Another thing we want to do is to convert an RSA public key from raw > modulus and exponent components into proper DER encoded > SubjectPublicKeyInfo data. Today we piggyback on OpenSSL to > accomplish this like this: > > BIGNUM *n = BN_bin2bn(modulus, (int)modulus_len, NULL); > BIGNUM *e = BN_bin2bn(exponent, (int)exponent_len, NULL); > RSA *rsa = RSA_new(); > RSA_set0_key(rsa, n, e, NULL); > int data_len = i2d_RSA_PUBKEY(rsa, NULL); > uint8_t *data_buf = malloc((size_t)data_len); > uint8_t *pdata = data_buf; > data_len = i2d_RSA_PUBKEY(rsa, ); > > However, some of those functions are now deprecated. Unfortunately > our best attempt with OpenSSL 3.x compatible APIs ended up being this > comparably long sequence of operations: > > BIGNUM *n = BN_bin2bn(modulus, (int)modulus_len, NULL); > BIGNUM *e = BN_bin2bn(exponent, (int)exponent_len, NULL); > EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL); > OSSL_PARAM_BLD *param_bld = OSSL_PARAM_BLD_new(); >
Re: Non-heap based structures
Hi, there is no way to do that with OpenSSL 1.1.0 and newer. The thing is that with recent versions of OpenSSL the later operations with the EVP_MD_CTX can fail for other reasons than memory allocation failure such as algorithm unavailability from a provider. So you would need to check anyway. If the only unchecked place is the context allocation, you can add the NULL checks to all other places where you use the context. Tomas On Tue, 2022-07-26 at 23:42 -0600, Philip Prindeville wrote: > Hi, > > I suspect I already know the answer, but... is there a way to have a > non-heap based structure like EVP_MD_CTX? > > If I don't want to have one be malloc'd (or OPENSSL_zalloc'd as the > case may be), I can't have one be a stack variable or static, can I? > > I ask because I'm trying to replace some existing code that has no > path to handle out-of-memory exceptions if EVP_MD_CTX_create() ever > returns NULL... > > I guess the point of crypto/evp/evp_local.h is to completely hide > details of the structure, including its size... so the answer to the > original question is probably "no". But I just wanted to make sure. > > Thanks, > > -Philip > -- Tomáš Mráz, OpenSSL
Re: DH parameter reading in OPENSSL 3
Hi,
it is somewhat unclear to me why do you consider the migration_guide(7)
useless in this regard. Citing it:
SSL_CTX_set_tmp_dh_callback(), SSL_set_tmp_dh_callback(),
SSL_CTX_set_tmp_dh(), SSL_set_tmp_dh()
These are used to set the Diffie-Hellman (DH) parameters that are to be
used by servers requiring ephemeral DH keys. Instead applications
should consider using the built-in DH parameters that are available by
calling SSL_CTX_set_dh_auto(3) or SSL_set_dh_auto(3). If custom
parameters are necessary then applications can use the alternative
functions SSL_CTX_set0_tmp_dh_pkey(3) and SSL_set0_tmp_dh_pkey(3).
So basically instead of SSL_CTX_set_tmp_dh() you should use
SSL_CTX_set0_tmp_dh_pkey().
To get an EVP_PKEY instead of DH, you should use
OSSL_DECODER_from_bio() to read the parameters using the decoder. How
to do that you can find out in the OSSL_DECODER_FROM_bio() manual page
- just use the example for the RSA key but replace the
OSSL_KEYMGMT_SELECT_KEYPAIR selector with
OSSL_KEYMGMT_SELECT_ALL_PARAMETERS, replace RSA with DH for the
keytype, and drop the OSSL_DECODER_CTX_set_passphrase call as that is
useless for parameters.
Another even more simple option would be to use
PEM_read_bio_Parameters().
Tomas Mraz
On Wed, 2022-07-13 at 16:35 +0200, Dirk Stöcker wrote:
> Hello,
>
> when upgrading to openssl3 my code states that some functions are
> deprecated in openssl 3, but even after reading documentation I was
> unable to find a non-deprecated replacement.
>
> Task is to read DH parameters in PEM format from a file and use them
> for
> the current "context" and if not available choose some defaults.
>
> if((bio = BIO_new_file("filename", "r")))
> {
> DH *dh = PEM_read_bio_DHparams(bio, 0, 0, 0);
> BIO_free(bio);
> /* if no DH inside, try internal defaults */
> if(!dh && (bio = BIO_new_mem_buf(dhparam, sizeof(dhparam
> {
> dh = PEM_read_bio_DHparams(bio, 0, 0, 0);
> BIO_free(bio);
> }
> if(dh)
> {
> SSL_CTX_set_tmp_dh(context, dh);
> DH_free(dh);
> }
> }
>
> Now it seems the default can be replaced by
>
> SSL_CTX_set_dh_auto(context, 1);
>
> instead of the the internal values but I have no idea how to use
> OSSL_DECODER to get the parameters and pass them to context. The
> migrationg guide is really useless and the examples and the openssl
> source also didn't help much.
>
> Anybody who can help me? It's probably only a few calls when one
> knows
> what to do.
>
> Freedom in Peace
--
Tomáš Mráz, OpenSSL
Re: Is there a one-page doc to tell which function now changes to which in OpenSSL3?
A good starting point is to read the migration guide: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Tomas Mraz, OpenSSL On Tue, 2022-06-28 at 20:48 -0700, Pei JIA wrote: > Actually, my question is quite general: > It looks a lot of functions in **OpenSSL1.1.1** is NOW deprecated in > **OpenSSL3** . > * Is there a doc to tell which function in **OpenSSL1.1.1** is NOW > changed to which function in **OpenSSL3** ??? > * Or any documentation that provides a very simple code snippet to > compare the implementation based on **OpenSSL1.1.1** and the > implementation using **OpenSSL3** . > > > ```console > error: ‘EVP_PKEY_get1_RSA’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘SSL_CTX_use_RSAPrivateKey’ is deprecated: Since OpenSSL 3.0 > [-Werror=deprecated-declarations] > error: ‘RSA_free’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_init’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_set_default’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_load_private_key’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_finish’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_free’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ENGINE_by_id’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘TLSv1_2_method’ is deprecated: Since OpenSSL 1.1.0 [- > Werror=deprecated-declarations] > error: ‘TLSv1_1_method’ is deprecated: Since OpenSSL 1.1.0 [- > Werror=deprecated-declarations] > error: ‘TLSv1_method’ is deprecated: Since OpenSSL 1.1.0 [- > Werror=deprecated-declarations] > error: ‘ERR_load_BIO_strings’ is deprecated: Since OpenSSL 3.0 [- > Werror=deprecated-declarations] > error: ‘ERR_remove_thread_state’ is deprecated: Since OpenSSL 1.1.0 > [-Werror=deprecated-declarations] > error: ‘ENGINE_load_builtin_engines’ is deprecated: Since OpenSSL 3.0 > [-Werror=deprecated-declarations] > > ``` > > > > > > > > > -- Tomáš Mráz, OpenSSL
Re: memory still reachable post calling SSL_CTX_free
On Tue, 2022-06-21 at 10:33 +, Tiwari, Hari Sahaya wrote:
> Hi,
> I need one clarification on routine SSL_CTX_free(). I see the memory
> is not freed even after calling this SSL_CTX_free().
>
> I have a simple test program, which just does SSL_CTX_new() and
> SSL_CTX_free().
>
> #include
> #include
>
> int main()
> {
> const SSL_METHOD *method;
> SSL_CTX *ctx = NULL;
> OPENSSL_init_ssl(0, NULL);
> method = TLS_method();
> ctx = SSL_CTX_new(method);
> if ( ctx == NULL ) {
> return(-1);
> }
> SSL_CTX_free(ctx);
> ctx=NULL;
> sleep(300);
sleep() won't help you at all as there is no concurrent thread running
or anything else that would remove things for you when the process is
sleeping.
> }
>
> If the program is terminated after it enters the sleep, I am seeing
> memory is still reachable in valgrind.
>
> Here is output from valgrind,
>
> ==443000== 10,224 bytes in 426 blocks are still reachable in loss
> record 593 of 594
> ==443000== at 0x4C34F0B: malloc (vg_replace_malloc.c:307)
> ==443000== by 0x525D775: OPENSSL_LH_insert (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000== by 0x522DDB2: ??? (in /usr/lib64/libcrypto.so.1.1.1g)
> ==443000== by 0x522E1CF: ERR_load_strings_const (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000== by 0x4E79083: ERR_load_SSL_strings (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000== by 0x4E790BC: ??? (in /usr/lib64/libssl.so.1.1.1g)
> ==443000== by 0x5DABCD6: __pthread_once_slow (in
> /usr/lib64/libpthread-2.28.so)
> ==443000== by 0x52C4ADC: CRYPTO_THREAD_run_once (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000== by 0x4E794FA: OPENSSL_init_ssl (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000== by 0x4E7D371: SSL_CTX_new (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000== by 0x400749: main (in /home/hari/a.out)
>
This is actually not a memory allocated by the SSL_CTX_new() itself but
error string data that is global. There is no real memory leak here.
You can call OPENSSL_cleanup() to explicitly de-allocate all the global
data however please note that you can do it really only before
immediate exit of the application using OpenSSL otherwise you risk
crashes if something tries to call OpenSSL again after
OPENSSL_cleanup() was called.
> SSL_CTX_free is already called before sleep(), but memory is still
> hanging around.
> Is there something I am missing here? Do I need to follow some other
> steps ?
> This memory leak is impacting our long term running processes, which
> allocate and free context.
This should not be the case as this memory should be allocated only
once. If you, in your test code, do SSL_CTX_new/SSL_CTX_free in a loop
you should still see just the same memory leaked and not more blocks.
--
Tomáš Mráz, OpenSSL
Re: nmake test error on 80-test_ssl_new.t
This is a known issue: https://github.com/openssl/openssl/issues/18456 You can just ignore the failure for now, it will be fixed in the next release. Tomas On Fri, 2022-06-10 at 14:08 +0430, Mohammad Ghasemi wrote: > I'm trying to build openssl 3 in Windows 10 using msvc 143 > > Test Summary Report > --- > 80-test_ssl_new.t (Wstat: 256 Tests: 30 Failed: 1) > Failed test: 12 > Non-zero exit status: 1 > Files=243, Tests=3106, 2594 wallclock secs (21.45 usr + 2.69 sys = > 24.14 CPU) > Result: FAIL > NMAKE : fatal error U1077: 'cmd' : return code '0x1' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Tools\MSVC\14.32.31326\bin\HostX64\x64\nmake.e > xe"' : return code '0x2' > Stop. -- Tomáš Mráz, OpenSSL
Re: AW: AW: How to figure out if .P12 is RSA or ECC crypted
On Thu, 2022-06-09 at 13:14 +, Beilharz, Michael wrote: > well, i use: > > pkcs12 -in "cert.p12" -clcerts -nokeys -out cert.PEM" -passin > pass: > pkcs12 -in "cert.p12" -nocerts -out tmpkey.PEM -passin pass: - > passout pass: Instead of this step you can just use: pkcs12 -in "cert.p12" -nocerts -nodes -out key.pem -passin pass: if you need unencrypted private key in PEM file. -- Tomáš Mráz, OpenSSL
Re: RSA_generate_key_ex is crashing when compiled on RHEL6 PPC and executed on RHEL8 for OpenSSL 3.0.1PPC
It is not an issue in OpenSSL that the getentropy somehow does not work. I could imagine adding a define that disables use of getentropy. Tomas On Thu, 2022-06-02 at 15:26 +0530, Minal Patil wrote: > Hello Tomas, > > Thanks Man. > It started working when compiled with your suggestions. > > Could it be an issue with openssl or with the compile ? > > Thanks, > Minal > > On Thu, Jun 2, 2022 at 2:32 PM Tomas Mraz wrote: > > This is crashing inside the getentropy call in glibc or the weak > > symbol > > binding does not work correctly for some reason. > > > > I'd suggest changing the line 359 of > > providers/implementations/rands/seeding/rand_unix.c > > from: > > # if !defined(__DragonFly__) && !defined(__NetBSD__) > > to: > > # if 0 > > > > That might help. > > > > Regards, > > Tomas Mraz > > > > On Thu, 2022-06-02 at 12:49 +0530, Minal Patil wrote: > > > here is the backtrace with debug. > > > Program received signal SIGILL, Illegal instruction. > > > 0x1004 in ?? () > > > Missing separate debuginfos, use: dnf debuginfo-install libgcc- > > 8.3.1- > > > 4.5.el8.ppc64le libstdc++-8.3.1-4.5.el8.ppc64le > > > (gdb) bt > > > #0 0x1004 in ?? () > > > #1 0x1006da60 in syscall_random (buf=0x104a3350, > > buflen=48) > > > at providers/implementations/rands/seeding/rand_unix.c:364 > > > #2 0x1006e3b4 in ossl_pool_acquire_entropy > > (pool=0x104a3300) > > > at providers/implementations/rands/seeding/rand_unix.c:646 > > > #3 0x10252ca0 in seed_src_generate (vseed=0x10446e90, > > > out=0x104a32c0 "", outlen=48, strength=0, > > > prediction_resistance=0, adin=0x7fffe340 "PoD\020", > > > adin_len=8) at providers/implementations/rands/seed_src.c:114 > > > #4 0x10253124 in seed_get_seed (vseed=0x10446e90, > > > pout=0x7fffe410, entropy=256, min_len=48, > > > max_len=4294967294, prediction_resistance=0, > > adin=0x7fffe340 > > > "PoD\020", adin_len=8) > > > at providers/implementations/rands/seed_src.c:204 > > > #5 0x1032a764 in get_entropy (drbg=0x10446f50, > > > pout=0x7fffe410, entropy=384, min_len=48, max_len=4294967294, > > > prediction_resistance=0) at > > > providers/implementations/rands/drbg.c:241 > > > #6 0x1032b140 in ossl_prov_drbg_instantiate > > > (drbg=0x10446f50, strength=0, prediction_resistance=0, > > > pers=0x10397a88 "OpenSSL NIST SP 800-90A > > > DRBG", perslen=29) > > > at providers/implementations/rands/drbg.c:451 > > > #7 0x1024eab8 in drbg_ctr_instantiate_wrapper > > > (vdrbg=0x10446f50, strength=0, prediction_resistance=0, pstr=0x0, > > > pstr_len=0, params=0x7fffe620) at > > > providers/implementations/rands/drbg_ctr.c:337 > > > #8 0x10127aa0 in evp_rand_instantiate_locked > > > (ctx=0x1042da90, strength=0, prediction_resistance=0, pstr=0x0, > > > pstr_len=0, params=0x7fffe620) at > > > crypto/evp/evp_rand.c:505 > > > #9 0x10127b50 in EVP_RAND_instantiate (ctx=0x1042da90, > > > strength=0, prediction_resistance=0, pstr=0x0, > > > pstr_len=0, params=0x7fffe620) at > > > crypto/evp/evp_rand.c:518 > > > #10 0x1003a988 in rand_new_drbg (libctx=0x0, > > > parent=0x1042da60, reseed_interval=256, > > > reseed_time_interval=3600) > > > at crypto/rand/rand_lib.c:595 > > > #11 0x1003ab58 in RAND_get0_primary (ctx=0x0) at > > > crypto/rand/rand_lib.c:642 > > > #12 0x1003add4 in RAND_get0_private (ctx=0x0) at > > > crypto/rand/rand_lib.c:706 > > > #13 0x10039cd4 in RAND_priv_bytes_ex (ctx=0x0, > > buf=0x10421f40 > > > "", num=64, strength=0) > > > at crypto/rand/rand_lib.c:333 > > > #14 0x100a7824 in bnrand (flag=PRIVATE, rnd=0x10420e70, > > > bits=512, top=1, bottom=1, strength=0, ctx=0x10420b90) > > > at crypto/bn/bn_rand.c:51 > > > #15 0x100a7db4 in BN_priv_rand_ex (rnd=0x10420e70, > > bits=512, > > > top=1, bottom=1, strength=0, ctx=0x10420b90) > > > at crypto/bn/bn_rand.c:122 > > > #16 0x100a6ae4 in probable_prime (rnd=0x10420e70, > > > bits=512, > > > safe=0, mods=0x10420f30, ctx=0x10420b90) > > > --Type for more, q to quit, c to continue without paging-- > >
Re: RSA_generate_key_ex is crashing when compiled on RHEL6 PPC and executed on RHEL8 for OpenSSL 3.0.1PPC
This is crashing inside the getentropy call in glibc or the weak symbol binding does not work correctly for some reason. I'd suggest changing the line 359 of providers/implementations/rands/seeding/rand_unix.c from: # if !defined(__DragonFly__) && !defined(__NetBSD__) to: # if 0 That might help. Regards, Tomas Mraz On Thu, 2022-06-02 at 12:49 +0530, Minal Patil wrote: > here is the backtrace with debug. > Program received signal SIGILL, Illegal instruction. > 0x1004 in ?? () > Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.3.1- > 4.5.el8.ppc64le libstdc++-8.3.1-4.5.el8.ppc64le > (gdb) bt > #0 0x1004 in ?? () > #1 0x1006da60 in syscall_random (buf=0x104a3350, buflen=48) > at providers/implementations/rands/seeding/rand_unix.c:364 > #2 0x1006e3b4 in ossl_pool_acquire_entropy (pool=0x104a3300) > at providers/implementations/rands/seeding/rand_unix.c:646 > #3 0x10252ca0 in seed_src_generate (vseed=0x10446e90, > out=0x104a32c0 "", outlen=48, strength=0, > prediction_resistance=0, adin=0x7fffe340 "PoD\020", > adin_len=8) at providers/implementations/rands/seed_src.c:114 > #4 0x10253124 in seed_get_seed (vseed=0x10446e90, > pout=0x7fffe410, entropy=256, min_len=48, > max_len=4294967294, prediction_resistance=0, adin=0x7fffe340 > "PoD\020", adin_len=8) > at providers/implementations/rands/seed_src.c:204 > #5 0x1032a764 in get_entropy (drbg=0x10446f50, > pout=0x7fffe410, entropy=384, min_len=48, max_len=4294967294, > prediction_resistance=0) at > providers/implementations/rands/drbg.c:241 > #6 0x1032b140 in ossl_prov_drbg_instantiate > (drbg=0x10446f50, strength=0, prediction_resistance=0, > pers=0x10397a88 "OpenSSL NIST SP 800-90A > DRBG", perslen=29) > at providers/implementations/rands/drbg.c:451 > #7 0x1024eab8 in drbg_ctr_instantiate_wrapper > (vdrbg=0x10446f50, strength=0, prediction_resistance=0, pstr=0x0, > pstr_len=0, params=0x7fffe620) at > providers/implementations/rands/drbg_ctr.c:337 > #8 0x10127aa0 in evp_rand_instantiate_locked > (ctx=0x1042da90, strength=0, prediction_resistance=0, pstr=0x0, > pstr_len=0, params=0x7fffe620) at crypto/evp/evp_rand.c:505 > #9 0x10127b50 in EVP_RAND_instantiate (ctx=0x1042da90, > strength=0, prediction_resistance=0, pstr=0x0, > pstr_len=0, params=0x7fffe620) at crypto/evp/evp_rand.c:518 > #10 0x1003a988 in rand_new_drbg (libctx=0x0, > parent=0x1042da60, reseed_interval=256, reseed_time_interval=3600) > at crypto/rand/rand_lib.c:595 > #11 0x1003ab58 in RAND_get0_primary (ctx=0x0) at > crypto/rand/rand_lib.c:642 > #12 0x1003add4 in RAND_get0_private (ctx=0x0) at > crypto/rand/rand_lib.c:706 > #13 0x10039cd4 in RAND_priv_bytes_ex (ctx=0x0, buf=0x10421f40 > "", num=64, strength=0) > at crypto/rand/rand_lib.c:333 > #14 0x100a7824 in bnrand (flag=PRIVATE, rnd=0x10420e70, > bits=512, top=1, bottom=1, strength=0, ctx=0x10420b90) > at crypto/bn/bn_rand.c:51 > #15 0x100a7db4 in BN_priv_rand_ex (rnd=0x10420e70, bits=512, > top=1, bottom=1, strength=0, ctx=0x10420b90) > at crypto/bn/bn_rand.c:122 > #16 0x100a6ae4 in probable_prime (rnd=0x10420e70, bits=512, > safe=0, mods=0x10420f30, ctx=0x10420b90) > --Type for more, q to quit, c to continue without paging-- > at crypto/bn/bn_prime.c:486 > #17 0x100a5c3c in BN_generate_prime_ex2 (ret=0x10420e70, > bits=512, safe=0, add=0x0, rem=0x0, cb=0x0, > ctx=0x10420b90) at crypto/bn/bn_prime.c:160 > #18 0x1003dce8 in rsa_multiprime_keygen (rsa=0x10411eb0, > bits=1024, primes=2, e_value=0x10411e70, cb=0x0) > at crypto/rsa/rsa_gen.c:191 > #19 0x1003e71c in rsa_keygen (libctx=0x0, rsa=0x10411eb0, > bits=1024, primes=2, e_value=0x10411e70, cb=0x0, > pairwise_test=0) at crypto/rsa/rsa_gen.c:437 > #20 0x1003d598 in RSA_generate_multi_prime_key > (rsa=0x10411eb0, bits=1024, primes=2, e_value=0x10411e70, cb=0x0) > at crypto/rsa/rsa_gen.c:71 > #21 0x1003d434 in RSA_generate_key_ex (rsa=0x10411eb0, > bits=1024, e_value=0x10411e70, cb=0x0) > at crypto/rsa/rsa_gen.c:46 > #22 0x10003ae8 in generate_key (keysize=1024, > pub_key=0x7fffef48, pri_key=0x7fffef50) at generatekey.c:25 > #23 0x000010003da8 in main () at generatekey.c:74 > > On Thu, Jun 2, 2022 at 12:06 PM Tomas Mraz wrote: > > Can you please try to build the openssl with debug information (-d > > on > > Configure command line)? To see whether the backtrace will contain > > more > > information. > > > > T
Re: RSA_generate_key_ex is crashing when compiled on RHEL6 PPC and executed on RHEL8 for OpenSSL 3.0.1PPC
Can you please try to build the openssl with debug information (-d on Configure command line)? To see whether the backtrace will contain more information. Tomas Mraz On Thu, 2022-06-02 at 11:09 +0530, Minal Patil wrote: > Hello All, > > I am trying to use RSA_generate_key_ex function to generate the RSA > key pairs on RHEL 7.2 PPCle. I am observing crash when i link the > source code with Openssl 3.0 whereas same works if i link with > Openssl 1.0.2 > > Below is configure command used for compiling openssl > ./Configure no-shared threads --prefix=/home/testuser/OpenSSL/Build - > -openssldir=/home/testuser/OpenSSL/Build --libdir=lib linux-ppc64le - > Wa,--noexecstack > > I am attaching the source code I am using for reference. > Below is stack trace observed > > Program received signal SIGILL, Illegal instruction. > #0 0x1004 in ?? () > #1 0x1005afdc in ossl_pool_acquire_entropy () > #2 0x101fed14 in seed_get_seed () > #3 0x102be844 in get_entropy () > #4 0x102bee8c in ossl_prov_drbg_instantiate () > #5 0x101f9b2c in drbg_ctr_instantiate_wrapper () > #6 0x100ff2e0 in EVP_RAND_instantiate () > #7 0x10031c18 in rand_new_drbg () > #8 0x10032bd0 in RAND_get0_primary () > #9 0x100333f8 in RAND_get0_private () > #10 0x10033558 in RAND_priv_bytes_ex () > #11 0x100926cc in BN_priv_rand_ex () > #12 0x10090b78 in BN_generate_prime_ex2 () > #13 0x10035a90 in RSA_generate_multi_prime_key () > #14 0x100361b4 in RSA_generate_key_ex () > #15 0x100048b8 in generate_key (keysize=1024, > pub_key=0x7fffef38, pri_key=0x7fffef40) at generatekey.c:25 > #16 0x10004b78 in main () at generatekey.c:74 > > I am compiling both 1.0.2j and 3.0 with same configure command and on > the same machine(i.e. RHEL 7). > > Any suggestion or pointer would be highly helpful. -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_pairwise_check(3) fails with error:0300009A:digital envelope routines::no key set
On Sat, 2022-05-28 at 19:12 -0700, Kip Warner wrote: > Hey list, > > I am in the process of porting some RSA related code that used > OpenSSL > 1.1.1 to the newer 3.0 API. A lot of the functions I was using are > now > deprecated. I've tried to follow the migration guide as best I can. > > Right now I am having an issue generating an RSA key pair: > > https://pastebin.com/jbLdqUdv > > Note that the call to EVP_PKEY_pairwise_check(3) fails on L66 with > "error:039A:digital envelope routines::no key set". This error > string was set by OpenSSL internally. > > I'm not sure exactly what I'm doing wrong. All I want to do is > generate > the RSA key pair and then verify that this was done correctly. For the pairwise check, you need to initialize a new EVP_PKEY_CTX context with EVP_PKEY_CTX_new_from_pkey(). You cannot reuse the key generation context. -- Tomáš Mráz, OpenSSL
Re: openssl 3.0.3 minor patches to build on SCO OpenServer 5.0.7
On Wed, 2022-05-18 at 16:37 -0500, Kevin R. Bulgrien wrote: > > From: "Matt Caswell" > > Subject: Re: openssl 1.1.1 minor patches to build on SCO OpenServer > > 5.0.7 > > > > Hi Kevin, > > > > The patch in s_socket.c is likely to be acceptable. It looks > > reasonable > > to me, it may well be useful on other systems and can probably be > > described as a bug fix. > > > > The other changes require the new OPENSSL_SYS_SCO5 define and are > > essentially adding support for a new platform into the codebase. > > > > We have a couple of policies which describe acceptable changes in > > this area. > > > > Our platform policy says: > > > > "Support for a new platform should only be added if it is being > > adopted > > as a primary, secondary or community platform." > > > > https://www.openssl.org/policies/platformpolicy.html > > > > Essentially this means that someone has to volunteer to be a > > community > > maintainer of the platform moving forwards, i.e. they are the > > contact > > point for any bug fixes/problems that may arise on that platform. > > You > > don't need to be a committer on the project to be a platform > > maintainer. > > Interestingly, openssl 1.1.1o already has support for this platform, > but > it is not up-to-date since I need these patches: With that on mind I'd say we could treat this as a bug fix. > > This is interesting, and I suppose subject to interpretation > differences. > My patches entirely involve configuration changes. I.e. They ONLY > affect > pre-processor directives. In my opinion, pre-processor directives > are > not code. I suppose this response means the project interprets code > as > source code files? If so, then a clarification of terms in the > documents > linked might be in order. We interpret any changes in the .c, .h, and similar files as source code changes. > > As far as a community maintainership goes, in my current employment > situation, > it is in my interest to build openssl releases as they come out. As > long as > maintainership is primarily related to build issues, I don't really > have a > problem with doing this. The main concern I would have is that I do > not have > an in-depth knowledge of the openssl code-base, so if maintainership > involves > code issues that pretty much any platform might encounter because the > code is > the same for them, I cannot claim to commensurate experience along > those lines. Yeah, this is mostly about build fixes. Of course if there is a run- time issue reported that affects only your platform we would have to cooperate on the fix there as well, but I would not expect many of these. -- Tomáš Mráz, OpenSSL
Re: AES and EVP_CIPHER question
The EVP_CIPHER_CTX_set_padding(ctx, 0) must be called after the
EVP_CipherInit() to have an effect.
Also what is the AST_CRYPTO_AES_BLOCKSIZE value? Is it in bits (i.e,
128)?
Also res should be initialized to -1 so you do not return uninitialized
value on error.
Tomas Mraz
On Fri, 2022-05-13 at 09:49 -0600, Philip Prindeville wrote:
> Hi,
>
> I'm trying to rewrite some legacy AES_* code to use EVP_CIPHER_* so
> it's forward compatible into 3.x.
>
> My code, in a nutshell, looks like:
>
> static int evp_cipher_aes_decrypt(const unsigned char *in, unsigned
> char *out, unsigned inlen, const ast_aes_decrypt_key *key)
> {
> EVP_CIPHER_CTX *ctx;
> int res, outlen, finallen;
> unsigned char final[AST_CRYPTO_AES_BLOCKSIZE / 8];
>
> if ((ctx = EVP_CIPHER_CTX_new()) == NULL) {
> return -1;
> }
>
> EVP_CIPHER_CTX_set_padding(ctx, 0);
>
> do {
> if ((res = EVP_CipherInit(ctx, EVP_aes_128_ecb(),
> key->raw, NULL, 0)) <= 0) {
> break;
> }
> if ((res = EVP_CipherUpdate(ctx, out, , in,
> inlen)) <= 0) {
> break;
> }
> /* for ECB, this is a no-op */
> if ((res = EVP_CipherFinal(ctx, final, )) <=
> 0) {
> break;
> }
>
> res = outlen;
> } while (0);
>
> EVP_CIPHER_CTX_free(ctx);
>
> return res;
> }
>
> It's ECB, so there's no IV. Or padding. The block size and key size
> are both 128 bits.
>
> One thing I noticed right away is that EVP_CipherUpdate() returns 1,
> and sees "outlen" to zero.
>
> And then EVP_CipherFinal() returns 0, and sets "finallen" to zero.
>
> What's wrong with this code?
>
> I'm trying to write "naive" code that counts on the primitives to
> indicate how much resultant output is generated for the input I've
> given (yes, I know that it's 1:1 in the case of ECB, but I shouldn't
> have to hard-code that in case I want to use the same code with
> multiple block modes).
>
> The function is supposed to return <= 0 on error, otherwise the
> number of bytes decrypted into "out" on success.
>
> Thanks,
>
> -Philip
>
--
Tomáš Mráz, OpenSSL
Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.
Please look at demos/signature/rsa_pss_direct.c If you want to use the old PKCS1 v1.5 padding then just replace RSA_PKCS1_PSS_PADDING with RSA_PKCS1_PADDING. Tomas On Thu, 2022-05-05 at 10:35 -0600, Philip Prindeville wrote: > Bonjour. Et milles mercis. > > That was helpful. > > One more question: if I want to reproduce RSA_sign() (and > RSA_verify()) using evp_key_sign() and evp_key_verify() then I'll > need add code to do the ASN.1 marshaling, right? There's no > convenience function to do that (seems like an oversight if that's > the case)? > > -Philip > > > > On May 4, 2022, at 3:45 AM, Erwann Abalea > > wrote: > > > > Bonjour, > > > > The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 > > padding for signature operations. > > PKCS#1v1.5 is rewritten in RFC2313. > > > > Using the command line tool, you can reproduce this: > > > > echo -n "Mary had a little lamb." > datatosign > > > > either one of the following can be used to sign data: > > openssl dgst -sha1 -sign tests/keys/rsa_key1.key datatosign > > > signing > > openssl pkeyutl -inkey tests/keys/rsa_key1.key -in <(openssl dgst > > -sha1 -binary datatosign) -sign -pkeyopt digest:sha1 > signing > > > > and you can display the signature either way (this will not > > "verify", it will only perform the RSA verify operation with > > PKCS#1v1.5 padding, without checking the validity or even if what > > has been signed is a DigestInfo structure, and output the result of > > the RSA operation): > > openssl rsautl -verify -inkey tests/keys/rsa_key1.pub -pubin -in > > signing -asn1parse > > openssl pkeyutl -verifyrecover -inkey tests/keys/rsa_key1.pub - > > pubin -in signing -asn1parse > > > > or you can actually verify the thing without displaying the result > > of the RSA verify crypto operation: > > openssl pkeyutl -verify -inkey tests/keys/rsa_key1.pub -pubin -in > > <(openssl dgst -sha1 -binary datatosign) -sigfile signing -pkeyopt > > digest:sha1 > > openssl dgst -verify tests/keys/rsa_key1.pub -signature signing - > > sha1 datatosign > > > -- Tomáš Mráz, OpenSSL
Re: 3.0.3 - EVP_EC_gen() segfault without init
Fix is here:
https://github.com/openssl/openssl/pull/18247
On Thu, 2022-05-05 at 07:54 +0200, Tomas Mraz wrote:
> Yes, this is unfortunately a bug in 3.0.3 release. Calling
> OPENSSL_init_crypto should not be necessary.
>
> Tomas Mraz
>
> On Wed, 2022-05-04 at 21:58 +0200, Klaus Keppler wrote:
> > Hello,
> >
> > yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of
> > our
> > unit tests crash.
> >
> > I've boiled the problem down to the following example code:
> >
> > ---cut---
> > #include
> > #include
> > #include
> >
> > int main(int argc, const char *argv[]) {
> > //OPENSSL_init_crypto(0, NULL);
> > if (! EVP_EC_gen("P-384")) return -1;
> > return 0;
> > }
> > ---/cut---
> >
> > Compile with:
> >
> > gcc -Wall -Werror -pedantic -o test test.c -lcrypto
> >
> > With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a
> > segmentation fault during a string comparison within
> > EVP_PKEY_Q_keygen
> > (EVP_EC_gen is just a macro).
> >
> > I assume that the curve names are not properly initialized, when you
> > uncomment the call to "OPENSSL_init_crypto()", everything works just
> > fine.
> >
> > The documentation [1] of OPENSSL_init_crypto() states that explicit
> > initialization is not required. Man page of EVP_EC_gen [2] says
> > nothing
> > about initialization.
> > Considering that 3.0.3 is only a minor update and 3.0.2 worked as
> > expected, we might have hit a bug. If this (above) is "just" a usage
> > error, the documentation should describe in which cases an explicit
> > initialization is required.
> >
> > Anyway, thank you for all your efforts!
> >
> > Best regards
> >
> > -Klaus Keppler
> >
> >
> > [1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
> > [2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html
>
--
Tomáš Mráz, OpenSSL
Re: 3.0.3 - EVP_EC_gen() segfault without init
Yes, this is unfortunately a bug in 3.0.3 release. Calling
OPENSSL_init_crypto should not be necessary.
Tomas Mraz
On Wed, 2022-05-04 at 21:58 +0200, Klaus Keppler wrote:
> Hello,
>
> yesterday we updated OpenSSL from 3.0.2 to 3.0.3, what made some of
> our
> unit tests crash.
>
> I've boiled the problem down to the following example code:
>
> ---cut---
> #include
> #include
> #include
>
> int main(int argc, const char *argv[]) {
> //OPENSSL_init_crypto(0, NULL);
> if (! EVP_EC_gen("P-384")) return -1;
> return 0;
> }
> ---/cut---
>
> Compile with:
>
> gcc -Wall -Werror -pedantic -o test test.c -lcrypto
>
> With OpenSSL 3.0.2 this runs just fine, with OpenSSL 3.0.3 we get a
> segmentation fault during a string comparison within
> EVP_PKEY_Q_keygen
> (EVP_EC_gen is just a macro).
>
> I assume that the curve names are not properly initialized, when you
> uncomment the call to "OPENSSL_init_crypto()", everything works just
> fine.
>
> The documentation [1] of OPENSSL_init_crypto() states that explicit
> initialization is not required. Man page of EVP_EC_gen [2] says
> nothing
> about initialization.
> Considering that 3.0.3 is only a minor update and 3.0.2 worked as
> expected, we might have hit a bug. If this (above) is "just" a usage
> error, the documentation should describe in which cases an explicit
> initialization is required.
>
> Anyway, thank you for all your efforts!
>
> Best regards
>
> -Klaus Keppler
>
>
> [1] https://www.openssl.org/docs/man3.0/man3/OPENSSL_init_crypto.html
> [2] https://www.openssl.org/docs/man3.0/man3/EVP_EC_gen.html
--
Tomáš Mráz, OpenSSL
Re: openssl 3.0 fips provider and low level APIs
All the providers can use the low-level APIs internally to implement crypto algorithms. The FIPS provider however includes all the low level implementations as a separately built and statically linked code. That means you cannot use the low-level calls in an application and still be FIPS compliant as the low-level API calls called from an application are implemented by the libcrypto library and not the FIPS provider. Tomas Mraz, OpenSSL On Tue, 2022-05-03 at 10:12 -0500, Joy Latten wrote: > Hi, > I understand that low-level APIs have been deprecated in version 3. I > have been playing some with the fips provider trying to understand > the config options to use with it. I noticed that the fips provider > source code includes a few low level APIs like SHA256_Init(). > Is it correct to conclude that although use of the low level APIs are > deprecated, perhaps for a grace period for transitioning they are > permitted in the fips provider? > > Thanks for all help! > regards, > Joy > > -- Tomáš Mráz, OpenSSL
Re: Openssl 3.0.2- Build error - catgets_failed
Maybe https://github.com/openssl/openssl/pull/18136 could help you? Regards, Tomas Mraz On Thu, 2022-04-21 at 16:49 +, Gaurav Mittal11 wrote: > I tried same commands and same setting with root access, seems like I > pass that error. > Can you help why its not giving any error and not even generating > crypto/chacha/libcrypto-lib-chacha-ia64.o file > > CC="/opt/aCC/bin/aCC" perl crypto/chacha/asm/chacha-ia64.pl "void" -I. > -Iinclude -Iproviders/common/include - > Iproviders/implementations/include +Z -Ae +DD64 +Olit=all -z +DD64 -mt > -DB_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/opt/openssl/3.0.2\"" - > DENGINESDIR="\"/opt/openssl/3.0.2/lib/hpux64/engines-3\"" - > DMODULESDIR="\"/opt/openssl/3.0.2/lib/hpux64/ossl-modules\"" - > D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -D_XOPEN_SOURCE - > D_XOPEN_SOURCE_EXTENDED -D_HPUX_ALT_XOPEN_SOCKET_API -DNDEBUG +DD64 -mt > -DAES_ASM -DGHASH_ASM -DOPENSSL_CPUID_OBJ -DPOLY1305_ASM -DSHA1_ASM - > DSHA256_ASM -DSHA512_ASM crypto/chacha/chacha-ia64.S ##This generate > .S file > > /opt/aCC/bin/aCC -I. -Iinclude -Iproviders/common/include - > Iproviders/implementations/include -DAES_ASM -DGHASH_ASM - > DOPENSSL_CPUID_OBJ -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > +Z -Ae +DD64 +Olit=all -z +DD64 -mt -DB_ENDIAN -DOPENSSL_PIC - > DOPENSSLDIR="\"/opt/openssl/3.0.2\"" - > DENGINESDIR="\"/opt/openssl/3.0.2/lib/hpux64/engines-3\"" - > DMODULESDIR="\"/opt/openssl/3.0.2/lib/hpux64/ossl-modules\"" - > D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -D_XOPEN_SOURCE - > D_XOPEN_SOURCE_EXTENDED -D_HPUX_ALT_XOPEN_SOCKET_API -DNDEBUG +DD64 -mt > -c -o crypto/chacha/libcrypto-lib-chacha-ia64.o crypto/chacha/chacha- > ia64.S ## this is not generating .o file > > I have cut below command, it is trying to put all 100 .o file into one > static librray and give error. > > ar qc libcrypto.a crypto/aes/libcrypto-lib-aes-ia64.o > crypto/aes/libcrypto-lib-aes_cbc.o crypto/cast/libcrypto-lib-c_skey.o > crypto/chacha/libcrypto-lib-chacha-ia64.o > > ar: could not open crypto/chacha/libcrypto-lib-chacha-ia64.o > gmake[1]: *** [Makefile:6800: libcrypto.a] Error 1 > gmake[1]: Leaving directory '/home/infod3/tools/openssl-3.0.2' > gmake: *** [Makefile:1680: build_sw] Error 2 > > -- > Gaurav Mittal > > -Original Message- > From: openssl-users On Behalf Of > Michael Wojcik > Sent: 21 April 2022 09:57 PM > To: openssl-users@openssl.org > Subject: [EXTERNAL] RE: Openssl 3.0.2- Build error - catgets_failed > > > From: Gaurav Mittal11 > > Sent: Thursday, 21 April, 2022 09:55 > > > > Yes, I have gone through internet search, I have not found any clue. > > > > Still same error even after setting LANG to C > > > > Yes, HP is kind of legacy server and very less help available on > > internet. > > > > Any more suggestions would be helpful. > > All I can say at the moment is that we haven't seen this with OpenSSL > 1.1.1n on HP-UX 11i. We haven't tried building any 3.x versions on that > platform yet (and maybe we won't have to, which would be great). > > Can you post the failing .s file somewhere? Maybe looking at it will > provide some clue. Those messages look like they might be syntax > cascade errors, so it's possible the Perl script tossed something bogus > in there. > > We do have HP-UX assembler expertise here (in the compiler team, since > we've had HP-UX support since the PA-RISC days at least, quite possibly > since the 68K/FOCUS days) - not just Itanium experience, that is, but > some working knowledge of the as program on that platform. I've battled > through a bit of Itanium assembly now and then myself. So I may be able > to find someone who can figure out where it's gone wrong. > -- Tomáš Mráz, OpenSSL
Re: OpenSSL 3.0.2 PKCS12_parse Failure
How do you load the legacy provider? Into which library context? It needs to be loaded into the default (NULL) library context for the PKCS12_parse() function. The workaround would be to not use the certificate/key pair for the server in the PKCS12 format but in the PEM format with separate key and certificate files. Tomas Mraz On Fri, 2022-04-01 at 18:14 +, vchiliquinga--- via openssl-users wrote: > Hello, > > Connection between a Openssl 3.0.2 server and a 1.1.1g client is > proving to be unsuccessful. > > According to the logs collected we seem to be having an issue with > the loading of the legacy providers. > We are loading both the default and legacy providers programmatically > as per the steps outlined in the Wiki for OpenSSL 3.0 – 6.2 > Providers. > > We are seeing the following error.. > > error:0308010C:digital envelope > routines:inner_evp_generic_fetch:unsupported:crypto\evp\evp_fetch.c:3 > 46:Global default library context, Algorithm (RC2-40-CBC : 0), > Properties () > PKCS12_parse() failed = 183. (Using GetLastError from > errhandlingapi.h, the 183 error code is obtained) > > Worth mentioning that we are only seeing this issue occur when the > server is a Windows 2012 server. > > Thank you, > Victor C. -- Tomáš Mráz, OpenSSL
Re: Autoconf and detecting if bio_st is defined or not
The bio_st structure is private since 1.1.0 release. So one option is to check if the OPENSSL_VERSION >= 0x1010 Tomas On Fri, 2022-03-25 at 18:33 -0600, Philip Prindeville wrote: > Hi, > > I was wondering if there was some sort of sentinel variable that > tells us if is exporting access to the bio_st > structure, or not. > > Thanks, > > -Philip > -- Tomáš Mráz, OpenSSL
Re: Certificate, "ecdsa_with_SHA3-512" signature algorithm
On Mon, 2022-03-28 at 09:24 +0300, Mib wrote: > Hi, I am trying to create a ECC certificate with ecdsa_with_SHA3-512 > signature algorithm. > > But I am having the below issue When I try to verify it with the > X509_Verify api. > "error:068000C7:asn1 encoding routines::unknown signature algorithm" > > As I understand, "ecdsa_with_SHA3-512" signature nid has not been > defined yet in the > "nid_triple sigoid_srt[]" array. > > I am new to openssl, does it mean it is not supported yet ? Thank > you. Regards Yes, you're correct. This hash/signature algorithm combination is not supported by any of the current releases by itself. However with the 3.0 release this combination could be supported by an external provider. -- Tomáš Mráz, OpenSSL
Re: Openssl 0.9.8 to 1.0.2u - HP-UX- After installation and softlink created -console does not connect
0.9.8 and 1.0.2 versions are not binary compatible. So if your SSH server is built against the 0.9.8 version and it expects to be loading the libcrypto.so from that version it will not work against the libcrypto.so from 1.0.2. The SSH server has to be built against the 1.0.2 version to work with it. Tomas Mraz On Fri, 2022-03-25 at 09:54 +, Gaurav Mittal11 wrote: > Hi, > > I have build and installed 1.0.2u version but when I have change > below softlink point to 1.0.2u from 0.9.8, console from putty stopped > connecting. > This is something related to openssl.cnf or we need new certs and > private keys. > Please help on same or share any documentation on it. > > Note – 3.0.2 openssl version gives lot of compilation error, this > 1.0.2u openssl version I have got from HP-UX website. > http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/openssl-1.0.2u/ > > Server details - > HP-UX hvdnd73a B.11.31 U ia64 1869095592 unlimited-user license > > dr-xr-xr-x 2 bin bin 8192 Apr 30 2008 certs > dr-xr-xr-x 2 bin bin 96 Apr 30 2008 private > dr-xr-xr-x 4 bin bin 96 Jan 11 2012 fips > dr-xr-xr-x 9 bin bin 8192 Mar 15 05:08 0.9.8 > lrwxr-xr-x 1 root sys 9 Mar 15 06:14 man -> > 0.9.8/man > lrwxr-xr-x 1 root sys 9 Mar 15 06:14 src -> > 0.9.8/src > lrwxr-xr-x 1 root sys 17 Mar 15 06:14 openssl.cnf > -> 0.9.8/openssl.cnf > lrwxr-xr-x 1 root sys 12 Mar 15 06:14 README -> > 0.9.8/README > lrwxr-xr-x 1 root sys 9 Mar 15 06:14 doc -> > 0.9.8/doc > lrwxr-xr-x 1 root sys 13 Mar 15 06:14 include -> > 0.9.8/include > lrwxr-xr-x 1 root sys 9 Mar 15 06:14 bin -> > 0.9.8/bin > lrwxr-xr-x 1 root sys 10 Mar 15 06:14 misc -> > 0.9.8/misc > lrwxr-xr-x 1 root sys 9 Mar 15 06:14 lib -> > 0.9.8/lib > drwxr-xr-x 7 root sys 8192 Mar 15 06:42 1.0.2u > > > Following Configuration used for configuration, complication/build > and install – > > export CC=/opt/aCC/bin/aCC > export CFLAGS="+DD64 -mt" > export CPPFLAGS="+DD64 -mt" > export LDFLAGS="-L/usr/lib/hpux64/" > export PATH=/usr/local/bin:/usr/contrib/imake/bin:$PATH > ./Configure --prefix=/opt/openssl-1.0.2u -- > openssldir=/opt/openssl/1.0.2u --shared hpux64-ia64-cc > gmake depend > gmake > gmake install > > > > -- > Gaurav Mittal > -- Tomáš Mráz, OpenSSL
Re: Porting asterisk to Openssl-3.0
On Thu, 2022-03-24 at 22:19 -0600, Philip Prindeville wrote: > Hi, > > I'm incrementally trying to port asterisk to Openssl 3.0. > > First thing I'm trying to do is wean the code off of the RSA_* > functions, and use generic EVP_PKEY_* functions instead. > > Most of it is fairly straightforward (it seems), but I've been > looking for examples of reading PEM public and private keys into > EVP_PKEY's. > > Currently asterisk uses 1.1.0 or later, so I'm trying to figure make > the code build first under 1.1.0 dropping the functions that get > deprecated in 3.0, and then rewriting (in a separate PR) whatever the > delta is between 1.1.0 and 3.0. > > In 3.0, I can find examples of reading PEM into a public RSA key such > as: > > https://www.openssl.org/docs/manmaster/man3/OSSL_DECODER_from_bio.html > > Though I didn't understand why selection is > OSSL_KEYMGMT_SELECT_KEYPAIR and not OSSL_KEYMGMT_SELECT_PUBLIC or > _PRIVATE. > > What is the way to read a PEM file (as a FILE * or BIO *) into a > EVP_PKEY canonically in 1.1.0? > It's PEM_read_bio_PrivateKey and PEM_read_PrivateKey - these functions aren't deprecated in 3.0 so you can use them there as well. It's actually a better idea to use these than the decoder API directly as they can support legacy functionality (engine based keys). -- Tomáš Mráz, OpenSSL
Re: run-checker NO DGRAM and test cases
On Fri, 2022-03-18 at 05:24 -0400, Michael Richardson wrote:
>
> Tomas Mraz wrote:
> >> Should the test *ALSO* ifdef itself out if OPENSSL_NO_DGRAM is
> >> defined?
>
> > No, that's not necessary as they won't be built at all with the
> > build.info change above.
>
> I didn't find this to be true. The source file still got built, and
> linked,
> and that failed.
>
> I had to add an ifdef to the source file. Please see:
> https://github.com/mcr/openssl/commit/2ae78377969d939d5eedc39ca0c22d914f739e93
>
> Perhaps my use of:
> IF[{- !$disabled{dgram} -}]
>
> is wrong in some way.
You've included the bio_write_test and bio_read_test also on the bare
PROGRAMS{noinst} assignment. You need to remove them from there.
Interestingly the http_test is included there as well which means it
will also be always compiled.
--
Tomáš Mráz, OpenSSL
Re: run-checker NO DGRAM and test cases
On Thu, 2022-03-17 at 10:17 -0400, Michael Richardson wrote:
>
> Tomas Mraz wrote:
> >> I figured out that this means that ./Configure should have
> "no-dgram"
> >> appended to it. That seems to result in OPENSSL_NO_DGRAM
> being
> >> defined.
> >>
> >> My test case naturally does not compile for that.
> >>
> >> Should my test case just be surrounded by #ifndef
> OPENSSL_NO_DGRAM
> >> from top to bottom (leaving...?), or is there something more
> >> sophisticated that should go into build.info in order to skip
> the test
> >> in that configuration?
>
> > Please look at the other examples in tests/build.info - there
> are
> > things disabled for no-sock and other stuff. But you'll also
> need to
> > skip the test in the perl test recipe.
>
> I thought it was shell script, but now that I look more at it, I
> guess it is
> a custom DSL.
>
> IF[{- !$disabled{dgram} -}]
> PROGRAMS{noinst}=bio_write_test
> ENDIF
> SOURCE[bio_write_test]=bio_write_test.c
> INCLUDE[bio_write_test]=../include ../apps/include
> DEPEND[bio_write_test]=../libcrypto libtestutil.a
>
> Should I repeat the test for the two programs, or should I group into
> a
> single IF for both programs?
>
> i.e.
> IF[{- !$disabled{dgram} -}]
> PROGRAMS{noinst}=bio_write_test bio_read_test
> ENDIF
Grouping them is fine.
> I guess maybe the tests could be named with dgram in the file name,
> since that's all they do.
I guess that we could later add more testcases there for other
bio_write/bio_read functions? Of course then we would have to switch
from disabling them in build.info to ifdefs.
> Should the test *ALSO* ifdef itself out if
> OPENSSL_NO_DGRAM is defined?
No, that's not necessary as they won't be built at all with the
build.info change above.
> It already does:
>
> #if defined(_WIN32)
> int setup_tests(void)
> {
> return 1;
> }
> ...
>
>
--
Tomáš Mráz, OpenSSL
Re: run-checker NO DGRAM and test cases
On Wed, 2022-03-16 at 16:20 -0400, Michael Richardson wrote: > > One of the run checkers is marked "no dgram". > > https://github.com/mcr/openssl/runs/5563998914?check_suite_focus=true > > I figured out that this means that ./Configure should have "no-dgram" > appended to it. That seems to result in OPENSSL_NO_DGRAM being > defined. > > My test case naturally does not compile for that. > > Should my test case just be surrounded by #ifndef OPENSSL_NO_DGRAM > from top > to bottom (leaving...?), or is there something more sophisticated > that should go into > build.info in order to skip the test in that configuration? Please look at the other examples in tests/build.info - there are things disabled for no-sock and other stuff. But you'll also need to skip the test in the perl test recipe. -- Tomáš Mráz, OpenSSL
Re: DSA signatures in OpenSSL 3.0
On Mon, 2022-03-14 at 08:58 -0300, Richard Dymond wrote: > On Mon, 14 Mar 2022 at 04:52, Tomas Mraz wrote: > > The DSA_SIG_* functions are not deprecated including the i2d and > > d2i > > functions. So you can use d2i_DSA_SIG to decode the DER produced by > > the > > EVP_DigestSign() and then obtain the r and s values from the > > DSA_SIG. > > > > > Thank you, that works! For some reason it had escaped my notice that > that the DSA_SIG_* functions are not deprecated. > > By the way, the reason I need to get the 'r' and 's' values from the > DSA signature is that I am encoding them one after the other as 160- > bit unsigned integers, in network byte order, as required by SSH and > described in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do > this encoding I am calling BN_bn2bin() twice to write 'r' followed by > 's' at the appropriate locations in a 40-byte buffer. By any chance, > does OpenSSL 3.0 provide any support for encoding a DSA signature > like this from a DSA_SIG (i.e. without having to extract 'r' and 's' > first and then use BN_bn2bin())? No, there is no such function. However there is not much overhead in doing the two BN_bn2bin calls (should those be BN_bn2binpad actually?) once you already have a DSA_SIG object. > Richard > > [1] https://datatracker.ietf.org/doc/html/rfc4253#section-6.6 -- Tomáš Mráz, OpenSSL
Re: DSA signatures in OpenSSL 3.0
On Fri, 2022-03-11 at 15:21 -0400, Richard Dymond wrote: > Hi > > I recently migrated an application from OpenSSL 1.1.1 to OpenSSL 3.0, > and I'm wondering how best to handle DSA signatures - specifically, > the 'r' and 's' values - in OpenSSL 3.0. > > In OpenSSL 1.1.1, it was pretty easy: > > DSA_do_sign() - gets you a DSA_SIG > DSA_SIG_get0() - gets you the 'r' and 's' values from the DSA_SIG > > This still works in OpenSSL 3.0, but the DSA_* functions are > deprecated, and so to avoid that I'm doing this instead: > > EVP_DIgestSign() - gets you a DER-encoded signature blob > BN_bin2bn() - grabs 'r' or 's' from the signature blob, so long as > you point it at the right place in the blob > > Which seems very cumbersome, and requires intimate knowledge of the > layout of the signature blob. > > Is there a better way to get the 'r' and 's' values from a DSA > signature in OpenSSL 3.0 without using deprecated functions? The DSA_SIG_* functions are not deprecated including the i2d and d2i functions. So you can use d2i_DSA_SIG to decode the DER produced by the EVP_DigestSign() and then obtain the r and s values from the DSA_SIG. -- Tomáš Mráz, OpenSSL
Re: Multi root certs support
Yes, this is a fully supported scenario. You can even test it with the openssl s_server command - use -cert, - key, and -cert_chain for the first certificate and -dcert, -dkey, and - dcert_chain with the second one. Tomas Mraz On Fri, 2022-03-11 at 13:19 +, Kris Kwiatkowski wrote: > Hello, > > On my server, I would like to support 2 certificate chains. One > chain > would be signed with RSA and the other with EdDSA (so 2 complatelly > different > chains with 2 root certificates). Then, let say, new clients that > support > EdDSA will choose to use it, otherwise I'll serve RSA for everybody > else. > > I think a protocol can support such setup (only interested in > TLSv1.3), but > is that feature implementated by OpenSSL? > > Kind regards, > Kris > > -- Tomáš Mráz, OpenSSL
Re: [EXTERNAL] Re: bignum to evp key
Srinivas, please understand, that the public and private keys in the shared key will come from different party. The private key is the one you've just generated and the public key will be received in some encoded format from the other peer. I gave you below the methods how you encode the public key so it can be sent to the other peer of the exchange. When receiving the encoded public key from the other peer you'll either use OSSL_DECODER to decode the encoded public key or create a new domain parameters EVP_PKEY and use EVP_PKEY_set1_encoded_public_key() to set the public key data on that key. Tomas On Fri, 2022-03-04 at 09:59 +, Srinivas, Saketh (c) wrote: > I need to compute the shared key for DH. I have to extract public and > private keys from evpkeypair. But the function EVP_PKEY_get_bn_param > extracts as a big num. I need them as evp_pkey. > > > From: Tomas Mraz > Sent: Friday, March 4, 2022 3:24 PM > To: Srinivas, Saketh (c) > Cc: openssl-users > Subject: Re: [EXTERNAL] Re: bignum to evp key > This is for some kind of artificial example code, isn't it? Because > in > a real world application of a DH/ECDH key exchange you will always > have > a private key for the local peer and a public key for the remote > peer. > > To transfer the public key to the remote side you will need to > somehow > encode it. Either with an OSSL_ENCODER, or via > EVP_PKEY_get1_encoded_public_key depending on the communication > protocol. > > When encoding the key with OSSL_ENCODER you can specify with the > OSSL_ENCODER_CTX_new_for_pkey() via the selection parameter that you > want to encode just the public key or the public key with domain > parameters. > > Tomas Mraz > > On Fri, 2022-03-04 at 09:43 +, Srinivas, Saketh (c) wrote: > > i need them to create ctx = EVP_PKEY_CTX_new(priv_key, NULL) > > > > and then add the peer to ctx as EVP_PKEY_derive_set_peer( ctx, > > pub_key ) > > > > both should be evp_pkey format. > > From: Tomas Mraz > > Sent: Friday, March 4, 2022 2:56 PM > > To: Srinivas, Saketh (c) ; > > openssl-users@openssl.org > > Subject: [EXTERNAL] Re: bignum to evp key > > There is no straightforward way to do that. What do you want to do > > with > > the public and private EVP_PKEYs? > > > > Tomas > > > > On Fri, 2022-03-04 at 07:28 +, Srinivas, Saketh (c) wrote: > > > HI, > > > > > > i have EvpKeyPair from GenerateEvpKeyPair(dh_p, dh_g, > > > ) > > > > > > How can I get the public key and priv key from keypair. The below > > > function gives them as bignums but not Evp_pkey. > > > > > > (EVP_PKEY_get_bn_param(pEvpKeyPair, OSSL_PKEY_PARAM_PUB_KEY, > > > ) > > > > > > I want pub key and priv keys as evp_pkey. > > > > > > Thanks, > > > Saketh. > > > > > > > > > Notice: This e-mail together with any attachments may contain > > > information of Ribbon Communications Inc. and its Affiliates that > > > is > > > confidential and/or proprietary for the sole use of the intended > > > recipient. Any review, disclosure, reliance or distribution by > > > others > > > or forwarding without express permission is strictly prohibited. > > > If > > > you > > > are not the intended recipient, please notify the sender > > > immediately > > > and then delete all copies, including any attachments. > > > -- Tomáš Mráz, OpenSSL
Re: [EXTERNAL] Re: bignum to evp key
This is for some kind of artificial example code, isn't it? Because in a real world application of a DH/ECDH key exchange you will always have a private key for the local peer and a public key for the remote peer. To transfer the public key to the remote side you will need to somehow encode it. Either with an OSSL_ENCODER, or via EVP_PKEY_get1_encoded_public_key depending on the communication protocol. When encoding the key with OSSL_ENCODER you can specify with the OSSL_ENCODER_CTX_new_for_pkey() via the selection parameter that you want to encode just the public key or the public key with domain parameters. Tomas Mraz On Fri, 2022-03-04 at 09:43 +, Srinivas, Saketh (c) wrote: > i need them to create ctx = EVP_PKEY_CTX_new(priv_key, NULL) > > and then add the peer to ctx as EVP_PKEY_derive_set_peer( ctx, > pub_key ) > > both should be evp_pkey format. > From: Tomas Mraz > Sent: Friday, March 4, 2022 2:56 PM > To: Srinivas, Saketh (c) ; > openssl-users@openssl.org > Subject: [EXTERNAL] Re: bignum to evp key > There is no straightforward way to do that. What do you want to do > with > the public and private EVP_PKEYs? > > Tomas > > On Fri, 2022-03-04 at 07:28 +, Srinivas, Saketh (c) wrote: > > HI, > > > > i have EvpKeyPair from GenerateEvpKeyPair(dh_p, dh_g, ) > > > > How can I get the public key and priv key from keypair. The below > > function gives them as bignums but not Evp_pkey. > > > > (EVP_PKEY_get_bn_param(pEvpKeyPair, OSSL_PKEY_PARAM_PUB_KEY, > > ) > > > > I want pub key and priv keys as evp_pkey. > > > > Thanks, > > Saketh. > > > > > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. and its Affiliates that > > is > > confidential and/or proprietary for the sole use of the intended > > recipient. Any review, disclosure, reliance or distribution by > > others > > or forwarding without express permission is strictly prohibited. If > > you > > are not the intended recipient, please notify the sender > > immediately > > and then delete all copies, including any attachments. > -- Tomáš Mráz, OpenSSL
Re: bignum to evp key
There is no straightforward way to do that. What do you want to do with the public and private EVP_PKEYs? Tomas On Fri, 2022-03-04 at 07:28 +, Srinivas, Saketh (c) wrote: > HI, > > i have EvpKeyPair from GenerateEvpKeyPair(dh_p, dh_g, ) > > How can I get the public key and priv key from keypair. The below > function gives them as bignums but not Evp_pkey. > > (EVP_PKEY_get_bn_param(pEvpKeyPair, OSSL_PKEY_PARAM_PUB_KEY, ) > > I want pub key and priv keys as evp_pkey. > > Thanks, > Saketh. > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If > you > are not the intended recipient, please notify the sender immediately > and then delete all copies, including any attachments. -- Tomáš Mráz, OpenSSL
Re: Unable to load PKCS#12 with password and no MAC
On Thu, 2022-02-17 at 11:31 +0200, Florin Spătar wrote: > I see. Thanks for the suggested workaround. > > Are there any plans for PKCS12_parse to support PKCS12 files without > MAC That would be a simple feature PR against master branch if anyone wants to take it. It would require some tests of PKCS12_parse to be added, that would be the hardest part of it I think. > or any plans to use a FIPS approved algorithm for PKCS12 MAC? Any of > these would help dealing with PKCS12 files in FIPS mode. Adding another algorithm for PKCS12 MAC would actually require changing the standard. The problem is the non-compliant PKCS12KDF is basically hardcoded in the PKCS12 standard as the KDF to generate the MAC key from the password. Tomas > Thanks, > > Florin Spatar > > On 16.02.2022 17:25, Tomas Mraz wrote: > > Yes, unfortunately PKCS12_parse currently does not support PKCS12 > > files > > without the MAC. Such support could be easily added. As a > > workaround > > you can look at how the pkcs12 application is implemented and use > > these > > calls instead. > > > > Regards, > > > > Tomas Mraz, OpenSSL > > > > On Wed, 2022-02-16 at 14:09 +, Florin Spatar wrote: > > > Hi, > > > > > > I am trying to use OpenSSL 3 in FIPS mode to load a PKCS#12. > > > First, I > > > got this error: > > > > > > [root@q032 ~]# openssl pkcs12 -nokeys -info -in agent.p12 - > > > passin > > > pass:opsware_admin > > > MAC: sha256, Iteration 2048 > > > MAC length: 32, salt length: 8 > > > Error verifying PKCS12 MAC; no PKCS12KDF support. > > > Use -nomacver if MAC verification is not required. > > > > > > To my understanding, PKCS12KDF used for PKCS12 MAC is non-FIPS. > > > On > > > openssl-pkcs12 man page I found the following two options: "- > > > nomac" & > > > "-nomacver" that can be useful in FIPS mode. Used "-nomac" to re- > > > create the PKCS#12, and "-nomacver" when loading the PKCS#12 to > > > get > > > rid of "Warning: MAC is absent!". > > > > > > The objective is to do the same thing via PKCS12_parse API. The > > > problem that I'm facing is that there is no API equivalent for - > > > nomacver and the following error occurs: > > > > > > 4087FE21197F:error:1180006C:PKCS12 routines:(unknown > > > function):mac absent:crypto/pkcs12/p12_mutl.c:182: > > > 4087FE21197F:error:11800071:PKCS12 routines:(unknown > > > function):mac verify failure:crypto/pkcs12/p12_kiss.c:71: > > > > > > The error only occurs if PKCS#12 password is not empty. If > > > password > > > is empty, MAC is not verified. > > > Am I missing something, or this is actually impossible to > > > achieve? > > > > > > Thanks, > > > > > > Florin Spatar -- Tomáš Mráz, OpenSSL
Re: Unable to load PKCS#12 with password and no MAC
Yes, unfortunately PKCS12_parse currently does not support PKCS12 files without the MAC. Such support could be easily added. As a workaround you can look at how the pkcs12 application is implemented and use these calls instead. Regards, Tomas Mraz, OpenSSL On Wed, 2022-02-16 at 14:09 +, Florin Spatar wrote: > Hi, > > I am trying to use OpenSSL 3 in FIPS mode to load a PKCS#12. First, I > got this error: > > [root@q032 ~]# openssl pkcs12 -nokeys -info -in agent.p12 -passin > pass:opsware_admin > MAC: sha256, Iteration 2048 > MAC length: 32, salt length: 8 > Error verifying PKCS12 MAC; no PKCS12KDF support. > Use -nomacver if MAC verification is not required. > > To my understanding, PKCS12KDF used for PKCS12 MAC is non-FIPS. On > openssl-pkcs12 man page I found the following two options: "-nomac" & > "-nomacver" that can be useful in FIPS mode. Used "-nomac" to re- > create the PKCS#12, and "-nomacver" when loading the PKCS#12 to get > rid of "Warning: MAC is absent!". > > The objective is to do the same thing via PKCS12_parse API. The > problem that I'm facing is that there is no API equivalent for - > nomacver and the following error occurs: > > 4087FE21197F:error:1180006C:PKCS12 routines:(unknown > function):mac absent:crypto/pkcs12/p12_mutl.c:182: > 4087FE21197F:error:11800071:PKCS12 routines:(unknown > function):mac verify failure:crypto/pkcs12/p12_kiss.c:71: > > The error only occurs if PKCS#12 password is not empty. If password > is empty, MAC is not verified. > Am I missing something, or this is actually impossible to achieve? > > Thanks, > > Florin Spatar -- Tomáš Mráz, OpenSSL
Re: OpenSSL 3.0 FIPS module configuration file
Please note that there are two checksums in the configuration file. One of them is the FIPS module checksum and the other is the checksum of the configuration. You can copy the file across machines if it is without the configuration checksum - that means the selftest will be always run when the FIPS module (i.e., the fips provider) is loaded. You cannot copy the file if the configuration checksum is present in it though because that means the selftest won't be run on the machines where you copy the configuration file to. That would be against the FIPS implementation guidance that requires to run the selftests at least once after the installation. Tomas On Tue, 2022-02-15 at 10:31 +1100, Dr Paul Dale wrote: > Yes, this has to do with the FIPS standards. I forget which > standard > it is but the self tests are mandated to be run on each device > independently. > > The fipsinstall process runs the self tests before generating the > configuration file. If the self tests fail, the module doesn't > install. Copying the configuration file across avoids the self tests > and therefore isn't compliant. > > > Pauli > > > On 15/2/22 02:25, Richard Dymond wrote: > > > > > Hi > > > > Probably a dumb question, but why must the FIPS module > > configuration file for OpenSSL 3.0 be generated on every machine > > that it is to be used on (i.e. must not be copied from one machine > > to another)? > > > > I just ran 'openssl fipsinstall' on two different machines with the > > same FIPS module and it produced exactly the same output each time, > > so presumably the reason has nothing to do with the config file > > being unique to the machine. > > > > Does it have something to do with the FIPS standard itself? > > > > Richard > > -- Tomáš Mráz, OpenSSL
Re: SHA1 Hashing in FIPS Provider
On Fri, 2022-02-11 at 08:35 +, Kevin Millson wrote:
> Hello OpenSSL Users,
>
> I’m trying to use SHA1 message digest hashing in combination with the
> FIPS provider, but seem to be running into issues. My code looks like
> the following:
>
> EVP_PKEY* privateKey = getPrivateKey();
> EVP_MD_CTX* mdContex = EVP_MD_CTX_new();
> if (mdContex != NULL) {
> const EVP_MD* messageDigest = EVP_MD_fetch(NULL, "SHA-1",
> "provider=fips");
> if (EVP_DigestSignInit(mdContex, NULL, messageDigest, NULL,
> privateKey) == 1) {
> std::cout << "Success";
> } else {
> std::cout << "EVP_DigestSignInit failed";
> }
> EVP_MD_CTX_free(mdContex);
> }
>
> The call to EVP_DigestSignInit() always fails. If I switch to SHA-256
> then it works fine. I thought SHA-1 wasn’t allowed for raw sign
> operations, but was still okay for message digests calculated via the
> EVP_MD related methods, is that thinking incorrect? And in fact, all
> use of SHA-1 with FIPS is disallowed?
With FIPS SHA-1 is disallowed for signing. SHA-1 is allowed in other
contexts than signing. It is allowed for legacy purposes in
verification of signatures, it is also allowed in HMACs.
--
Tomáš Mráz, OpenSSL
Re: [EXTERNAL] Re: does Openssl 3.0 has backward compatiblity.
The returned value should be just passed to OSSL_PROVIDER_unload() when you're no longer using the provider. Tomas On Thu, 2022-02-10 at 11:03 +, Srinivas, Saketh (c) wrote: > do you have an example how to set it. It seems the function returns > OSSL_PROVIDER. what/where do i set this return value. > > thanks, > Saketh. > From: Tomas Mraz > Sent: Wednesday, February 9, 2022 4:59 PM > To: Srinivas, Saketh (c) ; > openssl-users@openssl.org > Subject: [EXTERNAL] Re: does Openssl 3.0 has backward compatiblity. > The PKCS12 files use algorithms that are legacy, you need to load the > legacy and default provider to be able to load them. You can do that > either with configuration file (see man 5 config) or with > OSSL_PROVIDER_load() calls. > > Regards, > Tomas > > On Wed, 2022-02-09 at 11:11 +, Srinivas, Saketh (c) wrote: > > Does openssl 3.0 supports the openssl 1.0 pkcs12 files. Is it > > backward compatible. For me it giving error in PKCS12_parse > > function. > > > > > > thanks, > > Saketh. > > > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. and its Affiliates that > > is > > confidential and/or proprietary for the sole use of the intended > > recipient. Any review, disclosure, reliance or distribution by > > others > > or forwarding without express permission is strictly prohibited. If > > you > > are not the intended recipient, please notify the sender > > immediately > > and then delete all copies, including any attachments. > -- Tomáš Mráz, OpenSSL
Re: does Openssl 3.0 has backward compatiblity.
The PKCS12 files use algorithms that are legacy, you need to load the legacy and default provider to be able to load them. You can do that either with configuration file (see man 5 config) or with OSSL_PROVIDER_load() calls. Regards, Tomas On Wed, 2022-02-09 at 11:11 +, Srinivas, Saketh (c) wrote: > Does openssl 3.0 supports the openssl 1.0 pkcs12 files. Is it > backward compatible. For me it giving error in PKCS12_parse > function. > > > thanks, > Saketh. > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If > you > are not the intended recipient, please notify the sender immediately > and then delete all copies, including any attachments. -- Tomáš Mráz, OpenSSL
Re: error with p12 file importing
Hi, is this with a 3.0 version? If so, the most probable cause is that the pkcs12 file uses some legacy algorithms. You'll need to load the legacy and default providers either by having them activated in the OpenSSL configuration file or by explicitly loading them with OSSL_PROVIDER_load() calls. See the crypto(7) and config(5) manpages. Tomas On Fri, 2022-02-04 at 09:56 +, Srinivas, Saketh (c) wrote: > HI, > > I am getting this error while importing p12 file > > PKCS12_parse failed, error : error:0308010C:digital envelope > routines::unsupported > > can anyone explain this? > > thanks, > Saketh. > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If > you > are not the intended recipient, please notify the sender immediately > and then delete all copies, including any attachments. -- Tomáš Mráz, OpenSSL
Re: Openssl 3.0 support
Yeah, you need to add the @SECLEVEL=0 in the cipher string to set the security level to 0. That is needed to allow SHA1 in signatures which is required for these TLS versions. Tomas Mraz On Thu, 2022-02-03 at 17:36 +1100, pa...@openssl.org wrote: > It does support both. I think a configuration time option might be > required and neither is supported by the FIPS provider. > > Paul Dale > > > On 3/2/22 4:32 pm, Srinivas, Saketh (c) wrote: > > > > > Hi, > > > > Does openssl 3.0 still support TLSv 1.0 and TLSv1.1. or they are > > deprecated, because there were some deprecations like sha1 etc. > > > > Thanks, > > Saketh. > > > > > > > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. and its Affiliates that > > is > > confidential and/or proprietary for the sole use of the intended > > recipient. Any review, disclosure, reliance or distribution by > > others > > or forwarding without express permission is strictly prohibited. If > > you are not the intended recipient, please notify the sender > > immediately and then delete all copies, including any attachments. > > -- Tomáš Mráz, OpenSSL
Re: Order of providers breaks my keymgmt
On Mon, 2022-01-17 at 09:36 +0100, Milan Kaše wrote:
> Hi,
> I successfully implemented OpenSSL v3 provider which provides store
> and keymgmt and I can use it to sign a cms with the following
> command:
>
> openssl cms -sign -signer myprov:cert=0014 -provider myprov -provider
> default
>
> However when I swap the order of providers (in the real world
> scenario
> the providers are configured through the configuration file), i.e.
>
> openssl cms -sign -signer myprov:cert=0014 -provider default -
> provider myprov
>
> the command stops working.
>
> I return the private key from the store through the reference:
>
> int construct_ec_key(LOADER_CTX *myloader, OSSL_CALLBACK *object_cb,
> void *object_cbarg) {
> static const int object_type = OSSL_OBJECT_PKEY;
> static const char data_type[] = "EC";
> KEYREF ref = { 0, };
> OSSL_PARAM objparams[] = {
> OSSL_PARAM_int(OSSL_OBJECT_PARAM_TYPE, (int *)_type),
> OSSL_PARAM_octet_string(OSSL_OBJECT_PARAM_REFERENCE, ,
> sizeof(ref)),
> OSSL_PARAM_utf8_string(OSSL_OBJECT_PARAM_DATA_TYPE, (char
> *)data_type, COUNTOF(data_type) - 1),
> OSSL_PARAM_END,
> };
> return object_cb(objparams, object_cbarg);
> }
>
> The try_key_ref function then tries to transform data from the store
> into the EVP_PKEY. It first looks up a keymgmt that can handle the
> "EC" data type. Since the default provider is the first one that can
> do that it is selected. It then tries to export data from my keymgmt
> and import it into the selected default keymgmt. But obviously I
> can't
> export the private key and the operation fails.
We need to add a fallback in the try_key_ref() to try to fetch the
keymgmt from the provider of the store if the key is unexportable.
Could you please open an issue?
> When my provider is activated before the default one then everything
> works because the EVP_PKEY is constructed from my keymgmt.
>
> What am I doing wrong? Shouldn't OpenSSL first try to construct
> EVP_PKEY from the provider it actually returned the data? Is there a
> way to force OpenSSL to use the specified provider (some property
> "provider=myprov")?
You can set a default property query in the configuration file with
"?provider=myprov" as a workaround. That way your provider will be
preferred for the operations. However it might have some unwanted and
unexpected consequences.
--
Tomáš Mráz, OpenSSL
Re: What is the correct way to use OSSL_DECODER
On Wed, 2022-01-12 at 09:41 +0100, Milan Kaše wrote: > By further comparing the scenario with the built-in file provider and > my external provider I found that this has something to do with > library contexts. > > When x509_pubkey_ex_d2i_ex tries to decode the certificate's public > key it always uses the default library context. When loading a > certificate from a file through the default provider the > OSSL_DECODER_CTX_new_for_pkey sets up decoders in this context > correctly. However when loading a certificate from my provider the > default provider has not been activated and > OSSL_DECODER_CTX_new_for_pkey contains no decoder thus the following > DECODER_from_bio fails to decode the certificate public key. > > If I "hack" my provider_init function and force load the default > provider into the default library context then things start to work. > Then I realized I can also add provider on the command line: > > openssl cms -sign -signer myprov:cert=0014 -provider myprov -provider > default > > and this work too. > > How is this supposed to work? The default (or base) provider has to be explicitly loaded either via the configuration file once you load any other provider. The default provider is implicitly loaded only in case no other provider was loaded before for compatibility reasons. See for example the OSSL_PROVIDER-default manual page. -- Tomáš Mráz, OpenSSL
Re: Undefined Reference to "bn_get_words()" and "bn_get_top()".
On Tue, 2022-01-11 at 10:15 +, Kumar Mishra, Sanjeev wrote: > Hi, > I am getting following linking Error for APIs "bn_get_words()" and > "bn_get_top()" while compiling with OpenSSL 3.0. Although crypto/bn.h > is included in file. > Please help to resolve it. > Regards, > Sanjeev These symbols are internal and not exported from the shared library. You would have to link statically to be able to use them. Of course that is not recommended exactly because the symbols are internal and thus can disappear or arbitrarily change meaning within any release. -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Tue, 2022-01-04 at 19:25 +, Blumenthal, Uri - 0553 - MITLL wrote: > > > But, considering that the man pages describe C API, wouldn't it > > be > > > nice to mention (even though it may be obvious that a number of > > order > > > 2^384 might not fit into 32 or even 64 bits) that the actual > > type is > > > BIGNUM? > > > > No, the type is not a BIGNUM. Please read "man OSSL_PARAM" it > > contains > > the information on what types OSSL_PARAM support. > > I did that before playing with and modifying the OP's code. > Obviously, either I'm too dense to understand it, or it's too dense. > > > > Also, what should arguments to that C call > > EVP_PKEY_get_int_param() > > > look like to succeed? Do I need to pass a pointer to BN there??? > > > > Please read "man EVP_PKEY_get_int_param". > > See above. Some verbiage, very little clues - especially for somebody > who doesn't already know how it works. > > int EVP_PKEY_get_int_param(const EVP_PKEY *pkey, const char > *key_name, > int *out); > EVP_PKEY_get_int_param() retrieves a key pkey integer value *out > associated with a name of key_name. > > Overall, VERY confusing. > > How does one know (without going through > EVP_PKEY_gettable_params(EVP_PKEY *pkey) and > EVP_PKEY_get_params(const EVP_PKEY *pkey, OSSL_PARAM params[])) what > method to use to retrieve what parameter? So you're basically asking to put something like - "The parameter most probably won't fit into unsigned int." - to every such parameter documented for PKEYs? -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Tue, 2022-01-04 at 17:02 +, Blumenthal, Uri - 0553 - MITLL wrote: > > > In other words, the man page says it's unsigned int, but in fact > > it's > > > BIGNUM? Because the pointer I gave was to "unsigned int", like > > in the > > > OP's code. > > > > The param is too big to fit into int. If you were using some > > ridiculously small EC curve the call would succeed. The parameter > > types > > != C types and the manual page does not say "unsigned int" but > > "unsigned integer" for a reason. > > Yes, that makes sense. > > But, considering that the man pages describe C API, wouldn't it be > nice to mention (even though it may be obvious that a number of order > 2^384 might not fit into 32 or even 64 bits) that the actual type is > BIGNUM? No, the type is not a BIGNUM. Please read "man OSSL_PARAM" it contains the information on what types OSSL_PARAM support. > Also, what should arguments to that C call EVP_PKEY_get_int_param() > look like to succeed? Do I need to pass a pointer to BN there??? Please read "man EVP_PKEY_get_int_param". -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Tue, 2022-01-04 at 16:46 +, Blumenthal, Uri - 0553 - MITLL wrote: > On 1/4/22, 11:23, "Tomas Mraz" wrote: > > > > Theoretically, shouldn’t > > > > > > EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned > > int)order) > > > > > > work? I verified that it does not seem to work, at least in the > > > obvious context. > > > > OSSL_PARAM_EC_ORDER is an unsigned integer (also a bignum) and it > > won't > > fit into int. So that's the reason why that call fails. > > In other words, the man page says it's unsigned int, but in fact it's > BIGNUM? Because the pointer I gave was to "unsigned int", like in the > OP's code. The param is too big to fit into int. If you were using some ridiculously small EC curve the call would succeed. The parameter types != C types and the manual page does not say "unsigned int" but "unsigned integer" for a reason. -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Tue, 2022-01-04 at 14:17 +, Blumenthal, Uri - 0553 - MITLL wrote: > Now I became interested. ;-) > > Theoretically, shouldn’t > > EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned > int)order) > > work? I verified that it does not seem to work, at least in the > obvious context. OSSL_PARAM_EC_ORDER is an unsigned integer (also a bignum) and it won't fit into int. So that's the reason why that call fails. Also the order is not a degree (maximum number of bits of a curve coordinate). -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Tue, 2022-01-04 at 02:33 +0100, Wolf wrote: > Thank you for the answer! > > On 2022-01-03 10:11:19 +0100, Tomas Mraz wrote: > > You're using the secp384r1 curve which is a prime field curve. The > > OSSL_PKEY_PARAM_EC_CHAR2_M parameter can be obtained only for > > binary > > field curves. > > > > If you have a group NID for the curve of the EC key, you could use: > > > > EC_GROUP *group = EC_GROUP_new_by_curve_name_ex(NULL, NULL, nid); > > > > to create the group to call EC_GROUP_get_degree() on. > > > > Of course if you can have an EC key with arbitrary explicit group > > parameters, that would not work. > > That is sadly the case of me. > > > But you can then use number of bits of the OSSL_PKEY_PARAM_EC_P > > parameter as the degree for prime field curves. > > So, I've tried following your advice, but for some reason it is still > failing for me. I've modified my example program to be: You need to use EVP_PKEY_get_bn_param() to get the P parameter and BN_num_bits() to count the number of bits of the P value. -- Tomáš Mráz, OpenSSL
Re: EVP_PKEY_get_int_param is not getting degree from EC key
On Mon, 2022-01-03 at 01:51 +0100, Wolf wrote: > Greetings, > > I'm trying to port my program to openssl 3.0 and in the process I > need > to replace EC_GROUP_get_degree(EC_KEY_get0_group(ec)) with something > that is not deprecated. I'm trying to use EVP_PKEY_get_int_param with > OSSL_PKEY_PARAM_EC_CHAR2_M, however it does not work. I'm assuming > I'm > just doing something wrong, but have no idea what. Would there be any > kind soul willing to point me in the right direction? You're using the secp384r1 curve which is a prime field curve. The OSSL_PKEY_PARAM_EC_CHAR2_M parameter can be obtained only for binary field curves. If you have a group NID for the curve of the EC key, you could use: EC_GROUP *group = EC_GROUP_new_by_curve_name_ex(NULL, NULL, nid); to create the group to call EC_GROUP_get_degree() on. Of course if you can have an EC key with arbitrary explicit group parameters, that would not work. But you can then use number of bits of the OSSL_PKEY_PARAM_EC_P parameter as the degree for prime field curves. -- Tomáš Mráz, OpenSSL
Re: OpenSSL provider replacement for ENGINE_load_private_key
On Sun, 2021-12-12 at 00:39 +0200, Graham Leggett via openssl-users wrote: > Hi all, > > The ENGINE API is deprecated in favour of the new Provider API. > > What is the provider equivalent function that replaces > ENGINE_load_private_key()? One option would be for a provider to provide provider-storemgmt implementation to load a key from its special URI. You'd then use OSSL_STORE from the application to load a private key from that special URI. Another, rather simplistic, approach would be to use the EVP_PKEY_fromdata() function. In that case you'd have to know what the key algorithm are you using. You'd then use EVP_PKEY_CTX_new_from_name with query properties to include "provider=your_provider" and the params used with EVP_PKEY_fromdata() would contain just the special id parameter that the provider would use to identify the private key from the device. > Regards, > Graham > — > -- Tomáš Mráz, OpenSSL
Re: OpenSSL-3.+ how to configure [random]?
On Wed, 2021-11-10 at 03:38 +, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/9/21, 22:23, "Dr Paul Dale" wrote: > > > Currently I've no idea and can't reproduce locally :( > > Maybe you'd know how to force the "-engine rdrand" path through > "openssl.cnf"? > > > A rogue configuration file could cause the DRBGs/seeds to fail. > > Do you > > have seed=rdrand line in the random section? That will cause > > the > > seeding source to fail to load at all. > > No, I don't - and providing empty config causes the same result: > > $ OPENSSL_CONF=/dev/null openssl3 rand -hex 4 > $ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4 > Engine "rdrand" set. > 61f1666d How did you configure the rand seed sources when building OpenSSL? I think rather than trying to make the rdrand engine default it would make more sense to try to resolve the problem with the rand provider and its seeding. What is the exit code of the first execution of the rand command? Could you try to run it under strace and/or gdb to investigate? -- 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: Establishing connection errors
On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote: > For setting up the trusted store, when the application starts, it > calls: > > ssl_trusted_certs = X509_STORE_new() > > ...and then reads all of the certificates in /etc/ssl/certs/ calling > X509_STORE_add_cert(trusted_store,cert); > > ..for each one. How do you read the certs? They need to be loaded with the appropriate libctx. Or you can use for example X509_STORE_load_file_ex() function to load a file directly with an libctx. -- 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: Establishing connection errors
On Fri, 2021-11-05 at 13:04 +, Jason Schultz wrote: > I know I've been raising a lot of issues this week, because of > varying reasons, but I've hit another one that seems like either an > OpenSSL problem, or something new/different I need to do with OpenSSL > 3.0 in connection establishment. > > To recap, I'm using two non-default library contexts, one for FIPS, > one for non-FIPS. There is an open issue in github regarding the call > to SSL_CTX_build_cert_chain(), but since the purpose of that call is > to have the server not include the root certificate when sending the > chain, I have left that out of my code for now, in order to continue > testing. It shouldn't affect what I'm trying to do. > > As far as connection set up, based on whether or not the user wants > FIPS (not using FIPS for this test), I call: > > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > > ...to set up my SSL_CTX. My understanding is that all SSL objects, > etc., created based on that SSL_CTX will use the appropriate library > context/providers. So beyond the providers and library context setup > and using SSL_CTX_new_ex(), I haven't changed any code to establish > TLS connections. I've tried to establish connections using both RSA > and ECDSA certificates/keys, self-signed, or a server cert that's > part of a chain. I'm just establishing a connection to myself, not > between two systems, just to try to get something working. I'll post > all of the handshake messages at the end of this message, but here > are the error messages I get when the client side receives the server > certificate (in this case it's a self signed RSA certificate): How do you set up the non_fips_libctx and how do you set up any certificate trust store within the SSL_CTX? -- 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: X509_get_pubkey() in OpenSSL 3.0?
On Wed, 2021-11-03 at 20:32 +, Jason Schultz wrote: > 00B741558E7F:error:0308010C:digital envelope routines:(unknown > function):unsupported:crypto/evp/evp_fetch.c:346:Global default > library > context, Algorithm (SHA1 : 96), Properties () The "Global default library context" hints at what is the issue - somewhere in the chain verification or chain building routines the non- default context is not passed appropriately in and this causes the failures. Could you please open this as an issue in GitHub? -- 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: SSL and "custom" EVP_KEY
On Tue, 2021-11-02 at 11:42 +0700, Alex Dankow wrote: > Matt, > > Thank you very much for your response. I understand that the FIPS > certified OpenSSL module is long awaited and the team was quite > limited in time to complete all features. > I tried Windows certificates +Openssl because it implements the most > common scenario: you can get a certificate to Openssl in DER format, > but you can't get the private key. HSMs, KMIP servers or Windows > don't let you export the private key. It can be only virtualized > (You sure know it, but I'm writing it also for our readers.) > So, when I load X509 from storage it is handled by OpenSSL directly > and gets type "RSA".When the private key is supplied, it has type of > "MYTYPE" and actually represents a handle. If I skip the key matching It should not have a type "MYTYPE" if it is really an RSA key. There are some pecularities with how the openssl-3.0.0 works however 3.0.1 will contain a fix that should make this work correctly for unexportable private keys of any common type. Your provider will be invoked for operations with the private key. > part, "openssl ca" works and a cert request can be signed with such a > handle. > As I understand, Openssl doesn't handle it completely yet. But it was > planned so and maybe we will see it in the future. > If ENGINE is now deprecated (is it?), what HSM vendors should do? > -- > Alex Dankow > > > > > > > > > > > > > > On Fri, Oct 29, 2021 at 10:11 PM Matt Caswell > wrote: > > Hi Alex, > > > > On 29/10/2021 14:32, Alex Dankow wrote: > > > Hi OpenSSL team! > > > > > > I wrote a provider for Windows certificates and implemented > > "openssl ca". > > > Now, I think it would be fun to see a HTTPS server using > > certificates > > > installed in Windows storage. > > Nice! > > > > > > > > Certificate is loaded using load_cert_pass (taken from apps.c) > > > with > > > custom uri "wincert://11:22:33", private key is loaded with > > > load_key from apps.c too. It works, but ... > > > When I use SSL_CTX_use_PrivateKey(ctx, myprivk) the key is > > declined. > > > OpenSSL compares strings and expects "rsaEncryption", and so on > > instead > > > of "MYKEY". Why ? > > > > It's not entirely clear to me what you are attempting here. Are > > your > > certificates/keys stored in Windows storage standard RSA/ECDSA etc > > certs? Or are they using some custom algorithm? > > > > If they are standard RSA/ECSDA certs then you should be using the > > correct standard algorithm names in you keymgmt etc and it should > > all > > "just work". > > > > Unfortunately, in 3.0, libssl only supports standard algorithms. We > > have > > discussed a "pluggable" signature scheme mechanism which would > > enable > > plugging in arbitrary algorithms but it didn't make it for 3.0: > > > > https://github.com/openssl/openssl/issues/10512 > > > > I'd still like to get back to that at some point but we don't have > > it > > yet. It should be entirely possible with the new provider > > architecture - > > and in fact we *did* add pluggable kex/kem support for libssl. But > > we > > just ran out of time with pluggable signatures. > > > > https://github.com/openssl/openssl/pull/11914 > > https://github.com/openssl/openssl/pull/13018 > > > > > > Matt > > > > > Maybe I'm missing something, but if you built a key management > > system, > > > sign interface, ciphers that allows key virtualization, why not > > > go > > > further ? I'm ready to implement the encryption interface, but > > > why > > > OpenSSL still care about key type name. In the new era of version > > 3, it > > > can check if the key provides necessary interfaces. > > > > > > -- > > > Alex Dankow > > > > > > -- 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: Matching keys between providers
On Sat, 2021-10-23 at 11:04 +0700, Alex Dankow wrote: > Hi OpenSSL users and its glorious developers, > > Thank you very much for OpenSSL 3! > > My question is about writing a provider. I decided to start from a > Windows certificate storage provider. It already works with "openssl > storeutl" command, but can't make it work with "openssl ca". > > When openssl expects a certificate, I return an encoded certificate > directly. OpenSSL parses it and the public key belongs to the "OpenSSL > RSA" provider. I can't give private keys from Windows cert. storage and > return something virtual from my key management provider. > > At the next step, openssl.exe does matching, compares key types: public > key's type is "OpenSSL RSA" and the private key type of "MYPKEY". It is > done in evp_keymgmt_util_match. > I was hoping it would be called OSSL_FUNC_KEYMGMT_MATCH for both > providers, but it only compares strings and says types are different. > If I declare that my key management also handles RSA in OSSL_ALGORITHM > as "MYPKEY:RSA" OpenSSL tool gives an error that RSA has an existing > different identity. > > I'm exploring the source, but I'm stuck. Is it the wrong approach or I > missed something ? This is something that should be resolved by: https://github.com/openssl/openssl/pull/16725 The key type for RSA keys must be "RSA". And the PR linked above should ensure that the unexportable RSA keys from the keystore would be handled by your provider. -- 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: openssl 3.0.0 get ECC public key modulus from EVP_PKEY
On Thu, 2021-10-14 at 17:36 -0400, Ken Goldman wrote: > On 10/14/2021 6:39 AM, Matt Caswell wrote: > > > > "priv" (OSSL_PKEY_PARAM_PRIV_KEY) > > > > The private key value. > > > > Since its an integer using EVP_PKEY_get_bn_param() would be > > appropriate here, but not EVP_PKEY_get_octet_string_param(). > > > > Basically you need to know the type of the parameter you are > > attempting to access and use the right kind of "getter" to match > > the type - otherwise it will fail. > > That helped! > > https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html > > I found that page a bit confusing. Is it right that > > > > > are all actually BIGNUM? I.e., not C int or unsigned int? They are unbounded integer values. See OSSL_PARAM(3) > > > > While I'm on that page: > > should call EVP_PKEY_get_utf8_string_param(). This > seems to require an allocated array. > How does one find the size to allocate? Does it follow the typical > "if buf is NULL, return just the size" > so it can be malloced. > > same question. Yes, this should work, except for one caveat - you need to allocate + 1 byte for \0 terminator in case of the UTF8 string. We should document this. -- 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: Store Mgmt and keys loading ( keyform ENG )
No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already modified to use OSSL_STORE API to load keys. So you do not need to specify keyform=ENGINE if your key is provided by a provider that supports the STORE functionality for some special URL scheme. You just specify the right URL with that scheme to reference the key in the provider. Of course third party applications need to be modified to call OSSL_STORE API in a similar way how the openssl application does it. Tomas On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > Thank you for your comment. > Am I wrong then in saying that dgst and possibly other apps are not > ready to be used with providers rather than engines in the case you > need keyform=ENGINE ? > > > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > > You would have to implement a STORE provider that handles your > > special > > url scheme and then the keys would be referenced by the > > yourscheme://any-identifier-you-have. Of course the application > > (i.e., > > the openssl application which already does this) would have to use > > the > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > > API > > or the d2i/PEM_read APIs. > > > > Tomas > > > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > > I checked the sources, I found that keyform cannot be set to > > > ENGINE > > > if engine is not specified in the command options, this is in the > > > function make_engine_url() called from load_key() when > > > format==FORMAT_ENGINE. > > > I am not specifying engine in the dgst command options as I am > > using > > > a provider. > > > I would like to achieve the same as FORMAT_ENGINE does, but with > > > provider. > > > > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > > wrote: > > > > Hello, > > > > I am doing my own provider starting from the default provider's > > > > code. > > > > I have now a question, I am seeing the STOREMGMT operation is > > > > required to interpret the URI of input private key, I would > > > > like > > > > that the string passed by the user for input key is not > > > > interpret > > > > as file to open but just my provider should save the string > > > > value > > > > to be used later .This is when invoking command options such > > > > as > > > > dgst sign -in "text" -keyform ENG. > > > > With engines' architecture this is possible by passing option - > > > > keyform ENG to dgst command. The string in that case is not > > > > interpreted as a file path and just passed through. > > > > There was engine_set_load_privkey_function that was getting > > > > this > > > > string. > > > > How can I achieve this now with the provider architecture ? If > > > > I > > > > pass -keyform ENG to dgst command together with --provider , it > > > > says "no engine specified to load private key" Should I use > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > > don't > > > > have a real private key info to load and use from a Filesystem. > > > > Is there anything to set in the KEYMGMT too ? I can see there > > > > is > > a > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > > data in a key object should be considered. Not really sure if > > this > > > > is something I should set or not and how this keymgmt operation > > > > relates with storemgmt operation. > > > > > > > > thank you if you can send some comment on this. > > > > > > -- 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: Store Mgmt and keys loading ( keyform ENG )
You would have to implement a STORE provider that handles your special url scheme and then the keys would be referenced by the yourscheme://any-identifier-you-have. Of course the application (i.e., the openssl application which already does this) would have to use the OSSL_STORE API to load the keys and not directly the OSSL_DECODER API or the d2i/PEM_read APIs. Tomas On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > I checked the sources, I found that keyform cannot be set to ENGINE > if engine is not specified in the command options, this is in the > function make_engine_url() called from load_key() when > format==FORMAT_ENGINE. > I am not specifying engine in the dgst command options as I am using > a provider. > I would like to achieve the same as FORMAT_ENGINE does, but with > provider. > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > wrote: > > Hello, > > I am doing my own provider starting from the default provider's > > code. > > I have now a question, I am seeing the STOREMGMT operation is > > required to interpret the URI of input private key, I would like > > that the string passed by the user for input key is not interpret > > as file to open but just my provider should save the string value > > to be used later .This is when invoking command options such as > > dgst sign -in "text" -keyform ENG. > > With engines' architecture this is possible by passing option - > > keyform ENG to dgst command. The string in that case is not > > interpreted as a file path and just passed through. > > There was engine_set_load_privkey_function that was getting this > > string. > > How can I achieve this now with the provider architecture ? If I > > pass -keyform ENG to dgst command together with --provider , it > > says "no engine specified to load private key" Should I use > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't > > have a real private key info to load and use from a Filesystem. > > Is there anything to set in the KEYMGMT too ? I can see there is a > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > data in a key object should be considered. Not really sure if this > > is something I should set or not and how this keymgmt operation > > relates with storemgmt operation. > > > > thank you if you can send some comment on this. > > -- 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: LE/DST expired root: workaround #2
On Thu, 2021-09-30 at 21:28 -0400, Felipe Gasper wrote: > Hello, > > > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ > > ^^ This document indicates that, by enabling trusted-first mode, I > should be able to work around the LE expiration problem. > > I’m either misunderstanding this or “holding it wrong”, though, > because I can’t see that setup making any difference. > > I’ve got a chain with: > 1) leaf cert (felipegasper.com) > 2) Let’s Encrypt R3 > 3) … and the cert called “ISRG Root X1” that is *not*, in fact, a > root cert > > Cert #3 in the above is issued by the now-expired “DST Root CA X3”, > so including it (understandably) “misleads” `openssl verify` into > looking into its root store for that cert’s issuer, which causes a > verification failure. > > I notice, though, that connection handshakes succeed despite the non- > self-signed “ISRG Root X1” being part of the sent chain. > > Is there a way I can make `openssl verify` behave the same way as > connection handshakes? So the 3 certs I have in my chain will pass > OpenSSL’s dedicated verification logic? You need to have a self-signed ISRG Root X1 as a trusted cert in the openssl verify. That self-signed ISRG Root X1 is contained in up-to- date OS certificate trust stores so that's the reason why connections succeed (with 1.0.2 in case the -trusted_first is used). The 1.1.x or 1.0.2 will ignore the non-self-signed ISRG Root X1 certificate and use the self-signed ISRG Root X1 to verify the Let's Encrypt R3 intermediate cert. However 1.0.2 without -trusted_first will always try to verify the path via the non-self-signed ISRG Root X1 which leads to the expired DST Root CA X3 cert in the trust store which then fails the verification. -- 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_EncryptInit_ex2() operation
On Mon, 2021-09-27 at 15:15 -0400, Ken Goldman wrote: > Does it make sense to initialize the context once and then use it > multiple times, or is cleaner to create a new one from the raw key > byte string each time? It is not necessary. The reinitialization is supported to avoid recreating key schedule if the key used is the same. > I've seen sample code that uses this to 'reset' the context for a new > encryption. > > EVP_EncryptInit_ex2(e, NULL, NULL, NULL, NULL); > > 1. Is this guaranteed? Documented? We do not change the behavior of existing operations and modes (or at least not intentionally). This call is even tested at least for some ciphers and modes. However the documentation of it is missing. > 2. Does the iv get reset as well? Only for some modes (namely CBC, CFB, OFB) due to history. > 3. Is the padding retained, or must I call > EVP_CIPHER_CTX_set_padding() again? It should be retained. It is initialized only when a new key is set. -- 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: OpenSSL SSL_CTX_set_default_verify_paths Slow
On Mon, 2021-09-27 at 08:24 -0700, Jay Foster wrote: > On 9/27/21 7:33 AM, Michael Richardson wrote: > > Jay Foster wrote: > > > While migrating some applications from OpenSSL 1.0.2 (and > > 1.1.1) to > > > 3.0.0, I have noticed that the > > SSL_CTX_set_default_verify_paths() > > > function is much slower in 3.0.0. In 1.0.0 it would take > > about 0.1 > > > seconds and in 3.0.0 it takes over 3 seconds. > > > > Based upon your straces, the time is spend in the OS. > > Are you running this on the same system? > Exact same machine. > > That's still very slow... I wonder if you have a failing disk. > > I don't think so. The file system is a UBIFS on nand flash, and it > 1.0.2, but nowhere near as much slower as 3.0.0. > > blocks at a time and doing some processing on the data read. It > appears > that this processing is what is taking longer. Yes, unfortunately the decoding takes much longer on 3.0.0. I suppose there is some major optimization to be done in 3.1. -- 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: openssl 3.0.0 legacy provider won't lload via config file
This is really weird. The OPENSSLDIR as in the Makefile should be
applied during the build. If you do strings does
it show the ssl-3? Is it possible that you have some other build of
openssl-3.0 with incorrect (default) OPENSSLDIR lying on the system
somewhere?
Please open an GitHub issue so we can investigate this further.
Tomas Mraz
On Fri, 2021-09-17 at 11:55 -0700, Kory Hamzeh wrote:
>
>
> > On Sep 14, 2021, at 12:03 AM, Tomas Mraz wrote:
> >
> > On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote:
> > > I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far,
> > > everything
> > > seems to be working fine, except for the fact that I cannot get
> > > OpenSSL to load the legacy module when I configure
> > > /ssl/openssl.cnf
> > > as such. I can, however, load the module explicitly at run time.
> > >
> > ...
> > >
> > > The EVP_DecryptInit_ex() fails if I compile without -
> > > DLOAD_PROVIDER.
> > > The other flag, CRYPTO_INIT does not make any difference. What is
> > > puzzling is that I can build OpenSSL natively on an x86_64
> > > machine
> > > and using the same openssl.cnf file, the code above works and the
> > > legacy module loads without the code to explicitly load it.
> > >
> > > Any thoughts on what I may have done wrong or how to track this
> > > down?
> >
> > Could it be that your cross-compiled build expects the
> > configuration
> > file to be somewhere else? Have you tried to strace the application
> > to
> > see where it searches for the openssl.cnf?
>
> OK, I ran strace and notice what might be a bug in OpenSSL 3.0.0.
>
> Let me first start by saying that we run a mixture of OpenSSL 1.0.1g
> and OpenSSL 3.0.0. We are planning to upgrade all of the apps to
> 3.0.0, but some of the vendors have not upgraded yet.
>
> The 1.0.1g config directory is /ssl.
>
> I configured OpenSSL 3.0.0 to use /ssl-3 for its config files as
> follows:
>
> ./Configure linux-armv4 -march=armv7-a shared enable-fips --cross-
> compile-prefix=arm-none-linux-gnueabi- --prefix=/ --openssldir=/ssl-3
>
> The Makefile confirms this:
>
> OPENSSLDIR=/ssl-3
>
> I make and make install like this:
>
> make DESTDIR=$INSTALL_DIR install_ssldirs install_sw install_fips
>
> where $INSTALL_DIR is where we build the rootfs structure. I can see
> that it created $INSTALL_DIR/ssl-3.
>
> But an stace of the apps show:
>
> open("/ssl/openssl.cnf", O_RDONLY|O_LARGEFILE) = 3
>
> If I:
>
> export OPENSSL_CONF="/ssl-3/openssl.cnf”
>
> before I run my apps, everything works. But this is disconcerting.
>
> Any thoughts or feedback?
>
> Thanks,
> Kory
>
--
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: Does the openssl support RFC5755: Group. Role. Access Identify?
As this requires support for Attribute Certificates which is not currently present in OpenSSL neither RFC 5755 is supported. Regards, Tomas On Sat, 2021-09-18 at 11:34 +0800, 215104920 via openssl-users wrote: > Hi. There > Could you give me some help? > Thanks a lot. > > > BRs > Mystic -- 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: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0
I am sorry but as I said providers are not a direct replacement for
ENGINEs. It is a completely different implementation of the same
concept of pluggable cryptographical modules for OpenSSL. You can look
at the OpenSSL manual pages for the providers.
This is the starting point:
https://www.openssl.org/docs/man3.0/man7/provider.html
There is no tutorial as for how to implement your own provider. And as
I said on the application side if the application loads an OpenSSL
configuration file the providers loaded can be configured via the
config file and does not require any explicit API calls from the
application.
I'd recommend looking at some of the test sources in the tests
directory for some code examples.
Tomas
On Wed, 2021-09-15 at 10:34 +, Shivakumar Poojari wrote:
> Hi Tomas,
> As Engine function are deprecated I tried using providers
>
> But how to use providers to get engine functionality tried in man
> pages
>
> Some sample program will help, maybe some sample program will give the
> clear idea how to use provider
>
> Struggling in understand the providers
>
> Please share the sample program and the links to understand the
> providers
>
> Thanks,
> shiva kumar
> From: Tomas Mraz
> Sent: Wednesday, September 8, 2021 7:00 PM
> To: Shivakumar Poojari ;
> openssl-users@openssl.org
> Cc: Paramashivaiah, Sunil ;
> Bhattacharjee, Debapriyo (c)
> Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0
> Hello,
>
> there is no direct replacement. The ENGINEs as a pluggable crypto
> modules concept is replaced with the providers concept which is much
> more sophisticated and capable.
>
> Please look at
> https://clicktime.symantec.com/3NTnN1ZFia2bCryEiZnkRmY6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman7%2Fmigration_guide.html
>
> ENGINEs support is not removed from OpenSSL 3.0 however it is
> deprecated. If you cannot use deprecated functions you have to drop
> support for engines which means those functions just should not be
> called and there is no replacement.
>
> Providers allow for configuration via the default configuration file so
> for an application to support crypto modules in form of providers the
> application does not necessarily have to have any extra functions
> called. Just the default configuration file has to be present and the
> configuration of the desired provider(s) needs to be there.
>
> Tomas
>
>
> On Wed, 2021-09-08 at 13:07 +, Shivakumar Poojari wrote:
> > Hi
> > Upgrading our code to openssl 3.0. the below function we trying to
> > replace
> >
> > ENGINE_load_dynamic()
> >
> > Replacment for 3.0 what i
> > found OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL)
> >
> > ENGINE_by_id("dynamic")
> >
> > ENGINE_ctrl_cmd_string()
> >
> > ENGINE_set_default()
> >
> > ENGINE_get_DH()
> >
> > ENGINE_free()
> >
> > Need a replacement for the above-highlighted function. I searched in
> > man pages did not find any replacement and searched in google for
> > sample programs also not found
> >
> >
> > Thanks,
> > shiva kumar.
> >
> >
> >
> >
> >
> >
> >
> >
> > Notice: This e-mail together with any attachments may contain
> > information of Ribbon Communications Inc. and its Affiliates that is
> > confidential and/or proprietary for the sole use of the intended
> > recipient. Any review, disclosure, reliance or distribution by others
> > or forwarding without express permission is strictly prohibited. If
> > you
> > are not the intended recipient, please notify the sender immediately
> > and then delete all copies, including any attachments.
>
--
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: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY
On Tue, 2021-09-14 at 14:42 -0400, Ken Goldman wrote: > On 9/14/2021 11:40 AM, Tomas Mraz wrote: > > On Tue, 2021-09-14 at 11:11 -0400, Ken Goldman wrote: > > > Conceptually, how are these different? > > > > > > When do I use one vs the other? > > > > The EVP_PKEY is an object holding data (well, rather a reference, > > but > > that is fairly irrelevant) of a private key, public key, or domain > > parameters for asymetric crypto keys. > > > > The EVP_PKEY_CTX is an operation context - that is a context to > > make > > some operations with an EVP_PKEY such as signing/verification, > > encryption/decryption, key generation (starting with domain > > parameters > > EVP_PKEY), key checking. > > > > > Where would I learn this? > > > > I suppose in the manual pages - I'd start with EVP_PKEY_new and > > EVP_PKEY_CTX_new man pages. Yeah, the discoverability is not that > > good > > I suppose. And there is no good high level overview. > > In other words, the EVP_PKEY holds the public key. When I want to > use > it to encrypt / verify, I create a temporary EVP_PKEY_CTX? Is that > it? > Do I also use a ctx to initialize the key? > > Perhaps, to make the EVP_PKEY from n and e.: > > OSSL_PARAM_BLD_push_BN() for n and e parameters > EVP_PKEY_CTX_new_from_name the RSA > EVP_PKEY_fromdata using the parameters Yes, you've got this right. There are some cases where you do not need an EVP_PKEY_CTX to get an EVP_PKEY - such as using decoders to decode a key from a file. -- 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: OpenSSl 3 statically linking a provider
On Tue, 2021-09-14 at 21:46 -0700, Kory Hamzeh wrote: > I have written a custom provider which I need to include (link) with > my Application at link time rather than load it at run-time. The init > function is defined like this: > > OSSL_provider_init_fn sck_provider_init; > > int sck_provider_init(const OSSL_CORE_HANDLE *handle, > const OSSL_DISPATCH *in, > const OSSL_DISPATCH **out, > void **provctx) > > But I cannot figure out how to initialize/load it in my app. The man > page for provider(7) states that it is possible to do this, but does > not explain how. Is that documented somewhere? > > Thanks, > Kory Please see the manual page for the OSSL_PROVIDER_add_builtin function and the test/provfetchtest.c source code. -- 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: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY
On Tue, 2021-09-14 at 11:11 -0400, Ken Goldman wrote: > Conceptually, how are these different? > > When do I use one vs the other? The EVP_PKEY is an object holding data (well, rather a reference, but that is fairly irrelevant) of a private key, public key, or domain parameters for asymetric crypto keys. The EVP_PKEY_CTX is an operation context - that is a context to make some operations with an EVP_PKEY such as signing/verification, encryption/decryption, key generation (starting with domain parameters EVP_PKEY), key checking. > Where would I learn this? I suppose in the manual pages - I'd start with EVP_PKEY_new and EVP_PKEY_CTX_new man pages. Yeah, the discoverability is not that good I suppose. And there is no good high level overview. -- 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.]
Blog post about Let's Encrypt root certificate expiration and OpenSSL 1.0.2
I've written a blog post to explain the situation with the old Let's Encrypt root certificate expiration which will happen on 2021-09-30 and the behavior of OpenSSL 1.0.2 with that root certificate. Please read, if interested: https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ Regards, -- 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: openssl 3.0.0 legacy provider won't lload via config file
On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote: > I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, everything > seems to be working fine, except for the fact that I cannot get > OpenSSL to load the legacy module when I configure /ssl/openssl.cnf > as such. I can, however, load the module explicitly at run time. > ... > > The EVP_DecryptInit_ex() fails if I compile without -DLOAD_PROVIDER. > The other flag, CRYPTO_INIT does not make any difference. What is > puzzling is that I can build OpenSSL natively on an x86_64 machine > and using the same openssl.cnf file, the code above works and the > legacy module loads without the code to explicitly load it. > > Any thoughts on what I may have done wrong or how to track this down? Could it be that your cross-compiled build expects the configuration file to be somewhere else? Have you tried to strace the application to see where it searches for the openssl.cnf? -- 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: ENGINE API replacement for Openssl3.0
Hello,
there is no direct replacement. The ENGINEs as a pluggable crypto
modules concept is replaced with the providers concept which is much
more sophisticated and capable.
Please look at
https://www.openssl.org/docs/man3.0/man7/migration_guide.html
ENGINEs support is not removed from OpenSSL 3.0 however it is
deprecated. If you cannot use deprecated functions you have to drop
support for engines which means those functions just should not be
called and there is no replacement.
Providers allow for configuration via the default configuration file so
for an application to support crypto modules in form of providers the
application does not necessarily have to have any extra functions
called. Just the default configuration file has to be present and the
configuration of the desired provider(s) needs to be there.
Tomas
On Wed, 2021-09-08 at 13:07 +, Shivakumar Poojari wrote:
> Hi
> Upgrading our code to openssl 3.0. the below function we trying to
> replace
>
> ENGINE_load_dynamic()
>
> Replacment for 3.0 what i
> found OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL)
>
> ENGINE_by_id("dynamic")
>
> ENGINE_ctrl_cmd_string()
>
> ENGINE_set_default()
>
> ENGINE_get_DH()
>
> ENGINE_free()
>
> Need a replacement for the above-highlighted function. I searched in
> man pages did not find any replacement and searched in google for
> sample programs also not found
>
>
> Thanks,
> shiva kumar.
>
>
>
>
>
>
>
>
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. and its Affiliates that is
> confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or distribution by others
> or forwarding without express permission is strictly prohibited. If you
> are not the intended recipient, please notify the sender immediately
> and then delete all copies, including any attachments.
--
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: Query regarding openssl-3.0.0 ecdsa self tests
It is not a bug, the pairwise test is sufficient. It's just a misleading name. And I do not think it will cause any problem with FIPS validation, this can be documented. Tomas On Mon, 2021-08-30 at 16:53 +0530, Nagarjun J wrote: > Hello, > > Then, is this a bug in ECDSA POST ? Or have to rename the test , as > it is misleading and can cause problems in FIPS certification ? > > Thanks, > Nagarjun > > On Mon, Aug 30, 2021 at 3:51 PM Tomas Mraz wrote: > > The question was about the fips module POST (power on self test) > > and > > there what I wrote applies. Having special RNG providing constant > > data > > to ECDSA/DSA would be possible to do but it is not required, it > > would > > needlessly complicate the code, and add a risk of having such > > constant > > RNG being accidentally used for something where real random numbers > > are > > needed. > > > > Tomas > > > > On Mon, 2021-08-30 at 13:17 +0300, Billy Brumley wrote: > > > This is not really true. At least, for some of the tests. > > > > > > https://github.com/openssl/openssl/blob/master/test/ecdsatest.c#L73 > > > > > > That hijacks the RNG to feed the expected nonce, so it can check > > > vs > > a > > > KAT. > > > > > > Cheers, > > > > > > BBB > > > > > > On Mon, Aug 30, 2021 at 12:40 PM Tomas Mraz > > > wrote: > > > > > > > > Hello, > > > > > > > > your analysis is right. It does only pairwise consistency test > > > > as > > > > the > > > > KAT is impossible to do for regular DSA and ECDSA due to random > > > > nonce > > > > being input of the signature algorithm and thus the signature > > > > always > > > > changes. > > > > > > > > Tomas > > > > > > > > On Fri, 2021-08-27 at 22:47 +0530, Nagarjun J wrote: > > > > > Hi, > > > > > > > > > > Does openssl-3.0.0 really does ecdsa KAT ? The post test logs > > > > > says > > > > > "ECDSA KAT :PASS. But when i debuged the code it actually > > > > > doing > > > > > ECDSA > > > > > pairwise consistency test. > > > > > > > > > > Thanks, > > > > > Nagarjun > > > > > > > > -- > > > > 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.] > > > > > > > > > > -- 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.]
