Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Lan

Copyright year updates

Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes
(cherry picked from commit 0ce7d1f355c1240653e320a3f6f8109c1f05f8c0)

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24034)

show more ...

riscv: Fix remaining asm checks

There are additional asm checks which don't check for OPENSSL_CPUID_OBJ
causing the build to still fail on riscv [1], so fix them in the same
manner a

riscv: Fix remaining asm checks

There are additional asm checks which don't check for OPENSSL_CPUID_OBJ
causing the build to still fail on riscv [1], so fix them in the same
manner as ff279597692f9f19dca5b147944d3d96f2e109f8

[1] https://bugs.gentoo.org/923956
Fixes: https://github.com/openssl/openssl/issues/22871

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23752)

(cherry picked from commit daf1f8d64fff4a395ee7cf032484dc022a27e748)

show more ...

riscv: Fix mispelling of extension test macro

When refactoring the riscv extension test macros,
RISCV_HAS_ZKND_AND_ZKNE was mispelled.

CLA: trivial

Reviewed-by: Todd Sh

riscv: Fix mispelling of extension test macro

When refactoring the riscv extension test macros,
RISCV_HAS_ZKND_AND_ZKNE was mispelled.

CLA: trivial

Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23139)

show more ...

riscv: Provide vector crypto implementation of AES-128/256-XTS mode.

To accelerate the performance of the AES-XTS mode, in this patch, we
have the specialized multi-block implementation

riscv: Provide vector crypto implementation of AES-128/256-XTS mode.

To accelerate the performance of the AES-XTS mode, in this patch, we
have the specialized multi-block implementation for AES-128-XTS and
AES-256-XTS.

Signed-off-by: Jerry Shih <jerry.shih@sifive.com>
Signed-off-by: Phoebe Chen <phoebe.chen@sifive.com>

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/21923)

show more ...

Fix the aes-xts key-length checking condition and hw declaration.

The argument `key-length` includes 2 sets of keys.

All declarations should under `PROV_CIPHER_HW_declare_xts()` mac

Fix the aes-xts key-length checking condition and hw declaration.

The argument `key-length` includes 2 sets of keys.

All declarations should under `PROV_CIPHER_HW_declare_xts()` macro.

Signed-off-by: Jerry Shih <jerry.shih@sifive.com>

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/21923)

show more ...

riscv: Implement AES-192

Even though the RISC-V vector instructions only support AES-128 and
AES-256 for key generation, the round instructions themselves can
easily be used to imple

riscv: Implement AES-192

Even though the RISC-V vector instructions only support AES-128 and
AES-256 for key generation, the round instructions themselves can
easily be used to implement AES-192 too - we just need to fallback to
the generic key generation routines in this case.

Note that the vector instructions use the encryption key schedule (but
in reverse order) so we need to generate the encryption key schedule
even when doing decryption using the vector instructions.

Signed-off-by: Ard Biesheuvel <ardb@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

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/21923)

show more ...

riscv: AES: Provide a Zvkned-based implementation

The upcoming RISC-V vector crypto extensions provide
the Zvkned extension, that provides a AES-specific instructions.
This patch pro

riscv: AES: Provide a Zvkned-based implementation

The upcoming RISC-V vector crypto extensions provide
the Zvkned extension, that provides a AES-specific instructions.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

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/21923)

show more ...

Copyright year updates


Reviewed-by: Richard Levitte <levitte@openssl.org>
Release: yes

riscv: Clean up extension test macros

In RISC-V we have multiple extensions, that can be
used to accelerate processing.
The known extensions are defined in riscv_arch.def.
From t

riscv: Clean up extension test macros

In RISC-V we have multiple extensions, that can be
used to accelerate processing.
The known extensions are defined in riscv_arch.def.
From that file test functions of the following
form are generated: RISCV_HAS_$ext().

In recent commits new ways to define the availability
of these test macros have been defined. E.g.:
#define RV32I_ZKND_ZKNE_CAPABLE \
(RISCV_HAS_ZKND() && RISCV_HAS_ZKNE())
[...]
#define RV64I_ZKND_ZKNE_CAPABLE \
(RISCV_HAS_ZKND() && RISCV_HAS_ZKNE())

This leaves us with two different APIs to test capabilities.
Further, creating the same macros for RV32 and RV64 results
in duplicated code (see example above).

This inconsistent situation makes it hard to integrate
further code. So let's clean this up with the following steps:
* Replace RV32I_* and RV64I_* macros by RICSV_HAS_* macros
* Move all test macros into riscv_arch.h
* Use "AND" and "OR" to combine tests with more than one extension
* Rename include files for accelerated processing (remove extension
postfix).

