While RSA encrypt/decrypt and sign/verify are basically the same mod-expo
operations, the speed of the operation may still differ, due to different
padding, as well as the use of implicit rejection for RSA decrypt.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21383)
Also fixes a similar regression in X509_VERIFY_PARAM_add0_table().
Commit 38ebfc3 introduced a regression in 3.0.6 that changed the return
value of the two functions above from 1 on success to the number of entries
in the stack. If there are more than one entry then this is a change in
behaviour which should not have been introduced into a stable release.
This reverts the behaviour back to what it was prior to the change. The code
is slightly different to the original code in that we also handle a possible
-1 return value from the stack push function. This should never happen in
reality because we never pass a NULL stack as a parameter - but for the sake
of robustness we handle it anyway.
Note that the changed behaviour exists in all versions of 3.1 (it never had
the original version). But 3.1 should be fully backwards compatible with 3.0
so we should change it there too.
Fixes#21570
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/21576)
Fixes#21569
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21569)
Running LSX instructions requires both the hardware support and the
kernel support. The `cpucfg` instruction only tests the hardware
support, causing a SIGILL if the hardware supports LSX but the kernel
does not.
Use `getauxval(AT_HWCAP)` as the ["Software Development and Build
Convention for LoongArch Architectures"][1] manual suggests.
The LOONGARCH_HWCAP_LSX and LOONGARCH_HWCAP_LASX bits are copied from
the manual too. In Glibc 2.38 they'll be provided by <sys/auxv.h> as
well, but they are unavailable in earlier Glibc versions so we cannot
rely on it.
The getauxval syscall and Glibc wrapper are available since day one
(Linux-5.19 and Glibc-2.36) for LoongArch.
Fixes#21508.
[1]:https://github.com/loongson/la-softdev-convention/blob/master/la-softdev-convention.adoc#kernel-constraints
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21509)
Fixes#21554
CLA: trivial
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21562)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21545)
Apply normal sentence case to db update message
CLA: trivial
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21535)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21550)
This must fail with DH_CHECK_INVALID_Q_VALUE and
with DH_CHECK_Q_NOT_PRIME unset.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21550)
If |q| >= |p| then the q value is obviously wrong as q
is supposed to be a prime divisor of p-1.
We check if p is overly large so this added test implies that
q is not large either when performing subsequent tests using that
q value.
Otherwise if it is too large these additional checks of the q value
such as the primality test can then trigger DoS by doing overly long
computations.
Fixes CVE-2023-3817
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/21550)
The pre-existing error cases where DH_check returned zero
are not related to the dh params in any way, but are only
triggered by out-of-memory errors, therefore having *ret
set to zero feels right, but since the new error case is
triggered by too large p values that is something different.
On the other hand some callers of this function might not
be prepared to handle the return value correctly but only
rely on *ret. Therefore we set some error bits in *ret as
additional safety measure.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21524)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21515)
CLA: trivial
The purpose of adding the conditional operator on line 710 is to check
if the value of the variable 'fplace' exceeds the size of the array
'fconvert', and to reduce the value of 'fplace' by 1, so that later on
we can set the value to zero of the array element with the index 'fplace'
and not make any calls beyond the array edges.
However, the condition on line 710 will always be false, because
the size of 'fconvert' is strictly specified at the beginning of
the 'fmtfp()' function (line 571), so it is reasonable to remove
this conditional operator, as well as the unreachable decrementation
code of the variable 'fplace'.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21325)
When an early error happens in the test_pipelining
function and idx == 5 the error handling would try
to call OPENSSL_free(msg), but msg is at that time
just a string constant in read-only memory, so a
crash would be the result. Fixed that by using
fragsize as an indication when to free msg.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21512)
Function `X509at_add1_attr()` (crypto/x509/x509_att.c) rejects to add a duplicity into `*x` but it searches in a wrong stack.
Changed to search in `*x`.
CLA: trivial
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21505)
Change-Id: I57723835b0a7d20609d8c4ed2988123f975a927d
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21495)
The hardware-assisted ARMv8.2 implementation is already in keccak1600-armv8.pl.
It is not called because the author mentioned that it's not actually obvious
that it will provide performance improvements. The test on Apple M1 Firestorm
shows that the ARMv8.2 implementation could improve about 36% for large blocks.
So let's enable ARMv8.2 accelerated SHA3 on Apple CPU family.
Fixes#21380
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21398)
Running 'openssl speed eddsa' fails with
Doing 253 bits sign Ed25519 ops for 10s: EdDSA sign failure
000003FF9306C7D0:error:030000BC:digital envelope routines:EVP_DigestSign:
final error:crypto/evp/m_sigver.c:585:
-1 253 bits Ed25519 sign ops in 0.00s
Doing 253 bits verify Ed25519 ops for 10s: EdDSA verify failure
000003FF9306C7D0:error:030000BC:digital envelope routines:EVP_DigestVerify:
final error:crypto/evp/m_sigver.c:694:
-1 253 bits Ed25519 verify ops in 0.00s
This is because the EVP_DigestSign/Verify() calls in the EdDSA_sign/verify_loop()
fail because the context has already been finalized by the previous
EVP_DigestSign/Verify call during the EdDSA signature test done by speed_main().
This happens since commit 3fc2b7d6b8 where the
EVP_DigestSign/Verify() functions have been changed to set a flag that the
context has been finalized.
Fix this by re-initializing the context using EVP_DigestSign/Verify() in the
EdDSA_sign/verify_loop().
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21491)
Free the signature stack after iterating over all found signatures.
Free the kem and signature stacks at the end of speed_main() if not
NULL.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21491)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
Confirm that the only errors DH_check() finds with DH parameters with an
excessively long modulus is that the modulus is too large. We should not
be performing time consuming checks using that modulus.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.
There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.
An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.
The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().
CVE-2023-3446
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)
