The cryptographic API should not be related to whether or not
there is alternative implementation. The API should be same for regular
implementation, and for alternative implementation, so it is defined
outside of the XXX_ALT precompilation check in the cryptographic API header
Minor documentation improvements:
*Standardized file brief description.
*Separated return statements.
*Reordered tags within documentation blocks so that params and returns are last in block.
*Applied previous function documentation improvements to depracated functions.
In 2.7.0, we replaced a number of MD functions with deprecated inline
versions. This causes ABI compatibility issues, as the functions are no
longer guaranteed to be callable when built into a shared library.
Instead, deprecate the functions without also inlining them, to help
maintain ABI backwards compatibility.
- Rephrase file/function/parameter/enum/define/error descriptions into full and clear sentences.
- Make sure to adhere to the Arm writing guidelines.
- Fix missing/incorrect Doxygen tags.
- Standardize terminology used within the file.
GitHub PR: #1322
MD2, MD4, MD5, DES and SHA-1 are considered weak and their use
constitutes a security risk. If possible, we recommend avoiding
dependencies on them, and considering stronger message digests and
ciphers instead.
The _ext suffix suggests "new arguments", but the new functions have
the same arguments. Use _ret instead, to convey that the difference is
that the new functions return a value.
The following function calls are being deprecated to introduce int
return values.
* mbedtls_sha1()
* mbedtls_sha1_starts()
* mbedtls_sha1_update()
* mbedtls_sha1_finish()
* mbedtls_sha1_process()
The return codes can be used to return error values. This is important
when using hardware accelerators.
