Re: [External] : Why do I get the following error `wrong signature length` when I try to validate a signed file using the c++ OpenSSL 3.1 library?

[Thomas Dwyer III via openssl-users]

|if (EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0)|


The sizeof operator is not doing what you think it's doing. It's 
computing the sizes of the pointers (typically 4 or 8 bytes depending on 
your architecture) and not the sizes of your signature & signed content. 
You need to pass additional size_t values to your verifyLicense() 
function so that EVP_PKEY_verify() can know what those lengths really 
are. It's impossible to determine this from just a char* pointer.



Tom.III


On 6/10/24 13:15, Christian F. Gonzalez Di Antonio wrote:
I posted this on 
https://stackoverflow.com/questions/78604338/why-do-i-get-the-following-error-wrong-signature-length-when-i-try-to-validate 
 



I'm writing an c++ program LicenseValidator -> 
https://github.com/christiangda/LicenseValidator 
 to 
validate a hypothetical |program license| using OpenSSL 3.1 Library 
, 
and when I tried to validate the licensed content I got the following 
error:


|Failed to verify license 008C1AF90100:error:0277:rsa 
routines:ossl_rsa_verify:wrong signature 
length:crypto/rsa/rsa_sign.c:338: 
008C1AF90100:error:1C880004:Provider routines:rsa_verify:RSA 
lib:providers/implementations/signature/rsa_sig.c:785: |


I would appreciate any help or guidance on what I am doing wrong.

I am not at all an expert in the c/c++ programming language and this 
is the first time I have tried to use the OpenSSL library.


Of course, I've used GitHub Copilot, gemini, and chatgpt to write and 
understand the repository code. The chalenge is about the examples I 
found on internet, the majority of them are about OpenSSL v1 and the 
v3 is very different, so was hard to understand the migration.


The README.md 
 file 
has the instructions to create all the necessary keys, etc, references 
I used and the instructions to compile it using cmake.


The core function is LicenseValidator/src/License.cpp 
:


|bool verifyLicense(const unsigned char *licenseContent, const 
unsigned char *licenseSignature, const std::string pubkey) { EVP_PKEY 
*pkey = loadRsaPemPubKey(pubkey); if (pkey == NULL) { std::cerr << 
"Failed to load public key" << std::endl; ERR_print_errors_fp(stdout); 
return false; } EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(pkey, NULL); if 
(ctx == NULL) { std::cerr << "Failed to create EVP_PKEY_CTX" << 
std::endl; EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return 
false; } if (EVP_PKEY_verify_init(ctx) <= 0) { std::cerr << "Failed to 
initialize EVP_PKEY_CTX" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } // 
PKCS1 padding scheme if (EVP_PKEY_CTX_set_rsa_padding(ctx, 
RSA_PKCS1_PADDING) <= 0) { std::cerr << "Failed to set RSA padding" << 
std::endl; EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); 
ERR_print_errors_fp(stdout); return false; } // SHA256 digest if 
(EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) { std::cerr << 
"Failed to set signature MD" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } if 
(EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0) { std::cerr << "Failed 
to verify license" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } 
EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); return true; } |


Some guidance about how to solve the error I got.


--
Saludos,
Christian

Re: [External] : Re: BIO_read() crash

[Thomas Dwyer III]

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?



Tom.III


||
On 12/5/22 02:24, Tomas Mraz wrote:

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.

OpenSSL FIPS certificate #4282

[Thomas Dwyer III]

The OpenSSL project has obtained certificate #4282

from NIST for the FIPS provider. Nice. However, the certificate and
accompanying security policy specifically list version 3.0.0 while the
current release is 3.0.7. There have been CVEs & bugfixes since the 3.0.0
release but it's not clear whether any of those directly affected the FIPS
provider. Can someone from the OpenSSL project comment on the
viability/suitability of using the 3.0.0 FIPS provider with a 3.0.7
libcrypto/libssl?


Thanks,
Tom.III

Re: OpenSSL 3.0 FIPS module configuration file

[Thomas Dwyer III]

I believe the relevant standard is described in the Implementation Guidance
for FIPS 140-2:
https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf
(see IG 9.11 beginning on page 179). I searched briefly for similar text in
FIPS 140-3 IG but didn't see anything relevant.


Tom.III


On Mon, Feb 14, 2022 at 3:31 PM 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
>
>
>

Re: Set X509 public key in 1.0.2

[Thomas Dwyer III]

1.0.2 has X509_PUBKEY_get() (without the zero) which I believe increases
the reference count on the EVP_PKEY.


Tom.III


On Fri, Aug 20, 2021 at 3:31 PM Ken Goldman  wrote:

> I have an X509_PUBKEY structure holding the algorithm and public key.
> I want to set it in the X509 structure.
>
> In 1.1.1 and up, I can use
>
> evpPubkey = X509_PUBKEY_get0(addToCert->key);   /* X509_PUBKEY */
> X509_set_pubkey(x509Certificate, evpPubkey);
>
> However, 1.0.2 doesn't have these.
>
> What's a good approach?
>
> I could access the X509.cert_info.key and set the
> value, but I expect that would cause a double free later
> when I free both the X509 and the structure holding the
> X509_PUBKEY.
>
> Is the something like a X509_PUBKEY_dup function?
>
> (Yes, I know that 1.0.2 is obsolete, but there are some LTS
> distros, and I'd rather not drop support for 1.0.2 if I can
> figure this out.)
>
>
>

Re: EVP_MAC_init - specify the hash algorithm

[Thomas Dwyer III]

