Add extern "C" wrappers around type and function declarations to enable C++
interoperability of the driver header. This is done so that the driver
functions and types can be used or implmented by C++ code.
Convert PSA Crypto driver model structs to typedefs so that the `struct`
name doesn't need to be used and for consistent style with other PSA
structures.
The file crypto_driver.h was not using the header guard style as other PSA
Crypto header files. Remove the `__` prefix and suffix. Use C-style
comments for the end-of-guard comment.
The driver model's "encrypt or decrypt" type, encrypt_or_decrypt_t, is
publicly exposed and needs to have a `psa_` prefix in order to properly
communicate that it is part of the PSA driver model.
The `pcd_` prefix is ambiguous and does not make it clear that the types
and symbols are standardized by PSA. Replace `pcd_` with a prefix that can
be shared with all PSA drivers, `psa_drv_`.
"Driver APIs" can be interpreted to mean APIs used when you want to write a
driver, not the set of functions you implement to make a driver. See
https://www.kernel.org/doc/html/latest/driver-api/index.html "The kernel
offers a wide variety of interfaces to support the development of device
drivers."
As such, we are renaming "Driver API" to "Driver Model" and updating our
work so far to reflect this change.
snprintf was only added in Visual Studio 2015. This adds support
for building using Visual Studio versions prior to 2015.
This implementation of snprintf has been taken from platform.c
Wipe the whole MAC intermediate buffer, not just the requested MAC
size. With truncated MAC algorithms, the requested MAC size may be
smaller than what is written to the intermediate buffer.
Add comments noting that the maximum length of a MAC must fit in
PSA_ALG_MAC_TRUNCATION_MASK. Add a unit test that verifies that the
maximum MAC size fits.
Pass the nonce first, then the AD, then the input. This is the order
in which the data is processed and it's the order of the parameters to
the API functions.
There was a lot of repetition between psa_aead_encrypt and
psa_aead_decrypt. Refactor the code into a new function psa_aead_setup.
The new code should behave identically except that in some cases where
multiple error conditions apply, the code may now return a different
error code.
Internally, I rearranged some of the code:
* I removed a check that the key type was in CATEGORY_SYMMETRIC because
it's redundant with mbedtls_cipher_info_from_psa which enumerates
supported key types explicitly.
* The order of some validations is different to allow the split between
setup and data processing. The code now calls a more robust function
psa_aead_abort in case of any error after the early stage of the setup.
