Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
Two macros are also defined in headers in the PSA Compliance test suite, so
the test suite would fail to build if we changed the definitions. Preserve
those definitions. Technically this is a bug in the test suite, since having
extra spaces (or even a completely different constant expression with the
same value) would still be compliant. Bug reported as
https://github.com/ARM-software/psa-arch-tests/issues/337
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
For PSA error code definitions, the specific expansion is mandated by the
PSA Status code specification and the PSA Crypto API specification. In
particular, there must not be a space between (psa_status_t) and the
numerical value (whereas K&R would put a space).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Using proper configuration options (i.e. MBEDTLS_SHA224_C and
MBEDTLS_SHA256_C) it is now possible to build SHA224 and SHA256
independently from each other.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Using proper configuration options (i.e. MBEDTLS_SHA384_C and
MBEDTLS_SHA512_C) it is now possible to build SHA384 and SHA512
independently from each other.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
This is not new, it had always been the case, just not documented.
Pointed out by depends.py pkalgs (again, now that restartable is part of
full).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
muladd() (restartable or not) is only available when at least one short
weirstrass curve is enabled.
Found by depends.py curves (now that restartable is part of full).
Also, document that restartable only work for short weierstrass curves
(actually unrelated, but this made me think of that).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is only the beginning:
- some test failures in test_suite_pk, test_suite_x509 and ssl-opt.sh
will be fixed in the next few commits;
- then the interactions between those options will be documented and
tested.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It might not be obvious that this option goes beyond adding new
functions, but also automagically modifies the behaviour of TLS
in some circumstances. Moreover, the exact modifications and
circumstances were not documented anywhere outside the ChangeLog.
Fix that.
While at it, adjust the test that checks no restartable behaviour with
other key exchanges, to use a key exchange that allows cert-based client
authentication so that we can check that this is not restartable either.
We don't have any automated test checking that the server is never
affected. That would require adding an ec_max_ops command-line option to
ssl_server2 that never has any effect, just to check that it indeed
doesn't. I'm not sure that's worth it. I tested manually and could
confirm that the server never has restartable behaviour, even for the
parts that are shared between client and server such as cert chain
verification.
Note (from re-reading the code): all restartable behaviour is controlled
by the flag ssl->handshake->ecrs_enabled which is only client-side with
the ECDHE-ECDSA key exchange (TLS 1.2).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- disable reuse of max_early_data_size.
- make conf_early_data available for server.
- various comment issues
Signed-off-by: Jerry Yu <jerry.h.yu@arm.com>
Warns about the removal of the legacy DTLS Connection ID feature in a future version of Mbed TLS.
Signed-off-by: Hannes Tschofenig <hannes.tschofenig@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Added deprecated keyword to MBEDTLS_SSL_DTLS_CONNECTION_ID_COMPAT
Signed-off-by: Hannes Tschofenig <hannes.tschofenig@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Having multiple definitions was cumbersome, and meant we might forget the
definition when adding an inline definition to a file that didn't have one
before (as I did when I added an inline definition in common.h).
Resolves#6649.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Eventually we want it to be enabled by default
when TLS 1.3 is enabled but currently the
feature is on development thus it should not be
enabled by default.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define the ALLOW_PSK_RESUMPTION and ALLOW_PSK_EPHEMERAL_RESUMPTION
to the key exchange mode EXCHANGE_MODE_PSK and
EXCHANGE_MODE_PSK_EPHEMERAL to facilate later check.
Since they are 1( 1u<<0 ) and 4( 1u<<2 ), so define
ALLOW_EARLY_DATA to 8( 1u<<3 ).
Signed-off-by: Xiaokang Qian <xiaokang.qian@arm.com>
Since they're part of the public API (even if only through a few functions),
they should be documented.
I deliberately skipped documenting how to configure the size of the type.
Right now, MBEDTLS_HAVE_INT32 and MBEDTLS_HAVE_INT64 have no Doxygen
documentation, so it's ambiguous whether they're part of the public API.
Resolving this ambiguity is out of scope of my current work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Additionally use psa_get_and_lock_key_slot_with_policy() to obtain key.
This requires making this function public. This will have to be solved while adding driver dipatch for EC-JPAKE.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Add fields to mbedtls_ssl_context
Add write early data indication function
Add check whether write early data indication
Add early data option to ssl_client2
Add test cases for early data
Signed-off-by: Xiaokang Qian <xiaokang.qian@arm.com>