Thanks for that example. It's very helpful! I didn't know about the new
EVP_MAC API (although I see it now in the migration guide). I wrote my
implementation based on
https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying :-)


Tom.III


On Tue, Jul 13, 2021 at 4:07 PM Dr Paul Dale  wrote:

> Please don't do it the PKEY way :)
>
> Your code should look more like:
>
> OSSL_PARAMS params[2];
> EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL);
> EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac);
> EVP_MAC_free(mac); /* Now or later is all good and depends on the app
> reusing it or not */
>
> params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0);
> params[1] = OSSL_PARAMS_construct_end();
>
> EVP_MAC_init(mac_ctx, key, key_len, params);
> EVP_MAC_update(mac_ctx, data1, data1_len);
> EVP_MAC_update(mac_ctx, data2, data2_len);
> EVP_MAC_update(mac_ctx, data3, data3_len);
> EVP_MAC_final(mac_ctx, out, _size, out_len);
> EVP_MAC_CTX_free(mac_ctx);
>
> There are various other calls that tweak the flow but this is the basic
> idea.
>
>
> Pauli
>
> On 14/7/21 8:48 am, Thomas Dwyer III wrote:
>
> This seems to work for me in 3.0, passing the EVP_MD to
> EVP_DigestSignInit():
>
> pkey = EVP_PKEY_new_mac_key()
> EVP_DigestSignInit()
> EVP_DigestSignUpdate()
> EVP_DigestSignUpdate()
> .
> .
> .
> EVP_DigestSignFinal()
>
>
> Regards,
> Tom.III
>
>
>
> On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman  wrote:
>
>> Porting to 3.0 ... HMAC_Init_ex() had a place for
>> the hash algorithm.  EVP_MAC_init() does not,
>> unless it's embedded in the 'params' parameter.
>>
>> Any advice?  Or a sample for doing an
>> HMAC with 3.0?
>>
>>
>

Re: EVP_MAC_init - specify the hash algorithm

[Thomas Dwyer III]

This seems to work for me in 3.0, passing the EVP_MD to
EVP_DigestSignInit():

pkey = EVP_PKEY_new_mac_key()
EVP_DigestSignInit()
EVP_DigestSignUpdate()
EVP_DigestSignUpdate()
.
.
.
EVP_DigestSignFinal()


Regards,
Tom.III



On Tue, Jul 13, 2021 at 11:02 AM Ken Goldman  wrote:

> Porting to 3.0 ... HMAC_Init_ex() had a place for
> the hash algorithm.  EVP_MAC_init() does not,
> unless it's embedded in the 'params' parameter.
>
> Any advice?  Or a sample for doing an
> HMAC with 3.0?
>
>

Is SSL_CTX_set_tmp_rsa_callback() only for small keys?

[Thomas Dwyer III]

I'm porting some very old code from 1.0.2 to 3.0 (but it still has to
compile for both) and I'm trying to understand it's use of
SSL_CTX_set_tmp_rsa_callback(). It looks like this was removed in 1.1.0 but
it's not obvious to me why it was necessary in the first place. My read of
the 1.0.2 man page suggests that the callback is only invoked for very
small key sizes in order to comply with US export restrictions from decades
ago, but I'm having trouble confirming this via code inspection. Is my
understanding correct and, given that this code will never see RSA keys
smaller than 2048 bits, I can just delete the callback rather than add a
bunch of:

#if OPENSSL_VERSION_NUMBER < 0x1010L
...
#endif

Or is there some fundamental difference between the way key exchange works
in 1.0.2 compared to later versions that makes the callback in 1.0.2 still
necessary?


Thanks,
Tom.III

Re: Format error in certificate´s notAfter field

[Thomas Dwyer III]

This certificate is not the same one causing the error message in your
original email. The error message you provided earlier included
"serial=17702460327850242852" (or f5:ab:c5:e0:63:f5:73:24 in hex) but the
certificate you provided here has serial=16005263760024127372
(de:1e:1e:97:18:ab:c7:8c).


Tom.III


On Sun, Dec 27, 2020 at 11:50 PM Raúl Uría Elices  wrote:

