If the key doesn't exist by the time this call is made
then the handle is invalid,
which means that PSA_ERROR_INVALID_HANDLE should be
returned rather than "does not exist"
It may be possible that the implementation runs out of
memory when exporting a key from storage or a secure
element. For example, it may not be possible to directly
move the data from storage to the caller, so the implementation
will have to buffer the material temporarily (an issue if dynamic
memory allocation scheme is used). For a large key
this is more likely to return.
It may be possible that an implementation does not
fetch key material until a command like
this is called and such an error may occur if an
off-chip secure storage dependency may have been wiped.
Note that PSA_ERROR_NOT_PERMITTED is not included
because I can't think of a scenario where you have
a valid key handle but aren't allowed to read the
attributes
x0-x3 are skipped such that function parameters to not have to be moved.
MULADDC_INIT and MULADDC_STOP are mostly empty because it is more
efficient to keep everything in registers (and that should easily be
possible). I considered a MULADDC_HUIT implementation, but could not
think of something that would be more efficient than basically 8
consecutive MULADDC_CORE. You could combine the loads and stores, but
it's probably more efficient to interleave them with arithmetic,
depending on the specific microarchitecture. NEON allows to do a
64x64->128 bit multiplication (and optional accumulation) in one
instruction, but is not great at handling carries.
Avoid compiler errors when MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER
is set by using the application ID type.
[Error] psa_crypto_slot_management.c@175,9: used type 'psa_key_id_t' (aka 'psa_key_file_id_t') where arithmetic or pointer type is required
A macro useful for initializing psa_key_id_t, whether
MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER is set or not. Without this
macro, it is necessary to know if
MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER as with it the key ID is
non-scalar and needs to be initialized with {0, 0}, and 0 otherwise when
key ID is scalar.
Adjust the wording to permit multiple handles to a single key - closing
a handle does not necessarily release volatile memory associated with
the key, that only occurs when the last handle is closed.
- Describe the implementation defined behavior for opening multiple
keys, and provide a reference to the relevant section.
- Describe the use of INSUFFICENT_MEMORY error to indicate additional
implementation resource constaints.
- Clarify the distinction between DOES_NOT_EXIST and INVALID_HANDLE
error conditions.
Avoid an error with differing linkages being expressed for
psa_set_key_domain_parameters() between crypto_extra.h and
crypto_struct.h in C++ builds.
[Error] crypto_extra.h@456,14: conflicting declaration of 'psa_status_t psa_set_key_domain_parameters(psa_key_attributes_t*, psa_key_type_t, const uint8_t *, size_t)' with 'C' linkage
Document that a curve returned by mbedtls_ecp_curve_list() or
mbedtls_ecp_grp_id_list() may lack support for ECDH or ECDSA.
Add a corresponding changelog entry, under "API Changes" because we
have changed the behavior: formerly, these functions skipped ECDH-only
curves, although this was not documented.
