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)
This is defined in NIST SP 800-208 as the truncation to 192 bits of
SHA256. Unlike other truncated hashes in the SHA2 suite, this variant
doesn't have a different initial state, it is just a pure truncation
of the output.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21180)
Signed-off-by: Čestmír Kalina <ckalina@redhat.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12256)
The keccak XOF used for KMAC can be simplified by using klmd. This speeds up
XOF processing in cases where more than one result block is needed.
Signed-off-by: Juergen Christ <jchrist@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/20431)
CPACF does not directly support xofs. Emulate this by using single block
operations on an empty input block.
Fixes: affc070aab ("s390x: Optimize kmac")
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19983)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19375)
Including RIPEMD160 in both the default and legacy providers shouldn't break
anyone and makes the algorithm available more readily.
Fixes#17722
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19375)
Use hardware acceleration for kmac on s390x. Since klmd does not support
kmac, perform padding of the last block by hand and use kimd. Yields a
performance improvement of between 2x and 3x.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18863)
s390x does not directly support keccak via CPACF since these instructions
hard-code the padding to either SHA-3 or SHAKE for the "compute last message
digest" function. This caused test errors on Keccak digests. Fix it by using
"compute intermediate message digest" and manually computing the padding for
Keccak.
Fixes: a8b238f0e4 ("Fix SHA, SHAKE, and KECCAK ASM flag passing")
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18794)
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18220)
libimplementations.a was a nice idea, but had a few flaws:
1. The idea to have common code in libimplementations.a and FIPS
sensitive helper functions in libfips.a / libnonfips.a didn't
catch on, and we saw full implementation ending up in them instead
and not appearing in libimplementations.a at all.
2. Because more or less ALL algorithm implementations were included
in libimplementations.a (the idea being that the appropriate
objects from it would be selected automatically by the linker when
building the shared libraries), it's very hard to find only the
implementation source that should go into the FIPS module, with
the result that the FIPS checksum mechanism include source files
that it shouldn't
To mitigate, we drop libimplementations.a, but retain the idea of
collecting implementations in static libraries. With that, we not
have:
libfips.a
Includes all implementations that should become part of the FIPS
provider.
liblegacy.a
Includes all implementations that should become part of the legacy
provider.
libdefault.a
Includes all implementations that should become part of the
default and base providers.
With this, libnonfips.a becomes irrelevant and is dropped.
libcommon.a is retained to include common provider code that can be
used uniformly by all providers.
Fixes#15157
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15171)
Partial fix for #12964
This adds ossl_ names for the following symbols:
blake2b512_init,blake2b_final,blake2b_init,blake2b_init_key,
blake2b_param_init,blake2b_param_set_digest_length,blake2b_param_set_key_length,
blake2b_param_set_personal,blake2b_param_set_salt,blake2b_update,
blake2s256_init,blake2s_final,blake2s_init,blake2s_init_key,
blake2s_param_init,blake2s_param_set_digest_length,blake2s_param_set_key_length,
blake2s_param_set_personal,blake2s_param_set_salt,blake2s_update,
digest_default_get_params,digest_default_gettable_params
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14211)
The PROV_R codes can be returned to applications so it is useful
to have some common set of provider reason codes for the applications
or third party providers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14086)
These are: keccak_kmac_init(), sha3_final(), sha3_init(), sha3_reset() and
sha3_update().
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13417)
This stops them leaking into other namespaces in a static build.
They remain internal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13013)
This moves test/ossl_test_endian.h to include/internal/endian.h and
thereby makes the macros in there our standard way to check endianness
in run-time.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/12390)
The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all
functions which are dispatched between the core and providers.
This change includes in particular all up- and downcalls, i.e., the
dispatched functions passed from core to provider and vice versa.
- OSSL_core_ -> OSSL_FUNC_core_
- OSSL_provider_ -> OSSL_FUNC_core_
For operations and their function dispatch tables, the following convention
is used:
Type | Name (evp_generic_fetch(3)) |
---------------------|-----------------------------------|
operation | OSSL_OP_FOO |
function id | OSSL_FUNC_FOO_FUNCTION_NAME |
function "name" | OSSL_FUNC_foo_function_name |
function typedef | OSSL_FUNC_foo_function_name_fn |
function ptr getter | OSSL_FUNC_foo_function_name |
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12222)
The provider- manuals are meant to describe the general interface for
their respective operation. This is not the place to describe
implementation specific details.
This change creates a number of doc/man7/EVP_MD manuals, one for each
algorithm or set of algorithms, as well as doc/man7/EVP_MD-common.pod
to describe what's common to them all.
While we're at it, correct the SHA3 settable context params array to
match what's actually settable.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11270)
Use of the low level MD5 functions has been informally discouraged for a long
time. We now formally deprecate them.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10791)
Use of the low level Whirlpool functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10779)
Use of the low level RIPEMD160 functions has been informally discouraged for a
long time. We now formally deprecate them.
Applications should instead use the EVP APIs, e.g. EVP_Digest,
EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10789)
The idea to have all these things in providers/common was viable as
long as the implementations was spread around their main providers.
This is, however, no longer the case, so we move the common blocks
closer to the source that use them.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10564)
sdlyyxy
Fergus Dall
Čestmír Kalina
Juergen Christ
Tomas Mraz
Pauli
JHH20
Matt Caswell
Ulrich Müller
Richard Levitte
Shane Lontis
Pauli
Pauli
Richard Levitte
Dr. Matthias St. Pierre