> Here it is:
>
> -BEGIN CERTIFICATE-
> MIIESjCCA7OgAwIBAgIJAN4eHpcYq8eMMA0GCSqGSIb3DQEBCwUAMIGjMQswCQYD
> VQQGEwJlczEVMBMGA1UEBxMMUGVuYWNhc3RpbGxvMSYwJAYDVQQKEx1OT1JCRVJU
> IERFTlRSRVNTQU5HTEUgR0VSUE9TQTEyMDAGA1UEAxMpTk9SQkVSVCBERU5UUkVT
> U0FOR0xFIEdFUlBPU0EgV2ViQWRtaW4gQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWlu
> QGFzdGFyby5sb2NhbDAeFw0xNzA5MDgxNTQ0NTJaFw0zNjA3MTgxNTEyMThaMGsx
> CzAJBgNVBAYTAmVzMRUwEwYDVQQHDAxQZW5hY2FzdGlsbG8xJjAkBgNVBAoMHU5P
> UkJFUlQgREVOVFJFU1NBTkdMRSBHRVJQT1NBMR0wGwYDVQQDDBRhc2cyMjAuZ2Vy
> cG9zYS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+gNXRC
> WtsP9LANPgFJ1vj1/6naVUiHBq+AKgPePwOK6qbUczG+E8Zh8xr/JpcCjdrTLZNF
> rllVoEodthSvKnlaMI7qIgDWQE3MtVot5ARAZHFMob2uy3zeZ/uJniheYmj7BNy2
> d6pkFzlZyPiNh65KIBbEuZEKAgKQwRAduYWk+689p2Jnujj13yodpOuGPSjr9inz
> qLTK1GIkTf51O6GMGiu5erj27LHKAJojAVSjMDJ1AeDAsNg+RLLDP/q+Fi0wLUwL
> MPq2rhiXZvVPjU/iukiwrzNHqwZTIwpayNatjoskKE/KS+ldEIhMlythOiPVWgYs
> zAUdD1G3HL4cQgECAwEAAaOCATcwggEzMB0GA1UdDgQWBBQqUYZktt2XccSH1Sp2
> g8y8zwZ3nzCB2AYDVR0jBIHQMIHNgBSXppMhHL+r08UaJqK9kW36GvpusaGBqaSB
> pjCBozELMAkGA1UEBhMCZXMxFTATBgNVBAcTDFBlbmFjYXN0aWxsbzEmMCQGA1UE
> ChMdTk9SQkVSVCBERU5UUkVTU0FOR0xFIEdFUlBPU0ExMjAwBgNVBAMTKU5PUkJF
> UlQgREVOVFJFU1NBTkdMRSBHRVJQT1NBIFdlYkFkbWluIENBMSEwHwYJKoZIhvcN
> AQkBFhJhZG1pbkBhc3Rhcm8ubG9jYWyCCQDeHh6XGKvHijAfBgNVHREEGDAWghRh
> c2cyMjAuZ2VycG9zYS5sb2NhbDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DANBgkq
> hkiG9w0BAQsFAAOBgQAqsvoAFxWEWSxZHtEgDHEBfflBJEm3QqAl8bMb3O4rOnIV
> ufq/dkAx6AYzmtFZhWMIJnh4ZTU8ULjuAkqC2yXEBktpSR9VQFKabToLSuAW9QC7
> Db2ELKw8kXQgFxS0nkDhEgAitukcJ8TuVq7hlvRVwC6vnRRdKYaaT5cERZbDOg==
> -END CERTIFICATE-
>
>
>
>

Re: PRNG not available when multiple providers are configured?

[Thomas Dwyer III]

On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell  wrote:

>
>
> On 03/11/2020 00:55, Thomas Dwyer III wrote:
> > I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
> > has both the default provider and the fips provider configured at the
> > same time:
> >
> > openssl_conf = openssl_init
> >
> > [openssl_init]
> > providers = provider_sect
> >
> > [provider_sect]
> > default = default_sect
> > fips = fips_sect
> >
> > [default_sect]
> > activate = 1
> >
> > .include /conf/openssl/fips.cnf
> >
> > If I remove either default or fips from [provider_sect] then
> > RAND_status() returns 1. If I leave them both specified there,
> > RAND_status() always returns 0. Is this the expected behavior or am I
> > doing something wrong? I understand that I must specify properties when
> > fetching algorithms in order to get deterministic behavior with multiple
> > providers loaded. Is there an analogous API for the PRNG that I'm
> > overlooking?
> >
> > Interestingly, setting activate=0 for either provider is not sufficient
> > to work around this issue.
>
> I tested this out and was able to replicate your behaviour.
>
> The reasons are a little complicated (see below) but the TL;DR summary
> is that there is an error in your config file. The ".include" line
> should specify a config file relative to OPENSSLDIR (or
> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
> hence fips.cnf is not being found.
>


This explanation does not match my observations. strace clearly shows my
fips.cnf getting opened and read when my openssl.cnf has an absolute path.
Likewise, strace shows stat64("fips.cnf", ...) failing (and thus no
subsequent open() call) when I use a relative path. Furthermore, the
documentation at https://www.openssl.org/docs/manmaster/man5/config.html
says this should be an absolute path.

That said, see below..



> I've seen this error a few times now so I'm thinking that we should
> perhaps allow absolute paths. I'm not sure what the reason for
> disallowing them was.
>
> The reason it works if you comment out the "default" line is because
> that means the only provider left is the FIPS one. But the config line
> for that is faulty and therefore activating it fails. Ultimately we have
> not succesfully activated any provider. When you call RAND_status() it
> will attempt to fetch the RAND implementation and find that no providers
> have been activated. In this case we fallback and automatically activate
> the default provider. Hence you end up with RAND_status() still working.
>
> If you comment out the "fips" line then it works because it doesn't
> attempt to do anything with the fips provider, successfully activates
> the default provider, and hence RAND_status() works as expected.
>
> If you have both lines in the config file then it first successfully
> activates the default provider. It next attempts to activate the fips
> provider and fails. The way the config code works is that if any of the
> configured providers fail to activate then it backs out and deactivates
> all of them. At this point we're in a situation where a provider has
> been successfully activated and then deactivated again. The fallback
> activation of the default provider only kicks in if you've not attempted
> to activate any providers by the time you first need one. Therefore the
> default provider doesn't activate as a fallback either. Ultimately you
> end up with no active providers and RAND_status() fails.
>

Ah ha! This explanation makes sense to me and indeed pointed me at the real
problem. I had recompiled OpenSSL but I forgot to update the hmac in
fips.cnf via fipsinstall. So yes, the fips provider was failing to activate
because of that. As soon I fixed the hmac RAND_status() started working for
me. So THANKS for that! :-)


Tom.III




> We really should have a way of getting more verbose output in the event
> of config issues like this.
>
> Matt
>

PRNG not available when multiple providers are configured?

[Thomas Dwyer III]

I'm having trouble getting RAND_status() to return 1 when my openssl.cnf
has both the default provider and the fips provider configured at the same
time:

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
fips = fips_sect

[default_sect]
activate = 1

.include /conf/openssl/fips.cnf

