The current macro collector only tried the minimum and maximum expressible
lengths for PSA_ALG_TRUNCATED_MAC and PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG.
This was good enough for psa_constant_names, but it's weak for exercising
keys, in particular because it doesn't include any valid AEAD tag length.
So cover more lengths.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Only allow selected modes with 64-bit block ciphers (i.e. DES).
This removes some storage tests and creates corresponding op_fail tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In key read tests, add usage flags that are suitable for the key type and
algorithm. This way, the call to exercise_key() in the test not only checks
that exporting the key is possible, but also that operations on the key are
possible.
This triggers a number of failures in edge cases where the generator
generates combinations that are not valid, which will be fixed in subsequent
commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This currently makes all the descriptions unambiguous even when truncated at
66 characters, as the unit test framework does.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The output of generate_psa_tests.py is almost unchanged: the differences are
only spaces after commas (now consistently omitted).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the generated storage format test cases, cover all supported
algorithms for each key type. This is a step towards exercising
the key with all the algorithms it supports; a subsequent commit
will generate a policy that permits the specified algorithms.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use the new generic is_public method.
Impact on generated cases: there are new HMAC test cases for SIGN_HASH. It
was a bug that these test cases were previously not generated.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The timing module might include time.h on its own when on
a suitable platform, even if MBEDTLS_HAVE_TIME is disabled.
Co-authored-by: Tom Cosgrove <tom.cosgrove@arm.com>
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Otherwise the error status can be PSA_ERROR_INVALID_SIGNATURE instead of the
expected PSA_ERROR_NOT_SUPPORTED in some configurations. For example, the
RSA verification code currently checks the signature size first whenever
PSA_KEY_TYPE_RSA_PUBLIC_KEY is enabled, and only gets into
algorithm-specific code if this passes, so it returns INVALID_SIGNATURE even
if the specific algorithm is not supported.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
They're redundant with the automatically generated test cases, but it's
useful to have them when debugging issues with the test code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test suite test_suite_psa_crypto_op_fail now runs a large number
of automatically generated test cases which attempt to perform a
one-shot operation or to set up a multi-part operation with invalid
parameters. The following cases are fully covered (based on the
enumeration of valid algorithms and key types):
* An algorithm is not supported.
* The key type is not compatible with the algorithm (for operations
that use a key).
* The algorithm is not compatible for the operation.
Some test functions allow the library to return PSA_ERROR_NOT_SUPPORTED
where the test code generator expects PSA_ERROR_INVALID_ARGUMENT or vice
versa. This may be refined in the future.
Some corner cases with algorithms combining a key agreement with a key
derivation are not handled properly. This will be fixed in follow-up
commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test that hash operation functions fail when given a hash algorithm
that is not supported or an algorithm that is not a hash.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The new test suite psa_crypto_op_fail is intended for systematically
generated test cases that ensure that cryptographic operations with
invalid parameters fail as expected. I intend invalid parameters to
cover things like an invalid algorithm, an algorithm that is
incompatible with the operation, a key type that is incompatible with
the algorithm, etc.
This commit just creates the infrastructure. Subsequent commits will
add data generation and test code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Generate "with implication" and "without implication" usage test cases
separately.
The set of generated test cases is unchanged. The order, and the description
of "with implication" test cases, changes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a call to `mbedtls_md_starts()` in the `mbedtls_md_process()`
test, as it violates the API usage. Fixes#2227.
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
This commit alters the relevant .data files
such that the new function name change of check_iv
to iv_len_validity is reflected there.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit changes name of check_iv to
iv_len_vlaidity as this seems to better describe
its functionality.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Expected output generated by OpenSSL (see below) apart from the case
where both password and salt are either NULL or zero length, as OpenSSL
does not support this. For these test cases we have had to use our own
output as that which is expected. Code to generate test cases is as
follows:
#include <openssl/pkcs12.h>
#include <openssl/evp.h>
#include <string.h>
int Keygen_Uni( const char * test_name, unsigned char *pass, int
passlen, unsigned char *salt,
int saltlen, int id, int iter, int n,
unsigned char *out, const EVP_MD
*md_type )
{
size_t index;
printf( "%s\n", test_name );
int ret = PKCS12_key_gen_uni( pass, passlen, salt, saltlen, id, iter,
n, out, md_type );
if( ret != 1 )
{
printf( "Key generation returned %d\n", ret );
}
else
{
for( index = 0; index < n; ++index )
{
printf( "%02x", out[index] );
}
printf( "\n" );
}
printf( "\n" );
}
int main(void)
{
unsigned char out_buf[48];
unsigned char pass[64];
int pass_len;
unsigned char salt[64];
int salt_len;
/* If ID=1, then the pseudorandom bits being produced are to be used
as key material for performing encryption or decryption.
If ID=2, then the pseudorandom bits being produced are to be
used as an IV (Initial Value) for encryption or decryption.
If ID=3, then the pseudorandom bits being produced are
to be used as an integrity key for MACing.
*/
int id = 1;
int iter = 3;
memset( out_buf, 0, sizeof( out_buf ) );
memset( pass, 0, sizeof( pass ) );
memset( salt, 0, sizeof( salt ) );
Keygen_Uni( "Zero length pass and salt", pass, 0, salt, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL pass and salt", NULL, 0, NULL, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
salt[0] = 0x01;
salt[1] = 0x23;
salt[2] = 0x45;
salt[3] = 0x67;
salt[4] = 0x89;
salt[5] = 0xab;
salt[6] = 0xcd;
salt[7] = 0xef;
Keygen_Uni( "Zero length pass", pass, 0, salt, 8, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL pass", NULL, 0, salt, 8, id, iter, sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
memset( salt, 0, sizeof( salt ) );
pass[0] = 0x01;
pass[1] = 0x23;
pass[2] = 0x45;
pass[3] = 0x67;
pass[4] = 0x89;
pass[5] = 0xab;
pass[6] = 0xcd;
pass[7] = 0xef;
Keygen_Uni( "Zero length salt", pass, 8, salt, 0, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
Keygen_Uni( "NULL salt", pass, 8, NULL, 0, id, iter, sizeof(out_buf),
out_buf, EVP_md5( ) );
memset( out_buf, 0, sizeof( out_buf ) );
salt[0] = 0x01;
salt[1] = 0x23;
salt[2] = 0x45;
salt[3] = 0x67;
salt[4] = 0x89;
salt[5] = 0xab;
salt[6] = 0xcd;
salt[7] = 0xef;
Keygen_Uni( "Valid pass and salt", pass, 8, salt, 8, id, iter,
sizeof(out_buf),
out_buf, EVP_md5( ) );
return 0;
}
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Can't call mbedtls_cipher_free(&invalid_ctx) in cleanup if
mbedtls_cipher_init(&invalid_ctx) hasn't been called.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The implementation was silently overwriting the IV length to 12
even though the caller passed a different value.
Change the behavior to signal that a different length is not supported.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
The implementation was silently overwriting the IV length to 12
even though the caller passed a different value.
Change the behavior to signal that a different length is not supported.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