We end up with compile time tests for RV32/RV64 and run-time tests
for available extensions. Adding new routines (e.g. for vector crypto
instructions) should be straightforward.

Testing showed no regressions.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20078)

show more ...

provider: cipher: aes: add riscv32 zkn (zbkb) support

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/o

provider: cipher: aes: add riscv32 zkn (zbkb) support

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18308)

show more ...

providers: cipher: aes: add riscv64 zkn support

Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
Tested-by: Jiatai He <jiatai2021@iscas.ac.cn>

Reviewed-by: Paul Dale <pau

providers: cipher: aes: add riscv64 zkn support

Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me>
Tested-by: Jiatai He <jiatai2021@iscas.ac.cn>

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18197)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15801)

aes: rename new bsaes_ symbols -> ossl_bsaes_ ones

bsaes_cbc_encrypt -> ossl_bsaes_cbc_encrypt
bsaes_ctr32_encrypt_blocks -> ossl_bsaes_ctr32_encrypt_blocks
bsaes_xts_decrypt -> ossl

aes: rename new bsaes_ symbols -> ossl_bsaes_ ones

bsaes_cbc_encrypt -> ossl_bsaes_cbc_encrypt
bsaes_ctr32_encrypt_blocks -> ossl_bsaes_ctr32_encrypt_blocks
bsaes_xts_decrypt -> ossl_bsaes_xts_decrypt
bsaes_xts_encrypt -> ossl_bsaes_xts_encrypt

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/15445)

show more ...

Fix Aes-xts potential failure on aarch64

Add return value for aarch64 in the init key function.
This will avoid overwriting the stream pointers of aarch64.

Reviewed-by: Shane Lo

Fix Aes-xts potential failure on aarch64

Add return value for aarch64 in the init key function.
This will avoid overwriting the stream pointers of aarch64.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13133)

show more ...

prov: prefix provider internal functions with ossl_

Also convert the names to lower case.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/open

prov: prefix provider internal functions with ossl_

Also convert the names to lower case.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13014)

show more ...

Fix AES_XTS on x86-64 platforms with BSAES and VPAES support.

Fixes #11622
Fixes #12378

Due to a missing else it was setting up the stream for BSAES and then using this incorrec

Fix AES_XTS on x86-64 platforms with BSAES and VPAES support.

Fixes #11622
Fixes #12378

Due to a missing else it was setting up the stream for BSAES and then using this incorrect stream with VPAES.
The correct behaviour is not to use VPAES at all in this case.
Also note that the original code in e_aes could set up VPAES and then would overwrite it with the generic implementation.
On a machine that supported both BSAES and VPAES the code was changed locally to force it to run both cases to verify
both paths produce the correct known answers.

Debugged using mageia 7.1, but is also highly likely to fix FreeBSD also.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12887)

show more ...

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11616)

Deprecate the low level AES functions

Use of the low level AES functions has been informally discouraged for a
long time. We now formally deprecate them.

Applications should ins

Deprecate the low level AES functions

Use of the low level AES functions has been informally discouraged for a
long time. We now formally deprecate them.

Applications should instead use the EVP APIs, e.g. EVP_EncryptInit_ex,
EVP_EncryptUpdate, EVP_EncryptFinal_ex, and the equivalently named decrypt
functions.

Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10580)

show more ...

Fix Use after free when copying cipher ctx

Fixes #10438
issue found by clusterfuzz/ossfuzz

The dest was getting a copy of the src structure which contained a pointer that should

Fix Use after free when copying cipher ctx

Fixes #10438
issue found by clusterfuzz/ossfuzz

The dest was getting a copy of the src structure which contained a pointer that should point to an offset inside itself - because of the copy it was pointing to the original structure.

The setup for a ctx is mainly done by the initkey method in the PROV_CIPHER_HW structure. Because of this it makes sense that the structure should also contain a copyctx method that is use to resolve any pointers that need to be setup.

A dup_ctx has been added to the cipher_enc tests in evp_test. It does a dup after setup and then frees the original ctx. This detects any floating pointers in the duplicated context that were pointing back to the freed ctx.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10443)

show more ...

Providers: move all ciphers

From providers/{common,default}/ to providers/implementations/

Except for common code, which remains in providers/common/ciphers/.
However, we do mov

Providers: move all ciphers

From providers/{common,default}/ to providers/implementations/

Except for common code, which remains in providers/common/ciphers/.
However, we do move providers/common/include/internal/ciphers/*.h
to providers/common/include/prov/, and adjust all source including
any of those header files.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10088)

show more ...