If I remove either default or fips from [provider_sect] then RAND_status()
returns 1. If I leave them both specified there, RAND_status() always
returns 0. Is this the expected behavior or am I doing something wrong? I
understand that I must specify properties when fetching algorithms in order
to get deterministic behavior with multiple providers loaded. Is there an
analogous API for the PRNG that I'm overlooking?

Interestingly, setting activate=0 for either provider is not sufficient to
work around this issue.


Thanks,
Tom.III

Re: 3 failures with Openssl 3 alpha

[Thomas Dwyer III]

On Wed, Oct 7, 2020 at 7:33 AM The Doctor  wrote:

> 1) The openssh project does not work  openssh 8.4+
>

This is a problem with the openssh codebase and not with openssl. You asked

about this in openssh-unix-dev back in July. I posted this reply

in August. The issue is that openssh needs the "current" IV state (which
the now-deprecated EVP_CIPHER_CTX_iv() used to return) but it's calling the
wrong openssl function to obtain it. See PR #12233
 for additional discussion.


Regards,
Tom.III



> 2) Rust and OPEnssl 3 are not agrreing
>
> 3) ca_root_nss project and openssl 3 have a difference of opinion.
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> Look at Psalms 14 and 53 on Atheism
> https://www.empire.kred/ROOTNK?t=94a1f39b
> BC save the Province; on 24 October 2020, vote Liberal and not NDP!
>

Re: A question about the “localhost.key” and “localhost.crt” files.

[Thomas Dwyer III]

The filenames themselves are insignificant. You can name them anything you
want. The apache configuration file(s) contain key/value pairs where
SSLCertificateFile specifies the path to the file containing your
certificate and SSLCertificateKeyFile specifies the path to the file
containing your private key. There is no requirement that these filenames
match the name of your server. It sounds to me like you don't understand
how certificates work. I suggest you read a certificate tutorial such as
this one: http://www.steves-internet-guide.com/ssl-certificates-explained/

Once you understand how certificates work, I suggest reading the apache
documentation available here: https://httpd.apache.org/docs/current/ and,
specifically, the documentation for mod_ssl available here:
https://httpd.apache.org/docs/current/mod/mod_ssl.html


Regards,
Tom.III



On Fri, Sep 4, 2020 at 3:20 AM Jason Long via openssl-users <
openssl-users@openssl.org> wrote:

> Hello,
> I think “localhost.crt” and “localhost.key” files using by Apache and they
> are mandatory for get a HTTPS certificate. Some tools like "Certbot" need
> them.
> If these files deleted then how can I regenerate them? Is below command OK?
>
> # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
> /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt
>
> I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too?
>
> The "localhost" is the name of my server? If my server name in
> "/etc/hosts" file is "my-example.net" then these files name must be
> "my-example.net.key" and "my-example.net.crt" ?
>
> I'm thankful if anyone answer to my questions clearly.
>
> Thank you.
>

FIPS and default properties

[Thomas Dwyer III]

I'm struggling to understand how EVP_default_properties_is_fips_enabled()
works. I cannot get this function to return nonzero unless I first call
either EVP_default_properties_enable_fips() or
EVP_set_default_properties(), even when the config file sets
default_properties to enable fips.

Also, the return value of this function doesn't seem to have any effect on
which provider gets selected (which I think is what issue #11594
describes?).

My config file has the following:



*[openssl_init]providers = provider_sectalg_section = alg_sect*



*[provider_sect]fips = fips_sectdefault = default_sect*


*[default_sect]activate = 1*


*[alg_sect]default_properties = fips=yes*

*.include /path/to/fips.cnf*

I understand this to mean both the default provider and the fips provider
will be loaded into the default context, and both of these providers will
be activated. I also see that:

*EVP_MD_fetch(NULL, "sha256", NULL);*

returns a pointer which EVP_MD_provider() confirms as being from the fips
provider (as expected). Changing this to "fips=no" in the config file
results in EVP_MD_fetch() returning EVP_MD from the default provider, again
as expected. However, in both cases,
EVP_default_properties_is_fips_enabled() always returns zero. I don't see
anything in #11594 that would explain this.

Calling EVP_default_properties_enable_fips(NULL, 1) results in
EVP_default_properties_is_fips_enabled() returning 1, but this does not
appear to override the fips=no from the config file during EVP_MD_fetch()
(which is what I believe #11594 describes).

Is the result of EVP_default_properties_is_fips_enabled() supposed to take
into account the default properties specified in the config file? I don't
see it doing that. Also, regarding #11594, if default properties are
currently still broken, why do those in the config appear to work properly?

And finally the burning question: Any ETA on a fix? :-) :-) :-)


Thanks,
Tom.III

Re: openssl fipsinstall

[Thomas Dwyer III]

On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale  wrote:

> These are questions better asked of a FIPS lab since they are the experts
> and we are not.
>
>

That is a fair response.


I expect that your alternative installation process’s validity will depend
> on the security policy and what it says needs to be done.  This hasn’t been
> written yet so there is no answer at this point.
>
> Skipping the self tests is definitely not permitted.  The full suite of
> self tests *must* be run before the module can be used.
>
>

Oops, I didn't mean to suggest skipping the self-tests. I was talking about
the callback that fipsinstall currently uses to display results and/or
inject faults in the self-tests. I don't think I need that. As long as
OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the
self-tests passed at some point.



> You question prompts the possibility of making fipsinstall a standalone
> executable, this is something we could look into if we get time.  I expect
> we’d look favourably on a pull request that allowed either or both options.
>
>

