The uint32 is given as a bigendian stream, in the tests, however,
the char buffer that collected the stream read it as is,
without converting it. Add a temporary buffer, to call `greentea_getc()`
8 times, and then put it in the correct endianity for input to `unhexify()`.
Reduce the stack usage of the `test_suite_pkcs1_v21` by reducing the
size of the buffers used in the tests, to a reasonable big enough size,
and change the size sent to the API to sizeof output.
Reduce the stack usage of the `test_suite_rsa` by reducing the
size of the buffers used in the tests, to a reasonable big enough size,
and change the data size to decrypt in the data file.
In very reduced configurations, we don't want the overhead of maintaining a
bool just to remember if the context is valid and checking that bit at every
point of entry.
Note: so far this validity bit also served as a proxy to ensure that pk_ctx
was valid (currently this is a pointer to a dynamically-allocated buffer). In
the next series of commits, this will be changed to a statically-allocated
buffer, so there will be no question about its validity.
In the end (after this commit and the next series), a pk_context_t will be
(memory-wise) just the same as a mbedtls_uecc_keypair when SINGLE_TYPE is
enabled - meaning the PK layer will have zero memory overhead in that case.
This is the first in a series of commit aimed at removing the pk_info
structures when we're building with MBEDTLS_PK_SINGLE_TYPE enabled.
Introducing this abstraction allows us to later make it a two-valued type
(valid, invalid) instead, which is much lighter.
No effect for now, just declaring it here, implemented in subsequent commits.
The option requires MBEDTLS_USE_TINYCRYPT and is incompatible with
MBEDTLS_PK_RSA_ALT_SUPPORT and MBEDTLS_RSA_C.
Currently users (including the X.509 and SSL libraries) assume that if both PK
and RSA are enabled, then RSA is available through PK. If we allowed RSA to be
enabled together with PK_SINGLE_TYPE, we'd break that assumption. Going
through the code to find all place that rely on that assumption and fix them
would be cumbersome, and people who want PK_SINGLE_TYPE are unlikely to care
about RSA anyway, so let's just make them incompatible.
This is also consistent with what's done in the MD module: MD_SINGLE_HASH
requires that exactly one hash be enabled.
* baremetal: (78 commits)
Review corrections 6
Review corrections 5
Minor changes to tinycrypt README
Typos in the tinycrypt README
Addition of copyright statements to tinycrypt files
Add LICENSE and README for tinycrypt
Add SPDX lines to each imported TinyCrypt file
Review corrections 4
Review corrections 3
Review corrections 2
Review corrections
Update signature of BE conversion functions
Use function for 16/24/32-bit BE conversion
x509.c: Minor readability improvement
x509_crt.c: Indicate guarding condition in #else branch
X.509: Don't remove verify callback by default
Fix Doxygen warnings regarding removed verify cb+ctx parameters
ECC restart: Use optional verification mode in bad signature test
Re-implement verify chain if vrfy cbs are disabled
Add zero-cost abstraction layer for CRT verification chain
...
* mbedtls-2.16: (28 commits)
Bump version to Mbed TLS 2.16.3
Changelog entry
Check for zero length and NULL buffer pointer
ssl-opt.sh: wait for proxy to start before running the script further
Fix uninitialized variable in x509_crt
HMAC DRBG: Split entropy-gathering requests to reduce request sizes
Fix the license header of hkdf
Add a change log entry
Add a test for mlaformed ECJPAKE context
Fix handling of md failure
Add a test for signing content with a long ECDSA key
Add documentation notes about the required size of the signature buffers
Add missing MBEDTLS_ECP_C dependencies in check_config.h
Change size of preallocated buffer for pk_sign() calls
Adapt ChangeLog
Fix mpi_bigendian_to_host() on bigendian systems
Add ChangeLog entry for new function
Add ChangeLog entry
Correct deterministic ECDSA behavior
Add warning for alternative ECDSA implementations
...
With the removal of MBEDTLS_MEMORY_BUFFER_ALLOC_C from the
full config, there are no tests for it remaining in all.sh.
This commit adds a build as well as runs of `make test` and
`ssl-opt.sh` with MBEDTLS_MEMORY_BUFFER_ALLOC_C enabled to all.sh.
Previously, numerous all.sh tests manually disabled the buffer allocator
or memory backtracting after setting a full config as the starting point.
With the removal of MBEDTLS_MEMORY_BACKTRACE and MBEDTLS_MEMORY_BUFFER_ALLOC_C
from full configs, this is no longer necessary.
With the removal of the MD handle from the MD context, it's a precondition
for any MD API outside of mbedtls_md_init() and mbedtls_md_setup() that
the MD context has been successfully setup by precisely those functions
beforehand, and hence must be bound to the single enabled valid MD handle.
This commit continues the introduction of the MD digest implementation
abstraction layer given by `mbedtls_md_handle_t` by adding getter
functions returning the various properties of an implementation
(e.g. name, digest type, digest size). For the existing implementation,
these are just structure field accesses; however, in configurations
hardcoding the choice of a fixed digest algorithm, we'll be able to
implement them as inline functions returning compile-time constants.
As has been previously done for ciphersuites, this commit introduces
a zero-cost abstraction layer around the type
mbedtls_md_info const *
whose valid values represent implementations of message digest algorithms.
Access to a particular digest implementation can be requested by name or
digest ID through the API mbedtls_md_info_from_xxx(), which either returns
a valid implementation or NULL, representing failure.
This commit replaces such uses of `mbedtls_md_info const *` by an abstract
type `mbedtls_md_handle_t` whose valid values represent digest implementations,
and which has a designated invalid value MBEDTLS_MD_INVALID_HANDLE.
The purpose of this abstraction layer is to pave the way for builds which
support precisely one digest algorithm. In this case, mbedtls_md_handle_t
can be implemented as a two-valued type, with one value representing the
invalid handle, and the unique valid value representing the unique enabled
digest.
Add a basic unit test for the ECDSA part of the tinycrypt.
It generates keys, signs and verifies. Modified from tinycrypt
tests found in tinycrypt-repository.
Moved some functions under defined to get rid of compiler warnings.
Functions moved under defines:
- mbedtls_x509_get_alg
- mbedtls_x509_get_alg_null
- mbedtls_x509_get_time
- mbedtls_x509_get_ext
- mbedtls_x509_sig_alg_gets
- mbedtls_x509_key_size_helper
Left one function (mbedtls_x509_write_names) as non static as it increased code size.
* origin/mbedtls-2.16:
Changelog entry
Check for zero length and NULL buffer pointer
ssl-opt.sh: wait for proxy to start before running the script further
Adapt ChangeLog
Fix mpi_bigendian_to_host() on bigendian systems
Previously, the TinyCrypt component in all.sh restricted the ssl-opt.sh
to the 'Default, DTLS' test, due to implicit dependencies on Secp384r1.
These dependencies are now explicit and ssl-opt.sh skips corresponding
tests accordingly, so we can introduce a full run of ssl-opt.sh into
the TinyCrypt test in all.sh.
This commit modifies ssl-opt.sh to autodetect the use of test certificates
server5.* server6.* test-ca2.* using Secp384r1, and skips the corresponding
tests if MBEDTLS_ECP_DP_SECP384R1_ENABLED isn't set.
Previously, the TinyCrypt all.sh test restricted the run of compat.sh
to DTLS 1.2 and listed a few explicit ciphersuites.
This commit widens the scope of the test by testing any ciphersuite
based on ECDHE-ECDSA, regardless of TLS/DTLS or the particular version.
Further, it doesn't exclude SHA-384 as done previously.
This commit uses the flexibility of being able to chose CRTs and keys
to be used by compat.sh through predefined environment variables to
force the use of Secp256r1 certificates and keys in the all.sh test
for TinyCrypt.
This commit introduces environment variables
- SRV_ECDSA_CRT
- SRV_ECDSA_KEY
- CLI_ECDSA_CRT
- CLI_ECDSA_KEY
- SRV_RSA_CRT
- SRV_RSA_KEY
- CLI_RSA_CRT
- CLI_RSA_KEY
- CA_FILE
to tests/compat.sh which hold the path of the CA, client and server
certificate and key files to use by the script.
This is a preparatory step towards switching to a different set of
certificates and keys in case the configuration doesn't match the
certificates in use so far (e.g.: the ECDSA certificates use Secp384r1,
so if that's disabled, ECDSA tests will fail).
Even though exhaustive testing of TinyCrypt is left for later,
without this test we don't have any evidence that PK writing
works for TinyCrypt-based PK context.
TinyCrypt only supports Secp256r1, so skip all tests in test_suite_x509parse
which use different curves, while splitting those which rely on Secp256r1
alone into two tests: one for legacy ECC, and one for TinyCrypt.
Studying and improving the TinyCrypt test coverage is left for a later commit.
The current pkwrite tests involving ECC all use curves different
from Secp256r1, so they don't apply to TinyCrypt.
Adding tests for TinyCrypt is left to a later commit.
- The underlying test vectors are for Secp192r1, while TinyCrypt uses Secp256r1.
- The test implementation is specific to the structure of legacy-ECC PK ctxs.
Addition of analogous tests for TinyCrypt-based ECC PK contexts are left
for a later commit.
TinyCrypt should be used as a replacement of legacy ECC. In particular,
there shouldn't be any use of identifiers from the legacy ECC module.
So far, there's the configuration option
MBEDTLS_SSL_CONF_SINGLE_EC_GRP_ID
that's relevant if MBEDTLS_SSL_CONF_SINGLE_CURVE is set, and which in
this case must resolve to an identifier of type mbedtls_ecp_group_id
indicating which single curve to enable.
With the introduction of TinyCrypt, we must either change the type
of this option to mbedtls_uecc_group_id, or introduce a separate
compilation option.
In order to avoid type confusion, this commit follows tha latter
approach, introducing the configuration option
MBEDTLS_SSL_CONF_SINGLE_UECC_GRP_ID
that indicatesthe TinyCrypt group identifier of the single curve
to use (must be Secp256r1) if MBEDTLS_SSL_CONF_SINGLE_CURVE
and MBEDTLS_USE_TINYCRYPT are set.
This commit splits each test in ssl-opt.sh related to context serialization
in three tests, exercising the use of CCM, GCM and ChaChaPoly separately.
The reason is that the choice of primitive affects the presence and size
of an explicit IV, and we should test that space for those IVs is correctly
restored during context deserialization; in fact, this was not the case
previously, as fixed in the last commit, and was not caught by the tests
because only ChaChaPoly was tested.
* mbedtls-2.16: (21 commits)
Exclude DTLS 1.2 only with older OpenSSL
Document the rationale for the armel build
Switch armel build to -Os
Add a build on ARMv5TE in ARM mode
Add changelog entry for ARM assembly fix
bn_mul.h: require at least ARMv6 to enable the ARM DSP code
Changelog entry for test certificates update
Change worktree_rev to HEAD for rev-parse
Add ChangeLog entry for entropy_nv_seed test case fix
entropy_nv_seed: cope with SHA-256
entropy_nv_seed: clean up properly
Add ChangeLog entry for undefined behavior fix in test_suite_nist_kw
Don't call memset after calloc
Adapt ChangeLog
ECP restart: Don't calculate address of sub ctx if ctx is NULL
Update certificates to expire in 2029
Update soon to be expired crl
Test that a shared library build produces a dynamically linked executable
Test that the shared library build with CMake works
Add a test of MBEDTLS_CONFIG_FILE
...
Now function mbedtls_ssl_set_hostname is compile-time configurable
in config.h with define MBEDTLS_X509_REMOVE_HOSTNAME_VERIFICATION.
This affects to many x509 API's. See config.h for details.
ssl_client2 and ssl_server2 either allow loading specific CRTs
and CAs from files, or to leave them unspecified, in which case
they're automatically picked from the test certificates.
The test certificates should be chosen in a way that when
not specifying any CRT or CA parameters, the automatically
chosen ones match - but if one of them is specified but not
the other, one should not expect tests to succeed.
With the recent switch to Secp256r1-based test certificates,
the default test certificates have changed, which breaks some
ssl-opt.sh tests which specify the server CRT explicitly but
not the client trusted CAs.
This commit fixes this by specifying the client's trusted CA
explicitly in accordance with the explicitly specified server CRT.
One test for running with MBEDTLS_ECDH_C on and one
for running MBEDTLS_ECDH_C off. Run ssl-opt.sh with Default, DTLS
and compatibility tests with TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA.
compat.sh used to skip OpenSSL altogether for DTLS 1.2, because older
versions of OpenSSL didn't support it. But these days it is supported.
We don't want to use DTLS 1.2 with OpenSSL unconditionally, because we
still use legacy versions of OpenSSL to test with legacy ciphers. So
check whether the version we're using supports it.
tinyCrypt is still tested in the baremetal tests since it
is enabled in baremetal.h. Tests for minimal modifictions
of the default / full config enabling tinyCrypt will be
added elsewhere.
Without any -O option, the default is -O0, and then the assembly code
is not used, so this would not be a non-regression test for the
assembly code that doesn't build.
* mbedtls-2.16:
Fix parsing issue when int parameter is in base 16
Refactor receive_uint32()
Refactor get_byte function
Make the script portable to both pythons
Update the test encoding to support python3
update the test script
tests: Limit each log to 10 GiB
It happens regularly in test runs that the server example application
shuts down a connection, goes into waiting mode for a new connection,
and then receives the encrypted ClosureAlert from the client. The only
reason why this does currently not trigger the 'record from another epoch'
message is that we handle ClientHello parsing outside of the main record
stack because we want to be able to detect SSLv2 ClientHellos. However,
this is likely to go away, and once it happens, we'll see the log message.
Further, when record checking is used, every record, including the mentioned
closure alert, is passed to the record checking API before being passed to
the rest of the stack, which leads to the log message being printed.
In summary, grepping for 'record from another epoch' is a fragile way
of checking whether a reordered message has arrived. A more reliable
way is to grep for 'Buffer record from epoch' which is printed when
a record from a future epoch is actually buffered, and 'ssl_buffer_message'
which is the function buffering a future handshake message.
This test case was only executed if the SHA-512 module was enabled and
MBEDTLS_ENTROPY_FORCE_SHA256 was not enabled, so "config.pl full"
didn't have a chance to reach it even if that enabled
MBEDTLS_PLATFORM_NV_SEED_ALT.
Now all it takes to enable this test is MBEDTLS_PLATFORM_NV_SEED_ALT
and its requirements, and the near-ubiquitous MD module.
Call mbedtls_entropy_free on test failure.
Restore the previous NV seed functions which the call to
mbedtls_platform_set_nv_seed() changed. This didn't break anything,
but only because the NV seed functions used for these tests happened
to work for the tests that got executed later in the .data file.
memset has undefined behavior when either pointer can be NULL, which
is the case when it's the result of malloc/calloc with a size of 0.
The memset calls here are useless anyway since they come immediately
after calloc.
mbedtls_ssL_set_calc_verify_md() is used to select valid hashes when
writing the server's CertificateRequest message, as well as to verify
and act on the client's choice when reading its CertificateVerify
message.
If enabled at compile-time and configured via mbedtls_ssl_conf_sig_hashes()
the current code also offers SHA-1 in TLS 1.2. However, the SHA-1-based
handshake transcript in TLS 1.2 is different from the SHA-1 handshake
transcript used in TLS < 1.2, and we only maintain the latter
(through ssl_update_checksum_md5sha1()), but not the former.
Concretely, this will lead to CertificateVerify verification failure
if the client picks SHA-1 for the CertificateVerify message in a TLS 1.2
handshake.
This commit removes SHA-1 from the list of supported hashes in
the CertificateRequest message, and adapts two tests in ssl-opt.sh
which expect SHA-1 to be listed in the CertificateRequest message.
* origin/mbedtls-2.16:
Fix parsing issue when int parameter is in base 16
Refactor receive_uint32()
Refactor get_byte function
Make the script portable to both pythons
Update the test encoding to support python3
update the test script
tests: Limit each log to 10 GiB
Fix error `ValueError: invalid literal for int() with base 10:` that
is caused when a parameter is given in base 16. Use relevant base
when calling `int()` function.
Call `greentea_getc()` 8 times, and then `unhexify` once, instead of
calling `receive_byte()`, which inside calls `greentea_getc()` twice,
for every hex digit.
Since Python3 handles encoding differently than Python2,
a change in the way the data is encoded and sent to the target is needed.
1. Change the test data to be sent as hex string
2. Convert the characters to binary bytes.
This is done because the mbed tools translate the encoding differently
(mbed-greentea, and mbed-htrunner)
Limit log output in compat.sh and ssl-opt.sh, in case of failures with
these scripts where they may output seemingly unlimited length error
logs.
Note that ulimit -f uses units of 512 bytes, so we use 10 * 1024 * 1024
* 2 to get 10 GiB.
