MBEDTLS_HAVE_TIME is documented as: "System has time.h and time()."
If that is not defined, do not attempt to include time.h.
A particular problem is platform-time.h, which should only be included if
MBEDTLS_HAVE_TIME is defined, which makes everything messier. Maybe it
should be refactored to have the check inside the header.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Extend mbedtls_ssl_set_hs_own_cert() to reset handshake cert list
if cert provided is null. Previously, mbedtls_ssl_set_hs_own_cert()
only provided a way to append to the handshake certificate list,
without providing a way to replace the handshake certificate list.
Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
Perform the following optimizations:
- fix used flags for conditional compilation
- remove redundant N variable
- move loop used to generate valid k value to helper function
- fix initial value of status
- fix comments
Signed-off-by: Przemyslaw Stekiel <przemyslaw.stekiel@mobica.com>
Mention that TLS 1.3 is supported, in addition to (D)TLS 1.2.
Improve and clarify the documentation. In particular, emphasise that the
minor version numbers are the internal numbers which are off by one from the
human numbers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Same intended semantics, no casts.
Limitation: this doesn't work on architectures where
sizeof(uintptr_t) < sizeof(void*), which is somewhat weird but possible if
pointers contain redundant information.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The user data is typically a pointer to a data structure or a handle which
may no longer be valid after the session is restored. If the user data needs
to be preserved, let the application do it. This way, it is a conscious
decision for the application to save/restore either the pointer/handle
itself or the object it refers to.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In structure types that are passed to user callbacks, add a field that the
library won't ever care about. The application can use this field to either
identify an instance of the structure with a handle, or store a pointer to
extra data.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Provide an additional pair of #defines, MBEDTLS_SHA256_USE_A64_CRYPTO_IF_PRESENT
and MBEDTLS_SHA256_USE_A64_CRYPTO_ONLY. At most one of them may be
specified. If used, it is necessary to compile with -march=armv8-a+crypto.
The MBEDTLS_SHA256_PROCESS_ALT and MBEDTLS_SHA256_ALT mechanisms
continue to work, and are mutually exclusive with A64_CRYPTO.
There should be minimal code size impact if no A64_CRYPTO option is set.
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
These fields need to be enabled for 1.3 even if MBEDTLS_USE_PSA_CRYPTO isn't (1.3 should always use PSA).
Signed-off-by: Przemyslaw Stekiel <przemyslaw.stekiel@mobica.com>
Initially this function was doing something because the output format of
psa_export_public() didn't match the ECPoint format that TLS wants.
Then it became a no-op then the output format of psa_export_public()
changed, but it made sense to still keep the function in case the format
changed again. Now that the PSA Crypto API has reached 1.0 status, this
is unlikely to happen, so the no-op function is no longer useful.
Removing it de-clutters the code a bit; while at it we can remove a
temporary stack buffer (that was up to 133 bytes).
It's OK to remove this function even if it was declared in a public
header, as there's a warning at the top of the file saying it's not part
of the public API.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Relying on a PSA_VENDOR macro is not ideal, since the standard doesn't
guarantee this macro exists, but OTOH relying on
MBEDTLS_ECP_DP_xxx_ENABLED was even less ideal, so I believe this is
still an improvement.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We had ECC then PK then ECC, move PK to the end, now all ECC things are
together. (The comments suggest that was the intention all along.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