This is encouraging. However, since there is no draft security policy
written yet would this be premature? Or are you suggesting that the
presence of a standalone tool might influence the contents of such a
security policy?


Thanks,
Tom.III



Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 28 Jul 2020, at 6:19 am, Thomas Dwyer III  wrote:
>
> Hi all,
>
> I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment
> with very limited flash space. We need and use libcrypto and libssl but we
> have no need for the openssl binary. To date it was never necessary to ship
> this utility in our product. Now with OpenSSL 3.0 it appears the only way
> to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS
> config file to be included by the main config file. However, at nearly 1MB
> in size this binary is prohibitively large.
>
> I am able to reproduce the output of "openssl fipsinstall ..." with a
> (considerably smaller) standalone tool that links with libcrypto and
> generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm
> unclear on what the actual FIPS requirements are for this. Would I still be
> considered FIPS compliant if I use my own standalone tool instead of the
> openssl binary to generate the FIPS config? I presume I don't need to
> bother with the self-test callback and that it only matters whether or not
> OSSL_PROVIDER_load(NULL, "fips") succeeds?
>
>
> Thanks,
> Tom.III
>
>
>

openssl fipsinstall

[Thomas Dwyer III]

Hi all,

I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment
with very limited flash space. We need and use libcrypto and libssl but we
have no need for the openssl binary. To date it was never necessary to ship
this utility in our product. Now with OpenSSL 3.0 it appears the only way
to get FIPS support is to run "openssl fipsinstall ..." to create a FIPS
config file to be included by the main config file. However, at nearly 1MB
in size this binary is prohibitively large.

I am able to reproduce the output of "openssl fipsinstall ..." with a
(considerably smaller) standalone tool that links with libcrypto and
generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm
unclear on what the actual FIPS requirements are for this. Would I still be
considered FIPS compliant if I use my own standalone tool instead of the
openssl binary to generate the FIPS config? I presume I don't need to
bother with the self-test callback and that it only matters whether or not
OSSL_PROVIDER_load(NULL, "fips") succeeds?


Thanks,
Tom.III

Re: [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Thomas Dwyer III]

I just created https://github.com/openssl/openssl/issues/12496 for this.


Regards,
Tom.III


