Genertae test_suite_psa_crypto_generate_key.generated.data.
Use test_suite_psa_crypto_generate_key.function as a test function.
Signed-off-by: Przemyslaw Stekiel <przemyslaw.stekiel@mobica.com>
At least twice, we added a classification flag but forgot to test it in the
relevant test functions. Add some protection so that this doesn't happen
again. In each classification category, put a macro xxx_FLAG_MASK_PLUS_ONE
at the end. In the corresponding test function, keep track of the flags that
are tested, and check that their mask is xxx_FLAG_MASK_PLUS_ONE - 1 which is
all the bits of the previous flags set.
Now, if we add a flag without testing it, the test
TEST_EQUAL( classification_flags_tested, xxx_FLAG_MASK_PLUS_ONE - 1 )
will fail. It will also fail if we make the set of flag numbers
non-consecutive, which is ok.
This reveals that three algorithm flags had been added but not tested (in
two separate occasions). Also, one key type flag that is no longer used by
the library was still defined but not tested, which is not a test gap but is
inconsistent. It's for DSA, which is relevant to the PSA encoding even if
Mbed TLS doesn't implement it, so keep the flag and do test it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The status of signature wildcards with respect to PSA_ALG_IS_HASH_AND_SIGN
is unclear in the specification. A wildcard is usually instantiated with a
specific hash, making the implementation hash-and-sign, but it could also be
instantiated with a non-hash-and-sign algorithm. For the time being, go with
what's currently implemented, which is that they are considered
hash-and-sign.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The current definition of PSA_ALG_IS_HASH_AND_SIGN includes
PSA_ALG_RSA_PKCS1V15_SIGN_RAW and PSA_ALG_ECDSA_ANY, which don't strictly
follow the hash-and-sign paradigm: the algorithm does not encode a hash
algorithm that is applied prior to the signature step. The definition in
fact encompasses what can be used with psa_sign_hash/psa_verify_hash, so
it's the correct definition for PSA_ALG_IS_SIGN_HASH. Therefore this commit
moves definition of PSA_ALG_IS_HASH_AND_SIGN to PSA_ALG_IS_SIGN_HASH, and
replace the definition of PSA_ALG_IS_HASH_AND_SIGN by a correct one (based
on PSA_ALG_IS_SIGN_HASH, excluding the algorithms where the pre-signature
step isn't to apply the hash encoded in the algorithm).
In the definition of PSA_ALG_SIGN_GET_HASH, keep the condition for a nonzero
output to be PSA_ALG_IS_HASH_AND_SIGN.
Everywhere else in the code base (definition of PSA_ALG_IS_SIGN_MESSAGE, and
every use of PSA_ALG_IS_HASH_AND_SIGN outside of crypto_values.h), we meant
PSA_ALG_IS_SIGN_HASH where we wrote PSA_ALG_IS_HASH_AND_SIGN, so do a
global replacement.
```
git grep -l IS_HASH_AND_SIGN ':!include/psa/crypto_values.h' | xargs perl -i -pe 's/ALG_IS_HASH_AND_SIGN/ALG_IS_SIGN_HASH/g'
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Only tested for algorithms for which we support HMAC, since that's all we
use PSA_HASH_BLOCK_LENGTH for at the moment.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
PSA_ALG_RSA_PSS algorithm now accepts only the same salt length for
verification that it produces when signing, as documented.
Fixes#4946.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test the following combinations:
* 1024-bit key, SHA-256, salt=0
* 1024-bit key, SHA-256, salt=31 (1 byte shorter than standard)
* 1024-bit key, SHA-256, salt=32 (standard length)
* 1024-bit key, SHA-256, salt=94 (maximum possible length)
* 1024-bit key, SHA-512, salt=61 (1 byte shorter than standard)
* 1024-bit key, SHA-512, salt=62 (standard = maximum possible length)
* 528-bit key, SHA-512, salt=0 (only possible length)
Test psa_verify_hash() for both PSA_ALG_RSA_PSS and PSA_ALG_RSA_PSS_ANY_SALT
with all of these combinations. For psa_verify_message(), just test once
with the standard length and once with a different length.
Note that as of this commit, both PSA_ALG_RSA_PSS and
PSA_ALG_RSA_PSS_ANY_SALT accept any salt length during verification, hence
all the new test cases are positive.
The verify test cases were generated using the Python script below.
```
from Cryptodome import Hash
from Cryptodome.Hash import SHA512
from Cryptodome import PublicKey
from Cryptodome.PublicKey import RSA
from Cryptodome.Signature import pss
key = {
528: RSA.import_key(bytes.fromhex("30820145020100024300e31c246d46485984261fd174cab3d4357344602ecd793c47dbe54252d37bb350bc634359b19515542080e4724a4b672291be57c7648f51629eaef234e847d99cc65f0203010001024300b166322e09504a5c274b83592f5cf8ce2793a96de5a265abdbe060c641dbc65db0d11c782fe133a7e60aea686d21058d928cad3ef58924c4bb26b9206a03001d0241022200f85d72e463b406ffa282c34b5f0c2d6c2aacf210246af53d5bc7a0b7fa036e1cdb022200ea176c3d9a7fb355fb9fb7707e679b4acfb7bcb645b907e27cdf1764bc340971cd02212e13380342b3dd3083777abf7acc8988ad8a1406069b890f6efd63c57dae31394d022200c3602d3cf537e3cbbda93e072bd8f92965586aae8e5eb20ffc3c8e5fcb1c7b4d7902220098a04f18e48c689ad2f5b9bd404333def54cb2506cd0075c967a2968261e8b8f10")),
1024: RSA.import_key(bytes.fromhex("3082025e02010002818100af057d396ee84fb75fdbb5c2b13c7fe5a654aa8aa2470b541ee1feb0b12d25c79711531249e1129628042dbbb6c120d1443524ef4c0e6e1d8956eeb2077af12349ddeee54483bc06c2c61948cd02b202e796aebd94d3a7cbf859c2c1819c324cb82b9cd34ede263a2abffe4733f077869e8660f7d6834da53d690ef7985f6bc3020301000102818100874bf0ffc2f2a71d14671ddd0171c954d7fdbf50281e4f6d99ea0e1ebcf82faa58e7b595ffb293d1abe17f110b37c48cc0f36c37e84d876621d327f64bbe08457d3ec4098ba2fa0a319fba411c2841ed7be83196a8cdf9daa5d00694bc335fc4c32217fe0488bce9cb7202e59468b1ead119000477db2ca797fac19eda3f58c1024100e2ab760841bb9d30a81d222de1eb7381d82214407f1b975cbbfe4e1a9467fd98adbd78f607836ca5be1928b9d160d97fd45c12d6b52e2c9871a174c66b488113024100c5ab27602159ae7d6f20c3c2ee851e46dc112e689e28d5fcbbf990a99ef8a90b8bb44fd36467e7fc1789ceb663abda338652c3c73f111774902e840565927091024100b6cdbd354f7df579a63b48b3643e353b84898777b48b15f94e0bfc0567a6ae5911d57ad6409cf7647bf96264e9bd87eb95e263b7110b9a1f9f94acced0fafa4d024071195eec37e8d257decfc672b07ae639f10cbb9b0c739d0c809968d644a94e3fd6ed9287077a14583f379058f76a8aecd43c62dc8c0f41766650d725275ac4a1024100bb32d133edc2e048d463388b7be9cb4be29f4b6250be603e70e3647501c97ddde20a4e71be95fd5e71784e25aca4baf25be5738aae59bbfe1c997781447a2b24")),
}
hash_module = {
256: Hash.SHA256,
512: Hash.SHA512,
}
def print_test_case(remark, pub, kbits, hbits, input, output):
key_hex = pub.hex()
input_hex = input.hex()
output_hex = output.hex()
print(f"""\
PSA verify hash: RSA-{kbits} PSS SHA-{hbits}, {remark}
depends_on:PSA_WANT_ALG_RSA_PSS:PSA_WANT_ALG_SHA_{hbits}:PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY:MBEDTLS_PK_PARSE_C:MBEDTLS_MD_C
verify_hash:PSA_KEY_TYPE_RSA_PUBLIC_KEY:"{key_hex}":PSA_ALG_RSA_PSS(PSA_ALG_SHA_{hbits}):"{input_hex}":"{output_hex}"
PSA verify hash: RSA-{kbits} PSS-any-salt SHA-{hbits}, {remark}
depends_on:PSA_WANT_ALG_RSA_PSS:PSA_WANT_ALG_SHA_{hbits}:PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY:MBEDTLS_PK_PARSE_C:MBEDTLS_MD_C
verify_hash:PSA_KEY_TYPE_RSA_PUBLIC_KEY:"{key_hex}":PSA_ALG_RSA_PSS_ANY_SALT(PSA_ALG_SHA_{hbits}):"{input_hex}":"{output_hex}"
""")
def rand(n):
return bytes(x & 0xff for x in range(n))
def test_case(kbits, hbits, slen):
priv = key[kbits]
pub_spki = priv.publickey().export_key('DER')
pub_raw = PublicKey._expand_subject_public_key_info(pub_spki)[1]
hash_op = hash_module[hbits].new(b'abc')
digest = hash_op.copy().digest()
output = pss.new(priv, salt_bytes=slen, rand_func=rand).sign(hash_op)
print_test_case(f"slen={slen}", pub_raw, kbits, hbits, digest, output)
test_case(1024, 256, 0)
test_case(1024, 256, 31)
test_case(1024, 256, 32)
test_case(1024, 256, 94)
test_case(1024, 512, 61)
test_case(1024, 512, 62)
test_case(528, 512, 0)
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Ensure the unique part fits in the 66 columns that the test runner displays.
Leave room for an additional distinguisher on signature key policy negative
test cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test cases strictly replicate a subset of the test cases for
PSA_ALG_RSA_PSS. The subset validates that PSA_ALG_RSA_PSS_ANY_SALT is
recognized wherever PSA_ALG_RSA_PSS is.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a variant of PSA_ALG_RSA_PSS which currently has exactly the same
behavior, but is intended to have a different behavior when verifying
signatures.
In a subsequent commit, PSA_ALG_RSA_PSS will change to requiring the salt
length to be what it would produce when signing, as is currently documented,
whereas PSA_ALG_RSA_PSS_ANY_SALT will retain the current behavior of
allowing any salt length (including 0).
Changes in this commit:
* New algorithm constructor PSA_ALG_RSA_PSS_ANY_SALT.
* New predicates PSA_ALG_IS_RSA_PSS_STANDARD_SALT (corresponding to
PSA_ALG_RSA_PSS) and PSA_ALG_IS_RSA_PSS_ANY_SALT (corresponding to
PSA_ALG_RSA_PSS_ANY_SALT).
* Support for the new predicates in macro_collector.py (needed for
generate_psa_constant_names).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
digits is also a local variable in host_test.function, leading to compilers
complaining about that shadowing the global variable in
test_suite_base64.function.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is part of the definition of the encoding, not a choice of test
parameter, so keep it with the test code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add unit tests for mask_of_range(), enc_char() and dec_value().
When constant-flow testing is enabled, verify that these functions are
constant-flow.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When TEST_EQUAL fails, show the two numerical values in the test log (only
with host_test). The values are printed in hexa and signed decimal.
The arguments of TEST_EQUAL must now be integers, not pointers or floats.
The current implementation requires them to fit in unsigned long long
Signed values no larger than long long will work too. The implementation
uses unsigned long long rather than uintmax_t to reduce portability
concerns. The snprintf function must support "%llx" and "%lld".
For this purpose, add room for two lines of text to the mbedtls_test_info
structure. This adds 154 bytes of global data.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use the encoding from an upcoming version of the specification.
Add as much (or as little) testing as is currently present for Camellia.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Declare all AES and DES functions that return int as needing to have
their result checked, and do check the result in our code.
A DES or AES block operation can fail in alternative implementations of
mbedtls_internal_aes_encrypt() (under MBEDTLS_AES_ENCRYPT_ALT),
mbedtls_internal_aes_decrypt() (under MBEDTLS_AES_DECRYPT_ALT),
mbedtls_des_crypt_ecb() (under MBEDTLS_DES_CRYPT_ECB_ALT),
mbedtls_des3_crypt_ecb() (under MBEDTLS_DES3_CRYPT_ECB_ALT).
A failure can happen if the accelerator peripheral is in a bad state.
Several block modes were not catching the error.
This commit does the following code changes, grouped together to avoid
having an intermediate commit where the build fails:
* Add MBEDTLS_CHECK_RETURN to all functions returning int in aes.h and des.h.
* Fix all places where this causes a GCC warning, indicating that our code
was not properly checking the result of an AES operation:
* In library code: on failure, goto exit and return ret.
* In pkey programs: goto exit.
* In the benchmark program: exit (not ideal since there's no error
message, but it's what the code currently does for failures).
* In test code: TEST_ASSERT.
* Changelog entry.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It was unmaintained and untested, and the fear of breaking it was holding us
back. Resolves#4934.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The psa_open_key API depends on MBEDTLS_PSA_CRYPTO_STORAGE_C.
This is unnecessary for builtin keys and so is fixed.
Updated an open_fail test vector keeping with the same.
Signed-off-by: Archana <archana.madhavan@silabs.com>
Call the output size macros specifically with asymmetric keys, which
would cause a crash (and thus test fail) should this fix get regressed.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
This file had temporary MBEDTLS_xxx dependencies because it was created when
support for PSA_WANT_xxx was still incomplete. Switch to the PSA_WANT_xxx
dependencies
This fixes the bug that "PSA storage read: AES-GCM+CTR" was never executed
because there was a typo in a dependency.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Previously the check was convoluted. This has been simplified
and given a more appropriate suggestion as per gilles suggestion
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
In order to for tests to pass from the previous commit (which it mandatory for all pk verify/sign
functions to be given a hash_len that is exactly equal to the message digest length of md_alg) the
hash_len that is supplied to the fucntion cannot be MBEDTLS_MD_MAX_SIZE. This would result in all tests failing. Since the md alg for all of these funtions are SHA256, we can use mbedtls functions to get
the required length of a SHA256 digest (32 bytes). Then that number can be used for allocating the
hash buffer.
Signed-off-by: Nick Child <nick.child@ibm.com>
It is enough only one test case for a key type, algorithm pair when
testing the implicit usage flags.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Add test cases validating that if a stored key only had the hash policy,
then after loading it psa_get_key_attributes reports that it also has the
message policy, and the key can be used with message functions.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Negative x coordinate was tested with the value -1. It happens to be one
of the low order points both for Curve25519 and Curve448 and might be
rejected because of that and not because it is negative. Make sure that
x < 0 is the only plausible reason for the point to be rejected.
Signed-off-by: Janos Follath <janos.follath@arm.com>
A test case for which the loop would take practically forever if it was
reached. The point would be to validate that the loop is not reached.
The test case should cause the CI to time out if starting with the
current code, ecp_check_pubkey_mx() was changed to call
ecp_check_pubkey_x25519() first and run the mbedtls_mpi_size(() test
afterwards, which would make no semantic difference in terms of memory
contents when the function returns, but would open the way for a DoS.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We were already rejecting them at the end, due to the fact that with the
usual (x, z) formulas they lead to the result (0, 0) so when we want to
normalize at the end, trying to compute the modular inverse of z will
give an error.
If we wanted to support those points, we'd a special case in
ecp_normalize_mxz(). But it's actually permitted by all sources
(RFC 7748 say we MAY reject 0 as a result) and recommended by some to
reject those points (either to ensure contributory behaviour, or to
protect against timing attack when the underlying field arithmetic is
not constant-time).
Since our field arithmetic is indeed not constant-time, let's reject
those points before they get mixed with sensitive data (in
ecp_mul_mxz()), in order to avoid exploitable leaks caused by the
special cases they would trigger. (See the "May the Fourth" paper
https://eprint.iacr.org/2017/806.pdf)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Modify tests to test mbedtls_psa_cipher_operation_t,
mbedtls_transparent_test_driver_cipher_operation_t and
mbedtls_opaque_test_driver_cipher_operation_t struct initialization macros.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Tests for psa_cipher_encrypt and psa_cipher_decrypt functions.
The psa_cipher_encrypt function takes no parameter for IV and always generates
it therefore there will be a randomness in the calculation and cannot be
validated by comparing the actual output with the expected output.
The function is tested by:
- doing a prtially randomized test with an encryption then a decryption
and validating the input with output of the decryption
- validating against the multipart encryption
The combination of this two methods provides enough coverage like a
known answer test.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Various functions for PSA hash operations call abort
on failure; test that this is done. The PSA spec does not require
this behaviour, but it makes our implementation more robust in
case the user does not abort the operation as required by the
PSA spec.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
Various functions for PSA cipher and mac operations call abort
on failure; test that this is done. The PSA spec does not require
this behaviour, but it makes our implementation more robust in
case the user does not abort the operation as required by the
PSA spec.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
The cipher_bad_order test happened to pass, but was not testing the
failure case it intended to test.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
Tests for psa_mac_compute and psa_mac_verify functions.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The psa_verify_hash() is the pre-hashed version of the API and supposed
to work on hashes generated by the user. There were tests passing that
were getting "hashes" of sizes different from the expected.
Transform these into properly failing tests.
Signed-off-by: Janos Follath <janos.follath@arm.com>
