Conflicts:
* `include/mbedtls/build_info.h`: a new fragment to auto-enable
`MBEDTLS_CIPHER_PADDING_PKCS7` was added in
c9f4040f7f in `development-restricted`.
In `development`, this section of the file has moved to
`include/mbedtls/config_adjust_legacy_crypto.h`.
* `library/bignum.c`: function name change in `development-restricted` vs
comment change in development. The comment change in `development` is not
really relevant, so just take the line from `development-restricted`.
This commit sets a loop_limit to omit AES-GCM-192 and AES-GCM-256
if MBEDTLS_AES_ONLY_128_BIT_KEY_LENGTH enabled.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
The configuration symbol MBEDTLS_AESNI_C requests AESNI support, but it is
ignored if the platform doesn't have AESNI. This allows keeping
MBEDTLS_AESNI_C enabled (as it is in the default build) when building for
platforms other than x86_64, or when MBEDTLS_HAVE_ASM is disabled.
To facilitate maintenance, always use the symbol MBEDTLS_AESNI_HAVE_CODE to
answer the question "can I call mbedtls_aesni_xxx functions?", rather than
repeating the check `defined(MBEDTLS_AESNI_C) && ...`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
gcm.c had a slightly different pattern for the conditional inclusion of
platform.h which didn't fit the general replacement. Simplify it manually.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some source files had code to set mbedtls_xxx aliases when
MBEDTLS_PLATFORM_C is not defined. These aliases are defined unconditionally
by mbedtls/platform.h, so these macro definitions were redundant. Remove
them.
This commit used the following code:
```
perl -i -0777 -pe 's~#if !defined\(MBEDTLS_PLATFORM_C\)\n(#define (mbedtls|MBEDTLS)_.*\n|#include <(stdarg|stddef|stdio|stdlib|string|time)\.h>\n)*#endif.*\n~~mg' $(git grep -l -F '#if !defined(MBEDTLS_PLATFORM_C)')
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These issues were flagged by Coverity as instances where a local
variable may be used prior to being initialized. Please note that
none of these changes fixes any particular bug, this is just an attempt
to add more robustness.
Signed-off-by: Leonid Rozenboim <leonid.rozenboim@oracle.com>
Move GCM's update output buffer length verification
from PSA AEAD to the built-in implementation of the GCM.
Signed-off-by: Mateusz Starzyk <mateusz.starzyk@mobica.com>
An initialization vector IV can have any number of bits between 1 and
2^64. So it should be filled to the lower 64-bit in the last step
when computing ghash.
Signed-off-by: openluopworld <luopengxq@gmail.com>
An initialization vector IV can have any number of bits between 1 and
2^64. So it should be filled to the lower 64-bit in the last step
when computing ghash.
Signed-off-by: openluopworld <luopengxq@gmail.com>
An initialization vector IV can have any number of bits between 1 and
2^64. So it should be filled to the lower 64-bit in the last step
when computing ghash.
Signed-off-by: openluopworld <luopengxq@gmail.com>
An initialization vector IV can have any number of bits between 1 and
2^64. So it should be filled to the lower 64-bit in the last step
when computing ghash.
Signed-off-by: openluopworld <luopengxq@gmail.com>
The GET macros used to write to a macro parameter, but now
they can be used to assign a value to the desired variable
rather than pass it in as an argument and have it modified
in the macro function.
Due to this MBEDTLS_BYTES_TO_U32_LE is the same as
MBEDTLS_GET_UINT32_LE and was there for replaced in the
appropriate files and removed from common.h
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
As per tests/scripts/check-names.sh, macros in
library/ header files should be prefixed with
MBEDTLS_
The macro functions in common.h where also indented
to comply with the same test
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
32-bit integer manipulation macros (big edian):
GET_UINT32_BE and PUT_UINT32_BE appear in several
files in library/.
Removes duplicate code and save vertical
space the macro has been moved to common.h.
Improves maintainability.
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
Without this parameter, it would be hard for callers to know how many bytes
of output the function wrote into the output buffer. It would be possible,
since the cumulated output must have the same length as the cumulated input,
but it would be cumbersome for the caller to keep track.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