On Sat, Jul 18, 2020 at 1:06 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> Thomas,
>
>
>
> > I consider this a bug, of course, but at least now I know what's causing
> it and how to work around it.
>
>
>
> thanks for sharing your analysis. Would you mind creating a GitHub issue
> for the hang?
>
>
>
> https://github.com/openssl/openssl/issues
>
>
>
> Matthias
>
>
>
>
>
>
>
> *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre*
>
> Senior Software Engineer
> matthias.st.pie...@ncp-e.com
> Phone: +49 911 9968-0
> www.ncp-e.com
>
>
> * Follow us on:* Facebook <https://www.facebook.com/NCPengineering> |
> Twitter <https://twitter.com/NCP_engineering> | Xing
> <https://www.xing.com/companies/ncpengineeringgmbh> | YouTube
> <https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn
> <http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>
>
> *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 • 90449
> • Nuremberg
> *North American HQ:* NCP engineering Inc. • 601 Cleveland Str., Suite
> 501-25 • Clearwater, FL 33755
>
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
> Dietrich
> Registry Court: Lower District Court of Nuremberg
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE
> 133557619
>
> This e-mail message including any attachments is for the sole use of the
> intended recipient(s) and may contain privileged or confidential
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please immediately
> contact the sender by reply e-mail and delete the original message and
> destroy all copies thereof.
>
> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen>
> <https://www.ncp-e.com/de/aktuelles/events/veranstaltungen>
>
> *From:* openssl-users  *On Behalf Of 
> *Thomas
> Dwyer III
> *Sent:* Friday, July 17, 2020 6:57 PM
> *To:* openssl-users 
> *Subject:* [SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider
>
>
>
> It turns out the problem was caused by a misinterpretation of the phrase
> "add the following lines near the beginning" in section 7.1 of the
> documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for
> enabling FIPS support. I added these lines to the very top of the file:
>
>
>
> openssl_conf = openssl_init
>
>
>
> .include /usr/local/ssl/fipsmodule.cnf
>
>
>
> [openssl_init]
>
> providers = provider_sect
>
>
>
> [provider_sect]
>
> fips = fips_sect
>
>
>
> This caused the existing default section to now become part of the
> [provider_sect] section. Apparently any name=value line in that particular
> section where no [value] section exists causes OpenSSL to hang at exit when
> the FIPS provider is used. I consider this a bug, of course, but at least
> now I know what's causing it and how to work around it.
>
>
>
> Regarding how to confirm which provider is actually providing a given
> algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD
> obtained via EVP_get_digestbyname() (even after it's used successfully by
> EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD
> obtained via EVP_MD_fetch(). Is this intentional?
>
>
>
>
>
> Tom.III
>
>
>

[SOLVED] Re: OpenSSL 3.0 hangs at exit with FIPS provider

[Thomas Dwyer III]

It turns out the problem was caused by a misinterpretation of the phrase
"add the following lines near the beginning" in section 7.1 of the
documentation at https://wiki.openssl.org/index.php/OpenSSL_3.0 for
enabling FIPS support. I added these lines to the very top of the file:

openssl_conf = openssl_init

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

[provider_sect]
fips = fips_sect


This caused the existing default section to now become part of the
[provider_sect] section. Apparently any name=value line in that particular
section where no [value] section exists causes OpenSSL to hang at exit when
the FIPS provider is used. I consider this a bug, of course, but at least
now I know what's causing it and how to work around it.

Regarding how to confirm which provider is actually providing a given
algorithm, I found that EVP_MD_provider() returns NULL for any EVP_MD
obtained via EVP_get_digestbyname() (even after it's used successfully by
EVP_DigestInit_ex()) but it returns a valid OSSL_PROVIDER for any EVP_MD
obtained via EVP_MD_fetch(). Is this intentional?


Tom.III


On Wed, Jul 15, 2020 at 10:20 AM Thomas Dwyer III  wrote:

> Platform: Linux x86_64
>
> I understand this is still alpha but how complete is the FIPS provider
> right now? I'm following the documentation at
> https://wiki.openssl.org/index.php/OpenSSL_3.0 but I'm having a problem
> where my application hangs during exit() when I use the "fips" provider. I
> reduced my code down to this minimal snippet that reproduces the problem:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int
> main(int argc, char **argv)
> {
> OSSL_PROVIDER *pvdr = NULL;
> EVP_MD_CTX *ctx;
> const EVP_MD *md;
> char *alg = "sha1";
> int rc = 0;
>
> pvdr = OSSL_PROVIDER_load(NULL, "fips");
> if (pvdr == NULL) {
> fprintf(stderr, "Error loading FIPS provider\n");
> exit(1);
> }
>
> md = EVP_get_digestbyname(alg);
> if (!md) {
> fprintf(stderr, "unknown digest '%s'\n", alg);
> exit(1);
> }
>
> ctx = EVP_MD_CTX_create();
>
> if (EVP_DigestInit_ex(ctx, md, NULL) != 1) {
> long err = ERR_get_error();
> char *msg = ERR_error_string(err, NULL);
> fprintf(stderr, "EVP_DigestInit_ex() failed: %s\n", msg);
> exit(1);
> }
>
> EVP_MD_CTX_destroy(ctx);
>
> rc = OSSL_PROVIDER_unload(pvdr);
> if (rc != 1) {
> fprintf(stderr, "Error unloading FIPS provider\n");
> exit(1);
> }
>
> printf("finished!\n");
> exit(0);
> }
>
> When I run this it prints "finished!" and then hangs in some kind of spin
> loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() allows it
> to exit successfully, as does inserting a call to OPENSSL_init_crypto() at
> the very top with the OPENSSL_INIT_NO_ATEXIT flag. Passing "default"
> instead of "fips" to OSSL_PROVIDER_load() also seems to work fine. What am
> I missing?
>
> Also, per section 7.8 of the wiki referenced above, I'm unable to confirm
> that the digest algorithm I want to use is being provided by the FIPS
> module. EVP_MD_provider(md) returns NULL even though the actual digest is
> computed correctly.
>
>
> Thanks,
> Tom.III
>
>
>

OpenSSL 3.0 hangs at exit with FIPS provider

[Thomas Dwyer III]

Platform: Linux x86_64

I understand this is still alpha but how complete is the FIPS provider
right now? I'm following the documentation at
https://wiki.openssl.org/index.php/OpenSSL_3.0 but I'm having a problem
where my application hangs during exit() when I use the "fips" provider. I
reduced my code down to this minimal snippet that reproduces the problem:

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

int
main(int argc, char **argv)
{
OSSL_PROVIDER *pvdr = NULL;
EVP_MD_CTX *ctx;
const EVP_MD *md;
char *alg = "sha1";
int rc = 0;

pvdr = OSSL_PROVIDER_load(NULL, "fips");
if (pvdr == NULL) {
fprintf(stderr, "Error loading FIPS provider\n");
exit(1);
}

md = EVP_get_digestbyname(alg);
if (!digest) {
fprintf(stderr, "unknown digest '%s'\n", alg);
exit(1);
}

ctx = EVP_MD_CTX_create();

if (EVP_DigestInit_ex(ctx, md, NULL) != 1) {
long err = ERR_get_error();
char *msg = ERR_error_string(err, NULL);
fprintf(stderr, "EVP_DigestInit_ex() failed: %s\n", msg);
exit(1);
}

EVP_MD_CTX_destroy(ctx);

rc = OSSL_PROVIDER_unload(pvdr);
if (rc != 1) {
fprintf(stderr, "Error unloading FIPS provider\n");
exit(1);
}

printf("finished!\n");
exit(0);
}

When I run this it prints "finished!" and then hangs in some kind of spin
loop consuming 100% CPU. Skipping the call to EVP_DigestInit_ex() allows it
to exit successfully, as does inserting a call to OPENSSL_init_crypto() at
the very top with the OPENSSL_INIT_NO_ATEXIT flag. Passing "default"
instead of "fips" to OSSL_PROVIDER_load() also seems to work fine. What am
I missing?

Also, per section 7.8 of the wiki referenced above, I'm unable to confirm
that the digest algorithm I want to use is being provided by the FIPS
module. EVP_MD_provider(md) returns NULL even though the actual digest is
computed correctly.


Thanks,
Tom.III

Re: OpenSSL shared library in FIPS mode

[Thomas Dwyer III]

On Tue, Jul 7, 2020 at 12:48 AM Dr Paul Dale  wrote:

> OpenSSL 1.0.2 ceased being supported at the beginning of this year.
>
> If you are deviating in any way from the prescribed build instructions
> (you did read the security policy didn’t you?) you are not FIPS compliant.
>

Can you confirm whether that statement applies to the entirety of building
libcrypto, or whether it's just the fipscanister.o component that requires
strict adherence to the build instructions documented in the security
policy?


Thanks,
Tom.III



> Not using the OpenSSL Makefile is such a deviation.  My suspicion is that
> you are not and never have been FIPS compliant.
>
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 7 Jul 2020, at 3:36 pm, Shirisha Dasari via openssl-users <
> openssl-users@openssl.org> wrote:
>
> Hi All,
>
> We have been trying to integrate FOM 2.0.13 with OpenSSL 1.0.2u for FIPS
> compliance. Post integration, we have been able to run in FIPS mode, with
> all self-tests passing as well. However, we seem to be encountering issues
> in creation and parsing of ECDSA keys.
>
> A little background on how we build the shared libcrypto library:
>
> TARGET: x86_64
> BUILD HOST: x86_64
>
> We do not use the OpenSSL Makefile to build the OpenSSL source. Our build
> infrastructure  creates multiple static archives from the OpenSSL crypto
> source and finally creates a libcrypto.a from these archives as required by
> fipsld. The fipscanister.o and libcrypto.a are archived to create the final
> libcrypto.a and passed onto fipsld for creation of a dynamic library,
> libcrypto.so. fips_premain_dso gets built as a part of the build process
> too for generation of signature. These steps mimic the OpenSSL opensource
> Makefile.
>
> fipsld embeds the signature into the final libcrypto.so successfully and
> we are able to get into FIPS mode successfully at run time. Self-tests pass
> as well.
>
> Issue:
>
> While trying to use ECDSA host keys for OpenSSH, we noticed that parsing
> of ECDSA key fails. DSA and RSA key creation and parsing do not have this
> issue. Note that the ECDSA key was generated in FIPS mode and is being
> parsed in FIPS mode itself.
>
> root@localhost:/home/admin#  openssl ec -in ssh_host_key_ecdsa -text
> -noout
> read EC key
> unable to load Key
> 140020611143360:error:10067066:elliptic curve
> routines:ec_GFp_simple_oct2point:invalid
> encoding:../../../../vendor/openssl-fips/crypto/ec/ecp_oct.c:370:
> 140020611143360:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC
> lib:../../../../vendor/openssl-fips/crypto/ec/ec_asn1.c:1172:
> 140020611143360:error:100D508E:elliptic curve
> routines:ECKEY_PRIV_DECODE:decode
> error:../../../../vendor/openssl-fips/crypto/ec/ec_ameth.c:256:
> 140020611143360:error:0606F091:digital envelope
> routines:EVP_PKCS82PKEY:private key decode
> error:../../../../vendor/openssl-fips/crypto/evp/evp_pkey.c:92:
> 140020611143360:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
> lib:../../../../vendor/openssl-fips/crypto/pem/pem_pkey.c:142:
> root@localhost:/home/admin#
>
> A portion of the sample ECDSA key generated with curve secp384r1 via
> ssh-keygen with "ssh-keygen -t ecdsa -b 384 -f  ssh_host_key_ecdsa" is
> provided below:
>
> -BEGIN PRIVATE KEY-
> MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDD
> 
> 
> -END PRIVATE KEY-
>
>  A few questions related to this:
>
> 1) Is there a specific need to build the OpenSSL source only via the
> provided Makefile?
> 2) FIPS self test for ECDSA passes but the key creation/parsing fails.
> Could this indicate that the FIPS module APIs are not getting invoked in
> the case of ECDSA?
>
> --
> Thanks & Regards,
> Shirisha.
>
>
>

