As before with wanting to compare revisions across different
repositories, the ability to select the crypto submodule from a
different repository is useful.
We may wish to compare ABI/API between Mbed TLS and Mbed Crypto,
which will cause issues as not all .so files are shared. Only
compare .so files which both libraries have.
As going forward we will have Crypto in a submodule, we will need to
be able to check ABI compatibility between versions using different
submodule versions. For TLS versions that support the submodule, we
will always build using the submodule.
If the Crypto submodule is used, libmbedcrypto.so is not in the main
library folder, but in crypto/library instead. Given this, the script
searches for *.so files and notes their path, in order to create the
dumps correctly.
By default abi-compliance-checker will check the entire ABI/API.
There are internal identifiers that we do not promise compatibility
for, so we want the ability to skip them when checking the ABI/API.
Without a "--detach" option, git worktree will refuse to checkout a branch
that's already checked out. This makes the abi_check.py script not very
useful for checking the currently checked out branch, as git will error
that the branch is already checked out. Add the "--detach" option to check
out the new temporary worktree in detached head mode. This is acceptable
because we aren't planning on working on the branch and just want a
checkout to do ABI checking from.
Run ssl-opt.sh on x86_32 with ASan. This may detect bugs that only
show up on 32-bit platforms, for example due to size_t overflow.
For this component, turn off some memory management features that are
not useful, potentially slow, and may reduce ASan's effectiveness at
catching buffer overflows.
Remove the ssl_cert_test sample application, as it uses
hardcoded certificates that moved, and is redundant with the x509
tests and applications. Fixes#1905.
This is what we do in Jenkins, so it only makes sense to do it here as well.
This will avoid random failures for no other reason than the proxy was
dropping all the messages due to an unlucky PRNG seed.
See https://docs.travis-ci.com/user/environment-variables/ for syntax
* origin/pr/2470:
Silence pylint
check-files.py: readability improvement in permission check
check-files.py: use class fields for class-wide constants
check-files.py: clean up class structure
abi_check.py: Document more methods
check-files.py: document some classes and methods
Fix pylint errors going uncaught
Call pylint3, not pylint
New, documented pylint configuration
* origin/pr/2364:
Increase okm_hex buffer to contain null character
Minor modifications to hkdf test
Add explanation for okm_string size
Update ChangeLog
Reduce buffer size of okm
Reduce Stack usage of hkdf test function
* restricted/pr/553:
Fix mbedtls_ecdh_get_params with new ECDH context
Add changelog entry for mbedtls_ecdh_get_params robustness
Fix ecdh_get_params with mismatching group
Add test case for ecdh_get_params with mismatching group
Add test case for ecdh_calc_secret
Fix typo in documentation
It was failing to set the key in the ENCRYPT direction before encrypting.
This just happened to work for GCM and CCM.
After re-encrypting, compare the length to the expected ciphertext
length not the plaintext length. Again this just happens to work for
GCM and CCM since they do not perform any kind of padding.
We were still reusing the internal HMAC-DRBG of the deterministic ECDSA
for blinding. This meant that with cryptographically low likelyhood the
result was not the same signature as the one the deterministic ECDSA
algorithm has to produce (however it is still a valid ECDSA signature).
To correct this we seed a second HMAC-DRBG with the same seed to restore
correct behavior. We also apply a label to avoid reusing the bits of the
ephemeral key for a different purpose and reduce the chance that they
leak.
This workaround can't be implemented in the restartable case without
penalising the case where external RNG is available or completely
defeating the purpose of the restartable feature, therefore in this case
the small chance of incorrect behavior remains.
Alternative implementations are often hardware accelerators and might
not need an RNG for blinding. But if they do, then we make them misuse
the RNG in the deterministic case.
There are several way around this:
- Exposing a lower level function for replacement. This would be the
optimal solution, but litters the API and is not backward compatible.
- Introducing a new compile time option for replacing the deterministic
function. This would mostly cover the same code as
MBEDTLS_ECDSA_DETERMINISTIC and would be yet another compile time flag.
- Reusing the existing MBEDTLS_ECDSA_DETERMINISTIC macro. This changes
the algorithm used by the PK layer from deterministic to randomised if
the alternative implementation is present.
This commit implements the third option. This is a temporary solution
and should be fixed at the next device driver API change.
`mbedtls_ecdsa_sign_det` reuses the internal HMAC-DRBG instance to
implement blinding. The advantage of this is that the algorithm is
deterministic too, not just the resulting signature. The drawback is
that the blinding is always the same for the same key and message.
This diminishes the efficiency of blinding and leaks information about
the private key.
A function that takes external randomness fixes this weakness.