Try to make these definitions clearer given the complexity of the
mapping between the PSA config options and the MBEDTLS ones.
Signed-off-by: David Brown <david.brown@linaro.org>
If any of the software block ciphers are selected, define an internal
macro to indicate this. This eliminates some redundancy that needs to
check for this.
Signed-off-by: David Brown <david.brown@linaro.org>
Add checks for PSA_WANT_KEY_TYPE_CHACHA20, both with and without
MBEDTLS_PSA_CRYPTO_CONFIG. This only adds support for the ciphers
itself, presumably as a stream cipher (and not yet AEAD).
Signed-off-by: David Brown <david.brown@linaro.org>
Even if there is an accelerated version of a (block) key type, enable
the SW implementation if there are block modes that don't have
acceleration.
Signed-off-by: David Brown <david.brown@linaro.org>
Add additional ifdef checks in the PSA config to detect when an
algorithm is entirely implemented in hardware. If there is any
combination of cipher and padding type that is not supported by the HW
acceleration, enable the SW acceleration.
Signed-off-by: David Brown <david.brown@linaro.org>
Ensure that the builtin definitions are defined when selected by the
traditional configuration options.
Signed-off-by: David Brown <david.brown@linaro.org>
For the new features conditionalized on MBEDTLS_PSA_ACCEL_..., define a
correlated MBEDTLS_PSA_BUILTIN_... if it is not defined. This prevents
check_names from considering these new defines as typos.
Signed-off-by: David Brown <david.brown@linaro.org>
Add support for supported block modes using the PSA crypto config.
These are mapped to Mbed TLS config options as best as possible.
Signed-off-by: David Brown <david.brown@linaro.org>
There was some intentional duplication between
library/psa_crypto_random_impl.h and include/mbedtls/psa_util.h, with
the intent that the compiler would complain if one file was edited in
a way that's incompatible with the other file. However, the two files
were never included together, and in fact could not be included
together because some definitions can't be duplicated (type, static
variable).
Now library/psa_crypto_random_impl.h includes
include/mbedtls/psa_util.h, so the compiler will check what it can.
There is less redundancy since it isn't always possible to declare
something twice (specifically, types can't be declared).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This brings them in line with PSA Crypto API 1.0.0
PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH -> PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG
PSA_ALG_AEAD_WITH_TAG_LENGTH -> PSA_ALG_AEAD_WITH_SHORTENED_TAG
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
- Fixed code style.
- Clarified the documentation of what happens when saltlen is set to
MBEDTLS_RSA_SALT_LEN_ANY.
- Added range check on saltlen to reject out of range values.
(Code review done by @gilles-peskine-arm)
Signed-off-by: Cédric Meuter <cedric.meuter@gmail.com>
extension of mbedtls_rsa_rsassa_pss_sign() with an extra argument
'saltlen' which allows to inject the length of the salt to the function,
as opposed to the original function which internally computes the
maximum possible salt length. If MBEDTLS_RSA_SALT_LEN_ANY is passed
the function falls back to the the original behaviour. The original
function mbedtls_rsa_rsassa_pss_sign() can simply defer to it.
This allows to make some CAVP PSS generation tests that require the use
of a salt length which is smaller that the hash length.
Signed-off-by: Cédric Meuter <cedric.meuter@gmail.com>
Executed ./scripts/bump_version.sh --version 2.25.0 --so-crypto 6
Increasing the SO version of the crypto library, because the openless
API improvement came with API/ABI incompatibilities. For example
- the size of psa_key_handle_t changed
- the type of a parameter in 18 public functions has changed from
psa_key_handle_t to mbedtls_svc_key_id_t
Signed-off-by: Janos Follath <janos.follath@arm.com>
This temporarily breaks all.sh '*deprecated*' (deprecated functions still used
in the library), which will be fix in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Work in progress: next steps are to implement and test it.
Compared to the existing non-ext version:
- to separate tag parameter
- explicit output_len parameter
Also, this version will retain support for NIST_KW (hence documents it), while
the non-ext version will lose it in a few commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- Document constraints on buffers/pointers NULLability explicitly.
- Simplify terminology around IV/nonce: all AEADs implemented so far call that
a nonce. Keep the parameter names (iv, iv_len) to avoid having to change the
code (or having different names in the header and C files).
- Align documentation to the code regarding parameter constraints: the
documentation said the for ciphers with fixed nonce/tag length, the
iv_len/tag_len arguments were ignored, while the code enforced them to be the
expected value. This is more consistent with what's done with GCM/CCM, which
for tag_len for example accept more than one value, but from a relatively
small set, and will return errors for values outside that set. Accepting a
single value is a particular case of that (the set of acceptable value only
has one element).
Don't document behaviour with NIST KW as we're about to change that.
Note: this function is currently only defined if at least one of GCM, CCM or
ChachaPoly is enabled, even though it's supposed to handle NIST KW as well. No
need to fix this as the function will soon no longer support NIST KW.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