EVP_PKEY_new_raw_private_key() vs EVP_PKEY_new_mac_key() ?

[Thomas Dwyer III]

Are EVP_PKEY_new_raw_private_key() and EVP_PKEY_new_mac_key() functionally
equivalent? They have very different implementations internally but appear
to produce identical results when used with EVP_DigestSignInit() and key
type EVP_PKEY_HMAC. The documentation says "works like" but it's not clear
whether that really means "equivalent". I'm trying to write portable
(openssl version agnostic) HMAC functions and I'm concerned about the note
that says "New applications should use EVP_PKEY_new_raw_private_key()
instead" when that doesn't exist prior to 1.1.1. Is this the recommended
solution?

#if OPENSSL_VERSION_NUMBER < 0x10101000L
EVP_PKEY *pkey = EVP_PKEY_new_mac_key(EVP_PKEY_HMAC, ...);
#else
EVP_PKEY *pkey = EVP_PKEY_new_raw_private_key(EVP_PKEY_HMAC, ...);
#endif


Thanks,
Tom.III

Minimum gcc version required for openssl 3.x?

[Thomas Dwyer III]

I searched all the docs I could find but I was unable to locate any
statements regarding gcc compatibility for openssl 3.x. I'm having a
problem cross-compiling for arm using gcc-4.4.5:

rm -f libssl.so && \
ln -s libssl.so.3 libssl.so
arm-linux-gnueabi-gcc  -Iinclude  -fPIC -pthread -Wall -O3 -DNDEBUG
-DL_ENDIAN -DOPENSSL_NO_COMP -MMD -MF engines/capi-dso-e_capi.d.tmp -MT
engines/capi-dso-e_capi.o -c -o engines/capi-dso-e_capi.o engines/e_capi.c
/workspace/XX/perl/bin/perl ./util/mkdef.pl --ordinals util/engines.num
 --name engines/capi --OS linux > engines/capi.ld
arm-linux-gnueabi-gcc -fPIC -pthread -Wall -O3 -L. -z defs -Wl,-znodelete
-shared -Wl,-Bsymbolic   \
-o engines/capi.so -Wl,--version-script=engines/capi.ld \
engines/capi-dso-e_capi.o \
-lcrypto -ldl -pthread
arm-linux-gnueabi-gcc: defs: No such file or directory
gmake[5]: *** [engines/capi.so] Error 1

