This is an external function, so in the absence of link-time
optimisation (LTO) the compiler can't know anything about it and has to
call it the number of times it's called in the source code.
This only matters for pk_ec, but change pk_rsa as well for the sake of
uniformity.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
According to the TLS 1.3 standard the CCS records must be unencrypted.
When a record is not encrypted the counter, used in the dynamic IV
creation, is not incremented.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
Trusting the caller to perform the appropriate check is both risky, and
a bit user-unfriendly. Returning NULL on error seems both safer
(dereferencing a NULL pointer is more likely to result in a clean crash,
while mis-casting a pointer might have deeper, less predictable
consequences) and friendlier (the caller can just check the return
value for NULL, which is a common idiom).
Only add that as an additional way of using the function, for the sake
of backwards compatibility. Calls where we know the type of the context
for sure (for example because we just set it up) were legal and safe, so
they should remain legal without checking the result for NULL, which
would be redundant.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous wording "ensure it holds an XXX" context did not mean
anything without looking at the source.
Looking at the source, the criterion is:
- for mbedtls_pk_rsa(), that the info structure uses rsa_alloc_wrap;
- for mbedtls_pk_ec(), that it uses eckey_alloc_wrap or
ecdsa_alloc_wrap, since mbedtls_ecdsa_context is a typedef for
mbedtls_ecp_keypair. (Note that our test code uses mbedtls_pk_ec() on
contexts of type MBEDTLS_PK_ECDSA.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The abi_check script has common false positives. Document the intent of each
family of checks and typical cases of false positives that can be overridden.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Promise that we will try to keep backward compatibility with basic driver
usage, but not with more experimental aspects.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Promise that we will keep supporting existing key store formats, at least
until a major version comes along.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This was intended as experimental, and we've been saying for a long time
that it's superseded by the "unified driver interface", but we hadn't
documented that inside the Mbed TLS source code. So announce it as
deprecated.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Certain numerical values are written to the key store. Changing those
numerical values would break the backward compatibility of stored keys. Add
a note to the affected types. Add comments near the definitions of affected
values.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Those are adaptations of the already existing
TLS 1.2 tests. It is not really possible to just
remove the TLS 1.2 dependency of the existing tests
because of the following:
. in TLS 1.3 the ciphersuite selection on server
side is not related to the server certificate
. for tests involving OpenSSL the OpenSSL command line
as to be adapted to TLS 1.3
. server authentication is mandatory in TLS 1.3
. a key with KeyEncipherment and not DigitalSignature
usage is never acceptable
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Add one RSA PSS signature algorithm to the
test list of signature algorithms. This allows
certificate chains exposing an RSA key with
signatures using SHA-1 to be used in tests
where an TLS 1.3 handshake is performed.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In asn1_write tests, when there's a parsing function corresponding to the
write function, call it and check that it can parse what we wrote.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
