This test data file is automatically generated. We could do that as
part of the build, since the only requirement is Python and we have a
requirement on Python to build tests anyway (to generate the .c file
from the .function file). However, committing the generating file into
the repository has less impact on build scripts, and will be necessary
for some of the files generated by generate_psa_tests.py (at least the
storage format stability tests, for which stability is guaranteed by
the fact that the generated file doesn't change). To keep things
simple, for now, let's commit all the files generated by
generate_psa_tests.py into the repository.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the generation is sensitive to trivial differences such as
running `tests/scripts/generate_psa_tests.py` vs
`./tests/scripts/generate_psa_tests.py` vs an absolute path.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add support for ECC key types to the generation of not-supported test
cases in generate_psa_tests.py. For each curve, generate test cases
both for when ECC isn't supported and for when the curve isn't
supported.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
SECP192R1 is declared in the PSA API specification, but it's an old
one that Mbed TLS doesn't support and even OpenSSL doesn't support.
We don't have test vectors for it. Just skip it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Asymmetric keys can't just be arbitrary byte strings: the public key
has to match the private key and the private key usually has
nontrivial constraints.
In order to have deterministic test data and not to rely on
cryptographic dependencies in the Python script, hard-code some test
keys.
In this commit, copy some test keys from test_suite_psa_crypto.data.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For each declared key type, generate test cases for psa_import_key and
psa_generate_key when the corresponding type is not supported.
Some special cases:
* Public keys can never be generated.
* Omit key types that Mbed TLS does not support at all.
* ECC and FFDH, which depend on a curve/group, are not covered yet.
The generated test cases are written to
tests/suites/test_suite_psa_crypto_not_supported.generated.data .
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit creates a script to generate test cases automatically
based on enumerating PSA key types, algorithms and other
classifications of cryptographic mechanisms.
Subsequent commits will implement the generation of test cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
To start with, test that key creation fails as intended when the key
type is not supported. This commit only covers psa_import_key and
psa_generate_key. A follow-up will cover psa_key_derivation_output_key.
My primary intent in creating this new test suite is to automatically
generate test cases by enumerating the key types and algorithms that
the library supports. But this commit only adds a few manually written
test cases, to get the ball rolling.
Move the relevant test cases of test_suite_psa_crypto.data that only
depend on generic knowledge about the API. Keep test cases that depend
more closely on the implementation, such as tests of non-supported key
sizes, in test_suite_psa_crypto.data.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
New Python module intended to gather knowledge about key types and
cryptographic mechanisms, such as the ability to create test data for
a given key type and the determination of whether an algorithm is
compatible with a key type.
This commit just creates a class for knowledge about key types.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Older versions of Pylint (<2.1.0) limited the names of various things
to 30 characters. We allowed up to 35 characters for method name due
to pre-existing identifiers.
Modern versions of Pylint no longer have an upper limit. Let's not be
pickier than Pylint's default configuration.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
At the moment it makes no difference, but it could if e.g. a new
algorithm was called 'foomask'.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
By default, exclude macros whose numerical value is not a valid member
of the semantic type (e.g. PSA_ALG_xxx_BASE is not itself an
algorithm, only an intermediate value used to construct others). But
do include them with include_intermediate=True, which
generate_psa_constants.py does.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Change psa_rsa_sign/verify signature to that of
a sign/verify_hash driver entry point before to
move them to the psa_crypto_rsa.c RSA specific file.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Change psa_driver_wrapper_sign/verify_hash signature
to that of a sign/verify_hash driver entry point.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Wrap sign/verify_hash software implementation into
psa_sign/verify_hash_internal() functions whose
signature is that of a sign/verify_hash driver
entry point.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Update with CHACHA20_POLY1305, CHACHA20. Add in CTR, which was missing,
and move ALG_XTS to its proper location alphabetically.
Signed-off-by: David Brown <david.brown@linaro.org>
Change the psa_crypto use of the CHACHA20 cipher to also use the new
MBEDTLS_PSA_BUILTIN_KE_TYPE_CHACHA20.
Signed-off-by: David Brown <david.brown@linaro.org>
Change a few conditionals in the psa library to be based on the
MBEDTLS_PSA_BUILTIN_KEY_TYPE_DES instead of the WANT macros. Future
additions of HW acceleration will need to be mindful of these
definitions if any of this code is needed in those instances.
Signed-off-by: David Brown <david.brown@linaro.org>
With the else branch commented out, both lines are unnecessary. We
could check for the invalid configuration in the future, once tests were
made to exclude this combination.
Signed-off-by: David Brown <david.brown@linaro.org>
There is no PSA ALG_ECB, only ALG_ECB_NO_PADDING. Fix one incorrect
declaration, and remove another that is just redundant.
Signed-off-by: David Brown <david.brown@linaro.org>
Only define MBEDTLS_CIPHER_MODE_CBC if one of the CBC modes is requested
and everything isn't covered by an accelerated version. This keeps this
from being defined in cases where everything needed would be
accelerated.
Signed-off-by: David Brown <david.brown@linaro.org>
When converting definitions to use the new PSA defines, one erroneously
was conditionalized on the WANT macro instead of on the BUILTIN macro.
Signed-off-by: David Brown <david.brown@linaro.org>
This reverts commit 4192e9a90c210005f6b558ec51c6a694c902b51d.
Converting conditional compliation for PSA configuration will come
later.
Signed-off-by: David Brown <david.brown@linaro.org>
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>
