Creating public key context from name would always fail
for composite signature algorithms (such as RSA-SHA256)
because the public key algorithm name (e.g., RSA) does
not match the name of the composite algorithm.
Relates to #27855.
Signed-off-by: Pavol Žáčik <zacik.pa@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28224)
Increase the maximum number of signature algorithms.
With the introduction of the SignMessage and VerifyMessage API with
OpenSSL 3.4 the providers that support combined digest and sign algorithms
register quite a lot more signature algorithms, so the current limit of
111 is hit easily.
While at it correct the definitions of the signature fields within the
loopargs_t structure to use MAX_SIG_NUM instead of MAX_KEM_NUM.
Closes: https://github.com/openssl/openssl/issues/27873
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27878)
After commit b911fef216 speed with shake128 or
shake256 does not run anymore:
# openssl speed -seconds 1 -evp shake128 -bytes 256
Doing shake128 ops for 1s on 256 size blocks: shake128 error!
000003FF9B7F2080:error:1C8000A6:Provider routines:keccak_final:invalid digest
length:providers/implementations/digests/sha3_prov.c:117:
version: 3.4.0-dev
...
type 256 bytes
shake128 0.00
Function EVP_Digest_loop() must use EVP_DigestInit_ex2(), EVP_DigestUpdate(),
and EVP_DigestFinalXOF() in case of shake instead of just EVP_Digest() to get
around this.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24462)
When using CCM, openssl speed uses the loop function EVP_Update_loop_ccm() which
sets a (fake) tag when decrypting. When using -aead (which benchmarks a different
sequence than normal, to be comparable to TLS operation), the loop function
EVP_Update_loop_aead() is used, which also sets a tag when decrypting.
However, when using defaults, the loop function EVP_Update_loop() is used, which
does not set a tag on decryption, leading to "Error finalizing cipher loop".
To fix this, set a fake tag value if we're doing decryption on an AEAD cipher in
EVP_Update_loop(). We don't check the return value: this shouldn't really be able
to fail, and if it does, the following EVP_DecryptUpdate() is almost certain to
fail, so that can catch it.
The decryption is certain to fail (well, almost certain, but with a very low
probability of success), but this is no worse than at present. This minimal
change means that future benchmarking data should be comparable to previous
benchmarking data.
(This is benchmarking code: don't write real apps like this!)
Fixes#23657
Change-Id: Id581cf30503c1eb766464e315b1f33914040dcf7
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23757)
Add ability to measure performance of the two kmac algorithms, and
reduce code duplication in mac testing by introducing mac_setup() and
mac_teardown(). Also, start accepting "cmac" as an algorithm string
(similar to how "hmac" is accepted).
We can now compare the performance of KMAC128, KMAC256 (mac algs) to
KECCAK-KMAC128, KECCAK-KMAC256 (digest/xof algs).
Fixes#22619
Testing:
$ LD_LIBRARY_PATH=. ./apps/openssl speed kmac cmac hmac
$ LD_LIBRARY_PATH=. ./apps/openssl speed kmac256
$ LD_LIBRARY_PATH=. ./apps/openssl speed -evp KECCAK-KMAC256
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22764)
prefer hmac(sha256) rather than hmac(md5). Also, drop the "skip_hmac"
label. If we are supposed to do hmac(hash_func) and hash_func cannot
be found, then error out immediately.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22793)
Setup the loopargs array for all jobs, not only for the very first one.
It may fail with "Could not allocate 0 bytes for sig sign loop" and/or will
cause the loop functions to fail silently, because they operate on a NULL
PKEY context when "-async_jobs <n>" is specified.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/22399)
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)
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)
