Conflicts:
* `include/psa/crypto_sizes.h`: the addition of the `u` suffix in this branch
conflicts with the rework of the calculation of `PSA_HASH_MAX_SIZE` and
`PSA_HMAC_MAX_HASH_BLOCK_SIZE` in `development`. Use the new definitions
from `development`, and add the `u` suffix to the relevant constants.
Remove unnecessary "../library" prefix from test suite includes. This
makes the tests repo-agnostic between the mbedtls and psa-crypto repos.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The test for outputing a hexstring representation is actually
testing dn_gets, and is tested in test_suite_x509parse.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
Due to change in handling non-ascii characters, existing tests had to be
updated to handle the new implementation. New tests and certificates
are added to test the escaping functionality in edge cases.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
Converts none ascii to escaped hexpairs in mbedtls_x509_dn_gets and
interprets hexpairs in mbedtls_x509_string_to_names.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
This escapes special characters according to RFC 4514 in
mbedtls_x509_dn_gets and de-escapes in mbedtls_x509_string_to_names.
This commit does not handle hexpairs.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
Do explain why we don't test a smaller buffer in addition to testing the
nominal size and a larger buffer.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some basic test coverage for now:
* Nominal operation.
* Larger output buffer.
* Clone an operation and use it after the original operation stops.
Generate test data automatically. For the time being, only do that for
hashes that Python supports natively. Supporting all algorithms is future
work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
"Fix PBKDF2 with empty salt on platforms where malloc(0)=NULL" took care of
making an empty salt work. But it didn't fix the case of an empty salt
segment followed by a non-empty salt segment, which still invoked memcpy
with a potentially null pointer as the source. This commit fixes that case,
and also simplifies the logic in the function a little.
Test data obtained with:
```
pip3 install cryptodome
python3 -c 'import sys; from Crypto.Hash import SHA256; from Crypto.Protocol.KDF import PBKDF2; cost = int(sys.argv[1], 0); salt = bytes.fromhex(sys.argv[2]); password = bytes.fromhex(sys.argv[3]); n = int(sys.argv[4], 0); print(PBKDF2(password=password, salt=salt, dkLen=n, count=cost, hmac_hash_module=SHA256).hex())' 1 "" "706173737764" 64
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The hardware module name otherName SAN contains 2 OIDs:
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The first, type-id, is the one that identifies the otherName as a
HardwareModuleName. The second, hwType, identifies the type of hardware.
This change fixes 2 issues:
1. We were erroneously trying to identify HardwareModuleNames by looking
at hwType, not type-id.
2. We accidentally inverted the check so that we were checking that
hwType did NOT match HardwareModuleName.
This fix ensures that type-id is correctly checked to make sure that it
matches the OID for HardwareModuleName.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
