The timing module might include time.h on its own when on
a suitable platform, even if MBEDTLS_HAVE_TIME is disabled.
Co-authored-by: Tom Cosgrove <tom.cosgrove@arm.com>
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Having such implementation might cause issues for those that
expect to have a working implementation.
Having a compile-time error is better in such case.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
A previous commit has changed the signature of mpi_mul_hlp, making the length
of the output explicit. This commit adjusts mpi_montmul() accordingly.
It also fixes a comment on the required size of the temporary value
passed to mpi_montmul() (but does not change the call-sites).
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
A previous commit has changed the signature of mpi_mul_hlp(), making
the length of the output explicit.
This commit adjusts mbedtls_mpi_mul_int() to this change.
Along the way, we make the code simpler and more secure by not calculating
the minimal limb-size of A. A previous comment indicated that this was
functionally necessary because of the implementation of mpi_mul_hlp() --
if it ever was, it isn't anymore.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
The previous commit has changed the signature of mpi_mul_hlp(),
making the length of the output explicit.
This commit adjusts the call-site in mbedtls_mpi_mul_mpi() to
this new signature.
A notable change to the multiplication strategy had to be made:
mbedtls_mpi_mul_mpi() performs a simple row-wise schoolbook
multiplication, which however was so far computed iterating
rows from top to bottom. This leads to the undesirable consequence
that as lower rows are calculated and added to the temporary
result, carry chains can grow. It is simpler and faster to
iterate from bottom to top instead, as it is guaranteed that
there will be no carry when adding the next row to the previous
temporary result: The length of the output in each iteration
can be fixed to len(B)+1.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
The helper `mpi_mul_hlp()` performs a multiply-accumulate
operation `d += s * b`, where `d,b` are MPIs and `b` is a scalar.
Previously, only the length of `s` was specified, while `d` was
assumed to be 0-terminated of unspecified length.
This was leveraged at the end of the core multiplication steps
computingg the first `limb(s)` limbs of `d + s*b`: Namely, the
routine would keep on adding the current carry to `d` until none
was left. This can, in theory, run for an arbitrarily long time
if `d` has a tail of `0xFF`s, and hence the assumption of
`0`-termination.
This solution is both fragile and insecure -- the latter because
the carry-loop depends on the result of the multiplication.
This commit changes the signature of `mpi_mul_hlp()` to receive
the length of the output buffer, which must be greater or equal
to the length of the input buffer.
It is _not_ assumed that the output buffer is strictly larger
than the input buffer -- instead, the routine will simply return
any carry that's left. This will be useful in some applications
of this function. It is the responsibility of the caller to either
size the output appropriately so that no carry will be left, or
to handle the carry.
NOTE: The commit leaves the library in a state where it cannot
be compiled since the call-sites of mpi_mul_hlp() have
not yet been adjusted. This will be done in the subsequent
commits.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
It doesn't make sense for psa_mac_verify() to return
PSA_ERROR_BUFFER_TOO_SMALL since it doesn't have an output buffer. But this
was happening when requesting the verification of an unsupported algorithm
whose output size is larger than the maximum supported MAC size, e.g.
HMAC-SHA-512 when building with only SHA-256 support. Arrange to return
PSA_ERROR_NOT_SUPPORTED instead.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In some cases, a cipher operation for an unsupported algorithm could succeed
in psa_cipher_{encrypt,decrypt}_setup() and fail only when input is actually
fed. This is not a major bug, but it has several minor downsides: fail-late
is harder to diagnose for users than fail-early; some code size can be
gained; tests that expect failure for not-supported parameters would have to
be accommodated to also accept success.
This commit at least partially addresses the issue. The only completeness
goal in this commit is to pass our full CI, which discovered that disabling
only PSA_WANT_ALG_STREAM_CIPHER or PSA_WANT_ALG_ECB_NO_PADDING (but keeping
the relevant key type) allowed cipher setup to succeed, which caused
failures in test_suite_psa_crypto_op_fail.generated in
component_test_psa_crypto_config_accel_xxx.
Changes in this commit:
* mbedtls_cipher_info_from_psa() now returns NULL for unsupported cipher
algorithms. (No change related to key types.)
* Some code that is only relevant for ECB is no longer built if
PSA_WANT_ALG_ECB_NO_PADDING is disabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the systematically generated algorithm-not-supported tests
complain when they try to start an operation and succeed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the systematically generated algorithm-not-supported tests
complain when they try to start an operation and succeed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This check can be removed as if the buffer is too small for the key, then export will fail.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
As we may offer ciphersuites not compatible with
TLS 1.3 in the ClientHello check that the selected
one is compatible with TLS 1.3.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Use the actual minimum and maximum of the minor
version to be negotiated to filter ciphersuites
to propose rather than the ones from the
configuration.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add check in ServerHello supported_versions parsing
that the length of the extension data is exactly
two.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This implies that when both TLS 1.2 and TLS 1.3
are included in the build all the TLS 1.2 tests
using the default configuration now go through
a version negotiation on the client side.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In TLS 1.3 key sharing is not restricted to key
exchange with certificate authentication. It
happens in the PSK and ephemeral key exchange
mode as well where there is no certificate
authentication.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add some MBEDTLS_SSL_PROTO_TLS1_3 guards that will
be necessary when the ClientHello writing code is
made available when MBEDTLS_SSL_PROTO_TLS1_2 is
enabled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This can only be TLS 1.2 now in this structure and when
adding support for TLS 1.2 or 1.3 version negotiation
the highest configured version can be TLS 1.3.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The TLS server code only support TLS 1.2 thus simplify
the check of the version proposed by the client.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
ssl_tls12_client.c contains only TLS 1.2 specific
code thus remove some checks on the minor version
version being MBEDTLS_SSL_MINOR_VERSION_3. No aim
for completeness, ssl_parse_server_hello() is not
reworked here for example.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In ssl_tls.c, move mbedtls_ssl_set_calc_verify_md() under the
"if defined(MBEDTLS_SSL_PROTO_TLS1_2)" pre-processor directive
as it is specific to TLS 1.2.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
ssl_set_handshake_prfs() is TLS 1.2 specific and only called
from TLS 1.2 only code thus no need to pass the TLS minor
version of the currebt session.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In TLS 1.3, a PSA ECDH private key may be created
even if MBEDTLS_SSL_USA_PSA_CRYPTO is disabled. We
must destroy this key if still referenced by an
handshake context when we free such context.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In case of TLS 1.3 and hybrid TLS 1.2/1.3, propose
PKCS1 v1.5 signatures with SHA_384/512 not only
SHA_256. There is no point in not proposing them
if they are available.
In TLS 1.3 those could be useful for certificate
signature verification.
In hybrid TLS 1.2/1.3 this allows to propose for
TLS 1.2 the same set of signature algorithms.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This has although the benefit of getting rid of a
potential integer overflow (though very unlikely
and probably harmless).
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Rename ssl_cli.c and ssl_srv.c to reflect the fact
that they are TLS 1.2 specific now. Align there new
names with the TLS 1.3 ones.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
