Explain how MBEDTLS_CTR_DRBG_ENTROPY_LEN is set next to the security
strength statement, rather than giving a partial explanation (current
setting only) in the documentation of MBEDTLS_CTR_DRBG_ENTROPY_LEN.
NIST and many other sources call it a "personalization string", and
certainly not "device-specific identifiers" which is actually somewhat
misleading since this is just one of many things that might go into a
personalization string.
Improve the formatting and writing of the documentation based on what
had been done for CTR_DRBG.
Document the maximum size and nullability of some buffer parameters.
Document that a derivation function is used.
Document the security strength of the DRBG depending on the
compile-time configuration and how it is set up. In particular,
document how the nonce specified in SP 800-90A is set.
Mention how to link the ctr_drbg module with the entropy module.
* State explicit whether several numbers are in bits or bytes.
* Clarify whether buffer pointer parameters can be NULL.
* Explain the value of constants that are dependent on the configuration.
* origin/pr/2843: (26 commits)
Make hyperlink a hyperlink in every markdown flavor
Update the crypto submodule to be the same as development
Document test case descriptions
Restore MBEDTLS_TEST_OUTCOME_FILE after test_default_out_of_box
ssl-opt.sh: Fix some test case descriptions
Reject non-ASCII characters in test case descriptions
Process input files as binary
Factor description-checking code into a common function
Fix cosmetic error in warnings
Fix regex matching run_test calls in ssl-opt.sh
all.sh: run check-test-cases.py
Better information messages for quick checks
Fix configuration short name in key-exchanges.pl
Make test case descriptions unique
New test script check-test-cases.py
Document the test outcome file
Create infrastructure for architecture documents in Markdown
all.sh --outcome-file creates an outcome file
Set meaningful test configuration names when running tests
ssl-opt: remove semicolons from test case descriptions
...
Add invasive checks that peek at the stored persistent data after some
successful import, generation or destruction operations and after
reinitialization to ensure that the persistent data in storage has the
expected content.
Add a parameter to the p_validate_slot_number method to allow the
driver to modify the persistent data.
With the current structure of the core, the persistent data is already
updated. All it took was adding a way to modify it.
When registering a key in a secure element, go through the transaction
mechanism. This makes the code simpler, at the expense of a few extra
storage operations. Given that registering a key is typically very
rare over the lifetime of a device, this is an acceptable loss.
Drivers must now have a p_validate_slot_number method, otherwise
registering a key is not possible. This reduces the risk that due to a
mistake during the integration of a device, an application might claim
a slot in a way that is not supported by the driver.
Since components run in the main process, unsetting
MBEDTLS_TEST_OUTCOME_FILE unset it in subsequent components as well.
To avoid this, save and restore the value.
(Making each component run in a subshell would be a better solution,
but it would be a much bigger change.)
In ssl_parse_hello_verify_request, we read 3 bytes (version and cookie
length) without checking that there are that many bytes left in
ssl->in_msg. This could potentially read from memory outside of the
ssl->receive buffer (which would be a remotely exploitable
crash).
In ssl_parse_hello_verify_request, we print cookie_len bytes without
checking that there are that many bytes left in ssl->in_msg. This
could potentially log data outside the received message (not a big
deal) and could potentially read from memory outside of the receive
buffer (which would be a remotely exploitable crash).
Define a vendor-range within the the private use ranges in the IANA
registry. Provide recommendations for how to support vendor-defined
curves and groups.
