Reviewed-by: NHugo Landau <hlandau@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22525)

Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22459)

Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22459)

Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22459)

To enhance test coverage for AES-ECB mode, we provided longer additional
testing patterns for AES-128/192/256-ECB.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

This patch provides stream and multi-block implementations for
AES-128-ECB, AES-192-ECB, and AES-256-ECB to accelerate AES-ECB.
Also, refactor functions to share the same variable
declaration in aes-riscv64-zvkned.pl.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

This patch updates the OSSSL_HWSM3_block_data_order_zvksh and enables
SM3 on platforms with VLEN >= 128.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

To enhance test coverage for AES-XTS mode, we provided longer additional
testing patterns from BoringSSL for AES-XTS testing.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

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: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

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

All declarations should under `PROV_CIPHER_HW_declare_xts()` macro.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

To enhance test coverage for AES-GCM mode, we provided longer additional
testing patterns for AES-GCM testing.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

To accelerate the performance of the AES-GCM mode, in this patch, we
have the specialized multi-block implementations for AES-128-GCM,
AES-192-GCM and AES-256-GCM.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Unify the return value for `CRYPTO_gcm128_decrypt` as `CRYPTO_gcm128_encrypt`.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Support zvbb-zvkned based rvv AES-128/192/256-CTR encryption.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

This patch supports SHA-512, SHA-512/224, SHA-512/256 on platforms with
vlen greater than 128,
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Keep SHA-256 constant values in registers to save the loading time.

Move the constant loading for sha256 into a separate subroutine.
By creating a dedicated sub routine for loading sha256 constants, the
code can be made more modular and easier to modify in the future.

Relaxing the SHA256 constraint, zvknhb also supports SHA256.

Simplify the H and mask initialization flows.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Use rvv and zvbb extensions for CHACHA20 cipher.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

To enhance test coverage for AES-CBC mode, we provided longer additional
test patterns for AES-CBC testing.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Replace old CBC implementation with optimized AES-128/192/256-CBC in
this patch.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

To accelerate the performance of the AES-128/192/256-CBC block cipher
encryption, we used the vaesz, vaesem and vaesef instructions, which
implement a single round of AES encryption.

Similarly, to optimize the performance of AES-128/192/256-CBC block
cipher decryption, we have utilized the vaesz, vaesdm, and vaesdf
instructions, which facilitate a single round of AES decryption.

Furthermore, we optimize the key and initialization vector (IV) step by
keeping the rounding key in vector registers.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

https://github.com/riscv/riscv-crypto/blob/c8ddeb7e64a3444dda0438316af1238aeed72041/doc/vector/riscv-crypto-vector-zvkb.adoc
Create `RISCV_HAS_ZVKB()` macro.
Use zvkb for SM4 instead of zvbb.
Use zvkb for ghash instead of zvbb.
We could just use the zvbb's subset `zvkb` for flexibility.
Signed-off-by: NJerry Shih <jerry.shih@sifive.com>
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Interleave key loading and aes decrypt computing for single block aes.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Interleave key loading and aes encrypt computing for single block aes.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Added helper functions and opcode encoding functions
in riscv.pm perl module to avoid pointless code duplication.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Changed "mutiple" to "multiple" for improved clarity and correctness.
Signed-off-by: NPhoebe Chen <phoebe.chen@sifive.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

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: NArd Biesheuvel <ardb@google.com>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The upcoming RISC-V vector crypto extensions feature
a Zvksh extension, that provides SM3-specific istructions.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NCharalampos Mitrodimas <charalampos.mitrodimas@vrull.eu>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The upcoming RISC-V vector crypto extensions feature
a Zvksed extension, that provides SM4-specific instructions.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The upcoming RISC-V vector crypto extensions feature
a Zvknhb extension, that provides sha512-specific istructions.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NCharalampos Mitrodimas <charalampos.mitrodimas@vrull.eu>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Currently, architectures have to decide if they want the C code or an
arch-specific implementation. Let's add a macro, that allows to keep the C
code even if SHA512_ASM is defined (but rename it from sha512_block_data_order
to sha512_block_data_order_c). The macro INCLUDE_C_SHA512 can be used by
architectures, that want the C code as fallback code.
Signed-off-by: NCharalampos Mitrodimas <charalampos.mitrodimas@vrull.eu>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The upcoming RISC-V vector crypto extensions feature
a Zvknha extension, that provides sha256-specific instructions.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NCharalampos Mitrodimas <charalampos.mitrodimas@vrull.eu>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Currently, architectures have to decide if they want the C code or an
arch-specific implementation. Let's add a macro, that allows to keep the C
code even if SHA256_ASM is defined (but rename it from sha256_block_data_order
to sha256_block_data_order_c). The macro INCLUDE_C_SHA256 can be used by
architectures, that want the C code as fallback code.
Signed-off-by: NCharalampos Mitrodimas <charalampos.mitrodimas@vrull.eu>
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

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: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The upcoming RISC-V vector crypto extensions feature
a Zvkg extension, that provides a vghmac.vv instruction.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The RISC-V vector crypto extensions features a Zvbc extension
that provides a carryless multiplication ('vclmul.vv') instruction.
This patch provides an implementation that utilizes this
extension if available.

Tested on QEMU and no regressions observed.
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

The RISC-V vector extension comes with an implementation-defined
number of bits per vector register (VLEN), which can be read out at
run-time using the CSR 'vlenb' (which returns VLEN/8) followed by a
multiplication by 8 (to convert bytes to bits).

This patch introduces a RISC-V capability 'V' to specify the
availability of the vector extension. If this extension is found at
run-time, then we read out VLEN as described above and cache it.
Caching ensures that we only read the CSR once at startup.
This is necessary because reading out CSR can be expensive
(e.g. if CSR readout is implemented using trap-and-emulate).

Follow-up patches can make use of VLEN and chose the best strategy
based on the available length of the vector registers.
Signed-off-by: NChristoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21923)

Calling X509_NAME_print_ex with XN_FLAG_COMPAT falls back to calling
X509_NAME_print().  The obase parameter to X509_NAME_print() is not
used, so setting it to a different value has no effect.
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NTodd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/19963)

Similar to the bug fixed in 02db7354 (Fix bug in X509_print_ex).
The error return value from X509_NAME_print_ex() is different
depending on whether the flags are XN_FLAG_COMPAT or not.
Apply a similar fix to what was done for X509_print_ex here as well.
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NTodd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/19963)

The X509_FLAG_COMPAT constant is defined as a value of the
X509_print_ex() cflags argument, and so it should not be used
to compare against values for use with X509_NAME_print flags.
Use XN_FLAG_COMPAT, which has the same value, instead.
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NTodd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/19963)

While RFC 5705 implies that the maximum length of context for
exporters to be 65535 bytes as the length is embedded in uint16, the
current implementation enforces much smaller limit, which is less than
1024 bytes.  This removes the restriction by dynamically allocating
memory.
Signed-off-by: NDaiki Ueno <dueno@redhat.com>
Reviewed-by: NTodd Short <todd.short@me.com>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22465)