psa_aead_generate_nonce() could generate a nonce of up to 13 bytes,
depending on the inputs to psa_aead_set_lengths().
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Generate test cases for all key types. These test cases cover the key
representation (checked with export) and the encoding of the key type and
the bit-size.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Start generating storage format test cases. This commit introduces two test
data files: test_suite_psa_crypto_storage_format.v0.data for reading keys in
storage format version 0 (the current version at this time), and
test_suite_psa_crypto_storage_format.current.data for saving keys in the
current format (version 0 at this time).
This commit kicks off the test case generation with test cases to exercise
the encoding of usage flags. Subsequent commits will cover other aspects of
keys.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Construct an object given the attributes and material for a PSA crypto key
and get the Mbed TLS storage representation.
The code to generate the storage representation was written based on the
specification in docs/architecture/mbed-crypto-storage-specification.md,
without looking at the code.
The data in the unit tests is from the AES-128 format_storage_data_check
test case in test_suite_psa_crypto_persistent_key.data, tweaked manually.
This commit creates a basic framework for using symbolic values for
attributes, but does not yet implement obtaining the corresponding numerical
values from an external source.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Save tests are for forward compatibility: import a key in the current format
and check that it has the expected storage format so that future versions
will still be able to read it.
Read tests are for backward compatibility: read a key in the format of a
past version (injected into storage) and check that this version can use it.
Exercise the key unless it is meant to test metadata storage only.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make it possible to enumerate the key types, algorithms, etc.
collected by PSAMacroCollector.
This commit ensures that all fields of PSAMacroEnumerator are filled
by code inspection. Testing of the result may reveal more work to be
done in later commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split out the code that enumerates constructors of a PSA crypto type
from the code used to populate the list of constructors for the
specific purpose of testing psa_constant_names.
This commit adds some documentation but otherwise strives to minimize
code changes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Generating all files all the time makes debugging one specific target
harder. So support generating a selection of targets only.
As a bonus, it is now more apparent what files this script generates,
and check-generated-files.sh takes advantage of it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use separate classes for information gathering, for each kind of test
generation (currently just one: not-supported), and for writing output
files.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix SEC to SECP as the curve name. This fixes failing tests that
verified the config option was working.
Signed-off-by: David Brown <david.brown@linaro.org>
An earlier commit fixes the names of the PSA_WANT_ECC_ macros. Update
the crypto_config.h file to match these new names.
Signed-off-by: David Brown <david.brown@linaro.org>
Now that PSA crypto config supports the new PSA_WANT_ECC_xxx defines,
change the psa-specific test suites to use these new names.
Signed-off-by: David Brown <david.brown@linaro.org>
Use the names as described in
`docs/proposed/psa-conditional-inclusion-c.md which use a transform
like: SECP256R1 -> SECP_R1_256. The CURVE25519 and CURVE448 become
MONTGOMERY_255 and MONTGOMERY_448.
Signed-off-by: David Brown <david.brown@linaro.org>
For each curve defined MBEDTLS_ECP_DP_xxx_ENABLED, we have a
corrsponding PSA config define PSA_WANT_ECC_xxx. Along with that is a
value MBEDTLS_PSA_ACCEL_ECC_xxx which can be used to allow HW
acceleration of that particular curve.
If the PSA config requests an unaccelerated curve, the corresponding
MBEDTLS_PSA_BUILTIN_ECC_xxx will also be defined.
This commit defines these for all curves currently defined, with the
defines working in either direction, depending on whether
MBEDTLS_PSA_CRYPTO_CONFIG is defined.
Signed-off-by: David Brown <david.brown@linaro.org>
MinGW and older windows compilers cannot cope with %zu or %lld (there is
a workaround for MinGW, but it involves linking more code, there is no
workaround for Windows compilers prior to 2013). Attempt to work around
this by defining printf specifiers for size_t per platform for the
compilers that cannot use the C99 specifiers.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
This was a false positive caused by the compiler seeing the %08lx
specifiers and judging the output on that, rather than the numbers being
fed in. Given these are going to be maximum 32 bit numbers, then better
to use %08x, which keeps -Wformat-truncation=2 happy as well.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Fixes for printf format specifiers, where they have been flagged as
invalid sizes by coverity, and new build flags to enable catching these
errors when building using CMake. Note that this patch uses %zu, which
requires C99 or later.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Printf could potentially produce 2 64 bit numbers here when there is
only space for one, thus causing a buffer overflow. This was caught by
the new warning flags.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
We were not getting any warnings on printf format errors, as we do not
explicitly use printf anywhere in the code. Thankfully there is a way
to mark a function as having printf behaviour so that its inputs can be
checked in the same way as printf would be.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Add extra printf warning flags into the cmake build, only adding those
that are supported by each version of the compiler
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Test hash algorithm functions when called through a transparent
driver in all.sh test_psa_crypto_config_basic and
test_psa_crypto_drivers components.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Apply the right define guards for the right purpose. The 'core' hash
driver is included if any hash algorithm is either to be tested through
the test driver, or if it is requested by a user and not accelerated
(i.e. 'fallback'/'software' driver requested for the algorithm).
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
