The stack buffer used to hold the decrypted key in pk_parse_pkcs8_encrypted_der
was statically sized to 2048 bytes, which is not enough for DER encoded 4096bit
RSA keys.
This commit resolves the problem by performing the key-decryption in-place,
circumventing the introduction of another stack or heap copy of the key.
There are two situations where pk_parse_pkcs8_encrypted_der is invoked:
1. When processing a PEM-encoded encrypted key in mbedtls_pk_parse_key.
This does not need adaption since the PEM context used to hold the decoded
key is already constructed and owned by mbedtls_pk_parse_key.
2. When processing a DER-encoded encrypted key in mbedtls_pk_parse_key.
In this case, mbedtls_pk_parse_key calls pk_parse_pkcs8_encrypted_der with
the buffer provided by the user, which is declared const. The commit
therefore adds a small code paths making a copy of the keybuffer before
calling pk_parse_pkcs8_encrypted_der.
This commit adds the macro ENTROPY_HAVE_STRONG to the helper test file tests/suites/helpers.function to be able to make
tests depend on the presence of strong entropy.
The entropy test suite uses a negative dependency "depends_on:!CONFIG_FLAG" for one of its tests. This kind of
dependency (running a test only if some configuration flag is not defined) is currently not supported and instead
results in the respective test case being dropped.
This commit adds support for negative dependencies in test cases.
The function `mbedtls_rsa_gen_key` from `test_suite_rsa.function` initialized a stack allocated RSA context only after
seeding the CTR DRBG. If the latter operation failed, the cleanup code tried to free the uninitialized RSA context,
potentially resulting in a segmentation fault. Fixes one aspect of #1023.
There were preprocessor directives in pk.c and pk_wrap.c that cheked
whether the bit length of size_t was greater than that of unsigned int.
However, the check relied on the MBEDTLS_HAVE_INT64 macro being defined
which is not directly related to size_t. This might result in errors in
some platforms. This change modifies the check to use the macros
SIZE_MAX and UINT_MAX instead making the code more robust.
Document the preconditions on the input and output buffers for
the PKCS1 decryption functions
- mbedtls_rsa_pkcs1_decrypt,
- mbedtls_rsa_rsaes_pkcs1_v15_decrypt
- mbedtls_rsa_rsaes_oaep_decrypt
As noted in #557, several functions use 'index' resp. 'time'
as parameter names in their declaration and/or definition, causing name
conflicts with the functions in the C standard library of the same
name some compilers warn about.
This commit renames the arguments accordingly.
The AES sample application programs/aes/aescrypt2 could miss zeroizing
the stack-based key buffer in case of an error during operation. This
commit fixes this and also clears another temporary buffer as well as
all command line arguments (one of which might be the key) before exit.
The AES sample application programs/aes/crypt_and_hash could miss
zeroizing the stack-based key buffer in case of an error during
operation. This commit fixes this and also clears all command line
arguments (one of which might be the key) before exit.
The check uses grep, not config.pl, on the x509 headers - not where it should
be configured - config.h. grep syntax isn't very portable. Without config.pl
it's quite hard to do this check properly so removing this check.
The X509 test suite assumes that MBEDTLS_X509_MAX_INTERMEDIATE_CA is below the
hardcoded threshold 20 used in the long certificate chain generating script
tests/data_files/dir-max/long.sh. This commit adds a compile-time check for
that.
Some tests in ssl-opt.sh assumes the value 8 for the maximal number
MBEDTLS_X509_MAX_INTERMEDIATE_CA of intermediate CA's. This commit adds a check
before conducting the respective tests.
If we didn't walk the whole chain, then there may be any kind of errors in the
part of the chain we didn't check, so setting all flags looks like the safe
thing to do.
Inspired by test code provided by Nicholas Wilson in PR #351.
The test will fail if someone sets MAX_INTERMEDIATE_CA to a value larger than
18 (default is 8), which is hopefully unlikely and can easily be fixed by
running long.sh again with a larger value if it ever happens.
Current behaviour is suboptimal as flags are not set, but currently the goal
is only to document/test existing behaviour.
