#
496bc128 |
| 29-Mar-2024 |
Matt Caswell |
Copyright year updates Reviewed-by: Neil Horman <nhorman@openssl.org> Release: yes (cherry picked from commit 3764f200f9d44622faa8ac1b15d2f3eb7c39e473) Reviewed-by: Hugo Lan
Copyright year updates Reviewed-by: Neil Horman <nhorman@openssl.org> Release: yes (cherry picked from commit 3764f200f9d44622faa8ac1b15d2f3eb7c39e473) 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 ...
|
#
347f05e8 |
| 05-Mar-2024 |
Jakov Smolić |
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 ...
|
#
94474e02 |
| 24-Jul-2023 |
Ard Biesheuvel |
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 ...
|
#
f6631e38 |
| 26-Jan-2023 |
Christoph Müllner |
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 ...
|
#
da1c088f |
| 07-Sep-2023 |
Matt Caswell |
Copyright year updates Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
|
#
86c69fe8 |
| 17-Jan-2023 |
Christoph Müllner |
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 ...
|
#
5ccee69b |
| 13-May-2022 |
Hongren (Zenithal) Zheng |
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 ...
|
#
ee11118d |
| 30-Apr-2022 |
Hongren (Zenithal) Zheng |
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 ...
|
Revision tags: openssl-3.0.0-alpha17, openssl-3.0.0-alpha16, openssl-3.0.0-alpha15, openssl-3.0.0-alpha14, OpenSSL_1_1_1k, openssl-3.0.0-alpha13, openssl-3.0.0-alpha12, OpenSSL_1_1_1j, openssl-3.0.0-alpha11, openssl-3.0.0-alpha10, OpenSSL_1_1_1i, openssl-3.0.0-alpha9, openssl-3.0.0-alpha8, openssl-3.0.0-alpha7 |
|
#
7d6766cb |
| 28-Sep-2020 |
Pauli |
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 ...
|
Revision tags: OpenSSL_1_1_1h, openssl-3.0.0-alpha6 |
|
#
90409da6 |
| 22-Jul-2020 |
Shane Lontis |
Fix provider cipher reinit issue Fixes #12405 Fixes #12377 Calling Init()/Update() and then Init()/Update() again gave a different result when using the same key and iv. Cip
Fix provider cipher reinit issue Fixes #12405 Fixes #12377 Calling Init()/Update() and then Init()/Update() again gave a different result when using the same key and iv. Cipher modes that were using ctx->num were not resetting this value, this includes OFB, CFB & CTR. The fix is to reset this value during the ciphers einit() and dinit() methods. Most ciphers go thru a generic method so one line fixes most cases. Add test for calling EVP_EncryptInit()/EVP_EncryptUpdate() multiple times for all ciphers. Ciphers should return the same value for both updates. DES3-WRAP does not since it uses a random in the update. CCM modes currently also fail on the second update (This also happens in 1_1_1). Fix memory leak in AES_OCB cipher if EVP_EncryptInit is called multiple times. Fix AES_SIV cipher dup_ctx and init. Calling EVP_CIPHER_init multiple times resulted in a memory leak in the siv. Fixing this leak also showed that the dup ctx was not working for siv mode. Note: aes_siv_cleanup() can not be used by aes_siv_dupctx() as it clears data that is required for the decrypt (e.g the tag). Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12413)
show more ...
|
Revision tags: openssl-3.0.0-alpha5, openssl-3.0.0-alpha4, openssl-3.0.0-alpha3, openssl-3.0.0-alpha2, openssl-3.0.0-alpha1 |
|
#
33388b44 |
| 23-Apr-2020 |
Matt Caswell |
Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
|
Revision tags: OpenSSL_1_1_1g, OpenSSL_1_1_1f, OpenSSL_1_1_1e, OpenSSL_1_0_2u |
|
#
c72fa255 |
| 05-Dec-2019 |
Matt Caswell |
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 ...
|
#
604e884b |
| 04-Oct-2019 |
Richard Levitte |
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 ...
|