Restore MBEDTLS_PK_PARSE_C as it was removed by mistake.
Fix module name in added warnings.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Test coverage not there yet, as the entire test_suite_pkcs1_v21 is
skipped so far - dependencies to be adjusted in a future commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is mostly:
sed -i 's/mbedtls_psa_translate_md/mbedtls_hash_info_psa_from_md/' \
library/*.c tests/suites/*.function
This should be good for code size as the old inline function was used
from 10 translation units inside the library, so we have 10 copies at
least.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Trying to compile MD_C without any of the hash modules would result in a
bunch of unused parameter warning (hence errors in -Werror builds).
We could silence those warnings by casting the parameters to void, but
still, compiling the module in such a configuration would mean all of
its functions are useless (always returning an error).
Seems better to just document the dependency.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Depending only of our software implementation was too strict. The
function can be useful when only the PSA implementation is available,
since oftentimes the algorithm will still be expressed as an md_type for
legacy reasons.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous commit made the PKCS#1v1.5 part of rsa.c independent from
md.c, but there was still a dependency in the corresponding part in PSA.
This commit removes it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is a step towards building with RSA PKCS#1v1.5 without MD.
Also loosen guards around oid data: the OID definitions clearly don't
depend on our software implementation.
We could simply have no dependency as this is just data. But for the
sake of code size, let's have some guards so that people who don't use
MD5, SHA1 or RIPEMD160 don't have to pay the price for them.
Note: this is used for RSA (PKCS#v1.5) signatures among other things, an
area that is not influenced by USE_PSA, so the guards should not depend
on it either.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It was initially motivated by the fact that the PSA Crypto APIs
themselves were not stable. In the meantime, PSA Crypto has reached
1.0.0 so this no longer applies.
If we want user to be able to fully benefit from PSA in order to
isolate long-term secrets, they need to be able to use the new APIs with
confidence. There is no reason to think those APIs are any more likely
to change than any of our other APIs, and if they do, we'll follow the
normal process (deprecated in favour of a new variant).
For reference, the APIs in question are:
mbedtls_pk_setup_opaque() // to use PSA-held ECDSA/RSA keys in TLS
mbedtls_ssl_conf_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_ssl_set_hs_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_cipher_setup_psa() (deprecated in 3.2)
mbedtls_pk_wrap_as_opaque() (documented internal, to be removed in 3.2)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
