Added test vectors with AES in CBC mode

[pawelosyp]

Current test vectors have some lack of the AES in CBC mode. For us, it is impossible to pass the tests because for the time being our platform supports only AES in CBC and no CTR mode.

This PR introduces test vectors of AES in CBC mode and allows to define the failing algorithm for HKDF (currently it was PSA_ALG_CTR). All modifications are related to unsupported PSA_ALG_CTR.

[avinaw01-arm]

May I know the purpose of using the 'ARCH_TEST_CBC_NO_PADDING' macro guard in Test-3 and 4 test-data?
There is an option provided to utilize the 'ARCH_TEST_CIPHER_MODE_CBC' macro guard for such instances.

[pawelosyp]

@avinaw01-arm Looks like you are right, I have used the wrong macro - changed as you suggested.

[avinaw01-arm]

In file 'api-tests/dev_apis/crypto/test_c018/test_data.h', may I know your intention behind using the below changes?

#ifdef ARCH_TEST_HKDF_FAILING_ALG
#define HKDF_FAILING_ALG ARCH_TEST_HKDF_FAILING_ALG
#else
#define HKDF_FAILING_ALG PSA_ALG_CTR
#endif

From my understanding, for that particular test-data which you're targeting to change algorithm for, it doesn't matter whether it's in CTR or CBC mode. It is going to fail, as we are intentionally giving incorrect algorithm. So, my suggestion would be to keep 'PSA_ALG_CTR' algorithm as it is for this particular data-set.
Kindly get back to me on this.

[pawelosyp]

In file 'api-tests/dev_apis/crypto/test_c018/test_data.h', may I know your intention behind using the below changes?

#ifdef ARCH_TEST_HKDF_FAILING_ALG
#define HKDF_FAILING_ALG ARCH_TEST_HKDF_FAILING_ALG
#else
#define HKDF_FAILING_ALG PSA_ALG_CTR
#endif

From my understanding, for that particular test-data which you're targeting to change algorithm for, it doesn't matter whether it's in CTR or CBC mode. It is going to fail, as we are intentionally giving incorrect algorithm. So, my suggestion would be to keep 'PSA_ALG_CTR' algorithm as it is for this particular data-set. Kindly get back to me on this.

Our current implementation does not support PSA_ALG_CTR and we are failing to import the key (it is a 3rd test check) - during the import procedure, we are checking if all parameters are supported by our implementation. Is such a checking mechanism incorrect?

[avinaw01-arm]

Fine, let's come to a middle solution. Instead of using all that defines, can you just change the 'algorithm' value for that data-set? You may keep that value anything other than the compatible ones for that key-type.

[avinaw01-arm]

Also, please update the Copyright header year to 2024 like this: "Copyright (c) 20XX-2024" for the following files:

1. api-tests/dev_apis/crypto/test_c003/test_data.h
2. api-tests/dev_apis/crypto/test_c004/test_data.h
3. api-tests/dev_apis/crypto/test_c032/test_data.h
4. api-tests/dev_apis/crypto/test_c033/test_data.h
5. api-tests/dev_apis/crypto/test_c034/test_c034.c
6. api-tests/dev_apis/crypto/test_c034/test_data.h
7. api-tests/dev_apis/crypto/test_c035/test_c035.c
8. api-tests/dev_apis/crypto/test_c035/test_data.h

[avinaw01-arm]

I can see in the data-sets of Test-3 and 4 which you have requested, have exactly identical parameters from their previous data-sets for CTR mode. Please don't replicate that; instead give an OR option while checking the macro-guards for CTR or CBC mode. Kindly make sure to incorporate this in your commit.

[avinaw01-arm]

Also, Test descriptions for many data-sets are coming identical while running the regressions. For example, in file 'api-tests/dev_apis/crypto/test_c032/test_data.h': ".test_desc = "Test psa_cipher_encrypt_setup 16 Byte AES\n","
This test description is coming exactly same twice for CTR and CBC mode. Please provide distinct descriptions for each data-set so that users can understand the context.
Kindly check this in for all test-data files from Test-32 to 35.

[pawelosyp]

@avinaw01-arm all your comments are reworked, good catch to combine test vectors in Test-3 and 4.

[avinaw01-arm]

Thank you.
You forgot to update one test-description in 'api-tests/dev_apis/crypto/test_c034/test_data.h'. Please check line 199.
Then, we can start final validation of this PR and proceed for merge.