Renamed the tests because they are explicitly testing Curve25519 and
nothing else. Improved test coverage, test documentation and extended
in-code documentation with a specific reference to the standard as well.
The library is able to perform computations and cryptographic schemes on
curves with x coordinate ladder representation. Here we add the
capability to export such points.
The function `mbedtls_mpi_write_binary()` writes big endian byte order,
but we need to be able to write little endian in some caseses. (For
example when handling keys corresponding to Montgomery curves.)
Used `echo xx | tac -rs ..` to transform the test data to little endian.
The private keys used in ECDH differ in the case of Weierstrass and
Montgomery curves. They have different constraints, the former is based
on big endian, the latter little endian byte order. The fundamental
approach is different too:
- Weierstrass keys have to be in the right interval, otherwise they are
rejected.
- Any byte array of the right size is a valid Montgomery key and it
needs to be masked before interpreting it as a number.
Historically it was sufficient to use mbedtls_mpi_read_binary() to read
private keys, but as a preparation to improve support for Montgomery
curves we add mbedtls_ecp_read_key() to enable uniform treatment of EC
keys.
For the masking the `mbedtls_mpi_set_bit()` function is used. This is
suboptimal but seems to provide the best trade-off at this time.
Alternatives considered:
- Making a copy of the input buffer (less efficient)
- removing the `const` constraint from the input buffer (breaks the api
and makes it less user friendly)
- applying the mask directly to the limbs (violates the api between the
modules and creates and unwanted dependency)
The library is able to perform computations and cryptographic schemes on
curves with x coordinate ladder representation. Here we add the
capability to import such points.
The function `mbedtls_mpi_read_binary()` expects big endian byte order,
but we need to be able to read from little endian in some caseses. (For
example when handling keys corresponding to Montgomery curves.)
Used `echo xx | tac -rs .. | tr [a-z] [A-Z]` to transform the test data
to little endian and `echo "ibase=16;xx" | bc` to convert to decimal.
Add a test case for doing an ECDH calculation by calling
mbedtls_ecdh_get_params on both keys, with keys belonging to
different groups. This should fail, but currently passes.
The test function pkcs1_rsaes_v15_encrypt gets its fake-random input
for padding from a test parameter. In one test case, the parameter was
too short, causing a fallback to rand(). The reference output depends
on this random input, so the test data was correct only for a platform
with one particular rand() implementation. Supply sufficient
fake-random input so that rand() isn't called.
Don't unconditionally enable PSA Crypto for all tests. Only enable it in
tests that require it. This allows crypto tests to check that
psa_crypto_init() fails when it is supposed to fail, since we want to
perform some action in a test, and then call psa_crypto_init() and check
the result without it having been called previously.
The existing test `x509parse_crt()` for X.509 CRT parsing
so far used the generic parsing API `mbedtls_x509_crt_parse()`
capable of parsing both PEM encoded and DER encoded certficates,
but was actually only used with DER encoded input data. Moreover,
as the purpose of the test is the testing of the core DER X.509 parsing
functionality, not the PEM vs. DER dispatch (which is now already tested
in the various `x509_crt_info()` tests), the call can be replaced with a
direct call to `mbedtls_x509_parse_crt_der()`.
This commit does that, and further adds to the test an analogous
call to the new API `mbedtls_x509_parse_crt_der_nocopy()` to test
copyless parsing of X.509 certificates.
Additional changes to temporarily enable running tests:
ssl_srv.c and test_suite_ecdh use mbedtls_ecp_group_load instead of
mbedtls_ecdh_setup
test_suite_ctr_drbg uses mbedtls_ctr_drbg_update instead of
mbedtls_ctr_drbg_update_ret
Dependent on configured options, not all of the helper functions were being
used, which was leading to warning of unused functions with Clang.
To avoid any complex compile time options, or adding more logic to
generate_test_code.py to screen out unused functions, those functions which were
provoking the warning were changed to remove static, remove them from file
scope, and expose them to the linker.
Document when a context must be initialized or not, when it must be
set up or not, and whether it needs a private key or a public key will
do.
The implementation is sometimes more liberal than the documentation,
accepting a non-set-up context as a context that can't perform the
requested information. This preserves backward compatibility.
The MPI_VALIDATE_RET() macro cannot be used for parameter
validation of mbedtls_mpi_lsb() because this function returns
a size_t.
Use the underlying MBEDTLS_INTERNAL_VALIDATE_RET() insteaed,
returning 0 on failure.
Also, add a test for this behaviour.
For mbedtls_pk_parse_key and mbedtls_pk_parse_keyfile, the password is
optional. Clarify what this means: NULL is ok and means no password.
Validate parameters and test accordingly.
The test that mbedtls_aria_free() accepts NULL parameters
can be performed even if MBEDTLS_CHECK_PARAMS is unset, but
was previously included in the test case aria_invalid_params()
which is only executed if MBEDTLS_CHECK_PARAMS is set.
Parameter validation was previously performed and tested unconditionally
for the ChaCha/Poly modules. This commit therefore only needs go guard the
existing tests accordingly and use the appropriate test macros for parameter
validation.
Previously, one could change the definition of AES_VALIDATE_RET() to return
some other code than MBEDTLS_ERR_AES_BAD_INPUT_DATA, and the test suite
wouldn't notice. Now this modification would make the suite fail as expected.
The test framework for validation of parameters depends on the macro
MBEDTLS_PARAM_FAILED() being set to its default value when building the
library. So far the test framework attempted to define this macro but this was
the wrong place - this definition wouldn't be picked by the library.
Instead, a different approach is taken: skip those tests when the macro is
defined in config.h, as in that case we have no way to know if it will indeed
end up calling mbedtls_param_failed() as we need it to.
This commit was tested by manually ensuring that aes_invalid_params:
- passes (and is not skipped) in the default configuration
- is skipped when MBEDTLS_PARAM_FAILED() is defined in config.h
The previous prototype gave warnings are the strings produced by #cond and
__FILE__ are const, so we shouldn't implicitly cast them to non-const.
While at it modifying most example programs:
- include the header that has the function declaration, so that the definition
can be checked to match by the compiler
- fix whitespace
- make it work even if PLATFORM_C is not defined:
- CHECK_PARAMS is not documented as depending on PLATFORM_C and there is
no reason why it should
- so, remove the corresponding #if defined in each program...
- and add missing #defines for mbedtls_exit when needed
The result has been tested (make all test with -Werror) with the following
configurations:
- full with CHECK_PARAMS with PLATFORM_C
- full with CHECK_PARAMS without PLATFORM_C
- full without CHECK_PARAMS without PLATFORM_C
- full without CHECK_PARAMS with PLATFORM_C
Additionally, it has been manually tested that adding
mbedtls_aes_init( NULL );
near the normal call to mbedtls_aes_init() in programs/aes/aescrypt2.c has the
expected effect when running the program.
It was inconsistent between files: sometimes 3 arguments, sometimes one.
Align to 1 argument for the macro and 3 for the function, because:
- we don't need 3 arguments for the macro, it can add __FILE__ and __LINE__
in its expansion, while the function needs them as parameters to be correct;
- people who re-defined the macro should have flexibility, and 3 arguments
can give the impression they they don't have as much as they actually do;
- the design document has the macro with 1 argument, so let's stick to that.
Change the use of setjmp and longjmp in signalling parameter validation failures
when using the MBEDTLS_CHECK_PARAMS config.h option. This change allows
all calls which might result in a call to the parameter validation failure
handler to always be caught, even without use of the new macros, by placing a
setjmp() in the outer function which calls the test function, which the handler
can jump to.
This has several benefits:
* it allows us to remove the clang compiler warning (-Wclobbered) caused
by local auto variables being in the same function as the call to setjmp.
* removes the need to wrap all function calls in the test functions with the
TEST_ASSERT() macro. Now all parameter validation function calls should be
caught.
The tests for the ECDH key exchange that use the context accessed it
directly. This can't work with the new context, where we can't make any
assumptions about the implementation of the context. This commit works
around this problem and comes with the cost of allocating an extra
structures on the stack when executing the test.
One of the tests is testing an older interface for the sake of backward
compatibility. The new ECDH context is not backward compatible and this
test doesn't make any sense for it, therefore we skip this test in
non-legacy mode.
The recently added `mbedtls_ecdh_setup()` function is not used in the
tests yet. This commit adapts the tests to the new workflow.
Having done that, the old lifecycle is not tested anymore, so we add a
new test to ensure backward compatibility.
Since the AD too long is a limitation on Mbed TLS,
HW accelerators may support this. Run the test for AD too long,
only if `MBEDTLS_CCM_ALT` is not defined.
Addresses comment in #1996.
The test suites `test_suite_gcm.aes{128,192,256}_en.data` contains
numerous NIST test vectors for AES-*-GCM against which the GCM
API mbedtls_gcm_xxx() is tested.
However, one level higher at the cipher API, no tests exist which
exercise mbedtls_cipher_auth_{encrypt/decrypt}() for GCM ciphers,
although test_suite_cipher.function contains the test auth_crypt_tv
which does precisely that and is already used e.g. in
test_suite_cipher.ccm.
This commit replicates the test vectors from
test_suite_gcm.aes{128,192,256}_en.data in test_suite_cipher.gcm.data
and adds a run of auth_crypt_tv for each of them.
The conversion was mainly done through the sed command line
```
s/gcm_decrypt_and_verify:\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):
\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\)/auth_crypt_tv:
\1:\2:\4:\5:\3:\7:\8:\9/
```
It's better for names in the API to describe the "what" (opaque keys) rather
than the "how" (using PSA), at least since we don't intend to have multiple
function doing the same "what" in different ways in the foreseeable future.
Unfortunately the can_do wrapper does not receive the key context as an
argument, so it cannot check psa_get_key_information(). Later we might want to
change our internal structures to fix this, but for now we'll just restrict
opaque PSA keys to be ECDSA keypairs, as this is the only thing we need for
now. It also simplifies testing a bit (no need to test each key type).
While at it, clarify who's responsible for destroying the underlying key. That
can't be us because some keys cannot be destroyed and we wouldn't know. So
let's leave that up to the caller.
