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)
Fixes#11622Fixes#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)
The functions that check for the provider being runnable are: new, init, final
and dupctx.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12801)
TLS1.0 does not have an explicit IV in the record, and therefore we should
not attempt to remove it.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12670)
The S390x hardware-accelerated cipher implementations keep their IV
state in an internal structure tied to the underlying implementation.
However, the provider itself needs to be able to expose the IV state
to libcrypto when processing the "iv-state" parameter. In the absence
of a S390x hardware-specific get_ctx_params() implementation, be sure
to copy the IV state from the hw-specific structure back to the
generic PROV_CIPHER_CTX object after each cipher operation in order to
synchronize the internal and fetchable state.
[extended tests]
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
The current check for iv_gen and iv_gen_rand only lets you fetch
the IV for the case when it was set internally. It might also make
sense to fetch the IV if one was set at cipher-context creation time,
so switch to checking the iv_state, which should be enough to ensure
that there is valid data in the context to be copied out.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
Some modes (e.g., CBC and OFB) update the effective IV with each
block-cipher invocation, making the "IV" stored in the (historically)
EVP_CIPHER_CTX or (current) PROV_CIPHER_CTX distinct from the initial
IV passed in at cipher initialization time. The latter is stored in
the "oiv" (original IV) field, and has historically been accessible
via the EVP_CIPHER_CTX_original_iv() API. The "effective IV" has
also historically been accessible, via both EVP_CIPHER_CTX_iv()
and EVP_CIPHER_CTX_iv_noconst(), the latter of which allows for
*write* access to the internal cipher state. This is particularly
problematic given that provider-internal cipher state need not, in
general, even be accessible from the same address space as libcrypto,
so these APIs are not sustainable in the long term. However, it still
remains necessary to provide access to the contents of the "IV state"
(e.g., when serializing cipher state for in-kernel TLS); a subsequent
reinitialization of a cipher context using the "IV state" as the
input IV will be able to resume processing of data in a compatible
manner.
This problem was introduced in commit
089cb623be, which effectively caused
all IV queries to return the "original IV", removing access to the
current IV state of the cipher.
These functions for accessing the (even the "original") IV had remained
undocumented for quite some time, presumably due to unease about
exposing the internals of the cipher state in such a manner.
Note that this also as a side effect "fixes" some "bugs" where things
had been referring to the 'iv' field that should have been using the
'oiv' field. It also fixes the EVP_CTRL_GET_IV cipher control,
which was clearly intended to expose the non-original IV, for
use exporting the cipher state into the kernel for kTLS.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12233)
The test added previously used a 16 byte block during the update which does not cause internal buffering in the provider.
Some internal variables related to the buffering were not being cleared in the init, which meant that the second
update would use the buffered data from the first update.
Added test for this scenario with exclusions for ciphers that do not support partial block updates.
Found by guidovranken.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12523)
Fixes#12405Fixes#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)
Added Algorithm names AES-128-CBC-CTS, AES-192-CBC-CTS and AES-256-CBC-CTS.
CS1, CS2 and CS3 variants are supported.
Only single shot updates are supported.
The cipher returns the mode EVP_CIPH_CBC_MODE (Internally it shares the aes_cbc cipher code). This
would allow existing code that uses AES_CBC to switch to the CTS variant without breaking code that
tests for this mode. Because it shares the aes_cbc code the cts128.c functions could not be used directly.
The cipher returns the flag EVP_CIPH_FLAG_CTS.
EVP_CIPH_FLAG_FIPS & EVP_CIPH_FLAG_NON_FIPS_ALLOW have been deprecated.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12094)
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)
EVP_CipherUpdate is supposed to return 1 for success or 0 for error.
However for GCM ciphers it was sometimes returning -1 for error.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
Other ciphers return the length of the Payload for TLS as a result of an
EVP_DecryptUpdate() operation - but ChaCha20-Poly1305 did not. We change
it so that it does.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
The previous commits separated out the TLS CBC padding code in libssl.
Now we can use that code to directly support TLS CBC padding and MAC
removal in provided ciphers.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12288)
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)
When we're fetching an IV, there's no need to enforce that the
provided buffer is exactly the same size as the IV we want to
write into it. This might happen, for example, when
EVP_CIPHER_CTX_iv_noconst() passes sizeof(ctx->iv) (that is,
EVP_MAX_IV_LENGTH) for an AES-GCM cipher that uses a shorter IV.
AES-OCB and CCM were also affected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12039)
OSSL_CIPHER_PARAM_IV can be accessed both as an octet string and as
an octet pointer (for routines like EVP_CIPHER_CTX_iv() that are
in a nebulous undocumented-and-might-go-away-eventually state),
the latter for when there is need to modify the actual value in
the provider.
Make sure that we consistently try to set it as both the string and pointer
forms (not just octet string) and only fail if neither version succeeds. The
generic cipher get_ctx_params routine was already doing so, but the
AES-variant-, GCM-, and CCM-specific ones were not.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12039)
Fixes#11459
It was incorrectly using 8 bytes instead of 16 as the default.
This was verified by expanding the macros used in e_cast.c.
The issue occurs if EVP_CIPHER_CTX_set_key_length() is not called.
evp_test.c hides this issue as it always calls EVP_CIPHER_CTX_set_key_length() before
using EVP_CipherInit_ex(...., key, ..).
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11707)
The legacy provider contains assembler references. Most code is automagically pulled in from the libcrypto - but the platform specific assembler functions will not be visible in the symbol table. Copying BNASM and DESASM into liblegacy seems to be a better solution than exposing platform specific function in libcrypto.num.
Added a missing call in the des_cbc code for sparc.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11697)
This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.
Fixes#11538
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11539)
The cipher_tdes_common causes build failure as being duplicated
in libcrypto static builds.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11544)
DES implementations were missing the dup/copy ctx routines
required by CMAC implementation. A regression test is added.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11498)
DES, idea, seed, rc2, rc4, rc5, cast and blowfish have been moved out of the default provider.
Code shared between desx and tdes has been moved into a seperate file (cipher_tdes_common.c).
3 test recipes failed due to using app/openssl calls that used legacy ciphers.
These calls have been updated to supply both the default and legacy providers.
Fixed openssl app '-provider' memory leak
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11419)
In function 'ccm_tls_cipher',
inlined from 'ccm_cipher_internal' at providers/common/ciphers/cipher_ccm.c:359:16,
inlined from 'ccm_stream_final' at providers/common/ciphers/cipher_ccm.c:265:9:
providers/common/ciphers/cipher_ccm.c:317:5: error: argument 2 null where non-null expected [-Werror=nonnull]
317 | memcpy(ctx->iv + EVP_CCM_TLS_FIXED_IV_LEN, in, EVP_CCM_TLS_EXPLICIT_IV_LEN);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/internal/cryptlib.h:14,
from providers/common/include/prov/ciphercommon.h:14,
from providers/common/ciphers/cipher_ccm.c:12:
providers/common/ciphers/cipher_ccm.c: In function 'ccm_stream_final':
/home/ed/gnu/arm-linux-gnueabihf-linux64/arm-linux-gnueabihf/sys-include/string.h:44:14: note: in a call to function 'memcpy' declared here
44 | extern void *memcpy (void *__restrict __dest,
| ^~~~~~
[extended tests]
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10344)
Avoid function calls we don't need to do.
In 1.1.1 we have:
aes-128-cbc 572267.80k 681197.08k 715430.74k 720508.59k 722359.64k 723004.07k
Current master:
aes-128-cbc 460663.70k 631125.66k 701283.58k 719794.52k 724732.59k 726668.63k
new:
aes-128-cbc 582057.64k 684288.62k 715721.90k 724856.15k 717578.24k 727176.53k
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11102)
Compile failures were occuring on systems that weren't AESNI capable
because the detection wasn't quite right in a couple of files.
This fixes a run-checker build failure for the 386 compile option.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11022)
Minor fixes to resolve compilation errors with the no-multiblock
Configure option.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11004)
Use of the low level DES 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/10858)
Libssl uses the null cipher in certain situations. It should be
converted to a provided cipher.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10865)
These were initially added as internal functions only. However they will
also need to be used by libssl as well. Therefore it make sense to move
them into the public API.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10864)
Use of the low level IDEA 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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10819)
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 RC5 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/10834)
Use of the low level RC4 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/10834)