I found that gcc-4.9.2 works fine (odd, see below), as does the following
patch:

$ git diff Configurations/shared-info.pl
diff --git a/Configurations/shared-info.pl b/Configurations/shared-info.pl
index a673c7c..461ce3c 100644
--- a/Configurations/shared-info.pl
+++ b/Configurations/shared-info.pl
@@ -36,7 +36,7 @@ my %shared_info;
 (grep /(?:^|\s)-fsanitize/,
  @{$config{CFLAGS}}, @{$config{cflags}})
 ? ''
-: '-z defs',
+: '-Wl,-z,defs',
 };
 },
 'bsd-gcc-shared' => sub { return $shared_info{'linux-shared'}; },

Although this works in gcc-4.9.2, it appears that the -z flag wasn't
documented until gcc-5.5. All Google hits I get for "-z defs" take me to
pages that show "-Wl,-z,defs" so it's curious that this particular option
isn't being passed with -Wl like the others. Is there a minimum supported
gcc version for openssl 3.x?


Thanks,
Tom.III

Re: Extracting the public modulus from an RSA public key?

[Thomas Dwyer III]

Ugh. So simple! I don't know how I missed that. I found get0 & get1
accessors for many other structures but I didn't see that one.


Thanks,
Tom.III


On Tue, May 5, 2020 at 9:50 PM Dr Paul Dale  wrote:

> Might I suggest reading the documentation?
>
> RSA_get0_n() is the function you are wanting.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 6 May 2020, at 2:20 pm, Thomas Dwyer III  wrote:
>
> I'm porting some old legacy code from OpenSSL 1.0.2 to OpenSSL 3.0.0. A
> portion of this code reads X509 certificates, extracts the public key, and
> passes it to firmware that I cannot modify. Unfortunately, this legacy
> firmware API was very poorly designed such that the public key is passed in
> a way similar to:
>
> RSA *rsa = get_pubkey_from_cert(...)
> BIGNUM *bn = rsa->n;
> int len = BN_num_bytes(bn);
> unsigned char *buf = malloc(len);
> BN_bn2bin(bn, buf);
> pubkey_to_firmware(buf, len);
>
> Yuck. Ignoring the fact that this firmware appears to assume a constant
> exponent 'e', I cannot find a way to extract the modulus 'n' from the RSA
> key. I understand this is intentional. The only solution I could find is to
> print the key to a buffer via EVP_PKEY_print_public(), parse the result to
> extract the modulus into a giant hex string, and then BN_hex2bn() that back
> into a BIGNUM. Is there a better way?
>
>
> Thanks,
> Tom.III
>
>
>

Extracting the public modulus from an RSA public key?

[Thomas Dwyer III]

I'm porting some old legacy code from OpenSSL 1.0.2 to OpenSSL 3.0.0. A
portion of this code reads X509 certificates, extracts the public key, and
passes it to firmware that I cannot modify. Unfortunately, this legacy
firmware API was very poorly designed such that the public key is passed in
a way similar to:

RSA *rsa = get_pubkey_from_cert(...)
BIGNUM *bn = rsa->n;
int len = BN_num_bytes(bn);
unsigned char *buf = malloc(len);
BN_bn2bin(bn, buf);
pubkey_to_firmware(buf, len);

Yuck. Ignoring the fact that this firmware appears to assume a constant
exponent 'e', I cannot find a way to extract the modulus 'n' from the RSA
key. I understand this is intentional. The only solution I could find is to
print the key to a buffer via EVP_PKEY_print_public(), parse the result to
extract the modulus into a giant hex string, and then BN_hex2bn() that back
into a BIGNUM. Is there a better way?


Thanks,
Tom.III

Re: OpenSSL version 3.0.0-alpha1 build failed

[Thomas Dwyer III]

For what it's worth, I also get similar perl crashes from the Configure
script. All of my build servers (which I do not control) have perl 5.10.1
installed on Oracle Linux 6.5. I tested with 5.12.5 and that also crashed
in the same way. 5.14.4 is the oldest version (stable branch) I could find
that worked.


Tom.III


On Thu, Apr 30, 2020 at 2:44 PM Matt Caswell  wrote:

> This appears to be a bug in perl. You have a very old version of perl
> (the oldest we support is 5.10.0). It's probably worth trying to upgrade
> it.
>
> Matt
>
>
> On 30/04/2020 22:12, Ken Goldman wrote:
> > My build failed with the below.
> >
> > x86_64 Linux kernel 2.6.32
> > RHEL 6.7
> > Perl 5.10.1
> >
> > Everything through 1.1.1e was successful.
> >
> > ~~
> >
> >
> > ./config
> > Operating system: x86_64-whatever-linux2
> > Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64
> > Using os-specific seed configuration
> > *** glibc detected *** /usr/bin/perl: double free or corruption (out):
> > 0x02a401e0 ***
> > === Backtrace: =
> > /lib64/libc.so.6[0x3c2fa75dee]
> > /lib64/libc.so.6[0x3c2fa78c80]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2]
> > /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419]
> > /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06]
> > /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8]
> > /usr/bin/perl(main+0x154)[0x400e74]
> > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d]
> > [snipped]
> >
>

EVP Signing and Verifying

[Thomas Dwyer III]

The first signing example at
https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying explicitly
calls both EVP_DigestInit_ex() and EVP_DigestSignInit(). Is the former
really necessary? It appears that the implementation of EVP_DigestSignInit()
in all versions of OpenSSL internally invokes EVP_DigestInit_ex() so I'm
confused by this example. Did I miss something?


Thanks,
Tom.III