If the data is a bitstring or an octet string, instead use the hexstring
of the BER encoding (RFC 4514 Section 2.4)
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
This refactor is to accomodate future support of numericoid/hexstring
attributetype value pairs.
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>
* Don't break string literals in the allow list definition
* Comment each test that belongs to the allow list is there.
Signed-off-by: Tomás González <tomasagustin.gonzalezorlando@arm.com>
* Turn the warnings produced when finding non-executed tests that
are not in the allow list into errors.
Signed-off-by: Tomás González <tomasagustin.gonzalezorlando@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>
aca31654e6e96c76b073e0ffedb6ae53c9e4f4c7 removed a sentence with copypasta
refering to PBKDF2 instead of XTS. Restore that comment but fix the
copypasta.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
They're included by build_info.h and must not be included directly.
Currently, this only concerns one file: config_psa.h. It's technically a bug
to include it, but a harmless one because that header has already been
included by build_info.h except in configurations where it
effectively had no effect (enabling PSA options with PSA turned off).
We plan to split config_psa.h into multiple headers that are less
independent, which could make the inclusion more problematic.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since 3.0.0, mbedtls_config.h (formerly config.h) no longer needs to include
config_psa.h or check_config.h: build_info.h takes care of that.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't try to include MBEDTLS_PSA_CRYPTO_USER_CONFIG_FILE when
MBEDTLS_PSA_CRYPTO_CONFIG is disabled. This didn't make sense and was an
editorial mistake when adding it: it's meant as an addition to
MBEDTLS_PSA_CRYPTO_CONFIG_FILE, so it should be included under the same
conditions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
They belong here, next to the inclusion of the mbedtls config file. We only
put them in config_psa.h in Mbed TLS 2.x because there was no build_info.h
we could use.
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>
