Driver-only hashes: RSA 2.1

[mpg]

RSA PKCS#1 v2.1 (PSS, OAEP) computes hashes internal as part of its padding schemes. Currently this is done using the MD layer, which doesn't work in builds where hash algorithms are only provided by PSA drivers.

This task is to allow RSA v2.1 code to use PSA as a fallback in builds where MD is not available (and only those builds, for compatibility reasons).

Definition of done: all tests related to RSA PKCS#1 v2.1 (in test_suite_pkcs1_v21, and the PK and PSA test suites) pass (as opposed to skip) in a build with driver-only hashes.

Depends on: #6097 (to avoid dependency issues in test suites), #6065 (general foundation).

[mpg]

Assigned to myself as I had started work on this: https://github.com/mpg/mbedtls/pull/4

[AndrzejKurek]

This task is to allow RSA v2.1 code to use PSA as a fallback in builds where MD is not available (and only those builds, for compatibility reasons).

What do you exactly mean by compatibility reasons? Won't it be transparent for the callers in terms of I/O? Requirements will be smaller than before.

Edit: Is it about the additional requirement to call psa_init?

[mpg]

Edit: Is it about the additional requirement to call psa_init?

Yes, that's it. If we went with "PSA if available, or else fall back to MD", then in the default config (which has both PSA and MD):

• today you can call RSA functions even if you didn't call psa_crypto_init() first;
• after the change RSA function would start failing if you didn't call psa_crypto_init() first. This would be a compatibility break: code that was working (and secure, and not relying on undocumented features, etc) in Mbed TLS 3.2 would break in 3.3, and users would have to change their application code. We explicitly promise that this should never happen, except for major releases (so, not until Mbed TLS 4.0 now).

So, instead we go for the backwards-looking "MD is available, or else 'fall back' to PSA". Then in configs which have both MD and PSA, things keep working as before. In configs without MD, in 3.2 you just can't build with PKCS1_V21 (check_config.h forbids it and your linker would complain) - in 3.3 you'll be able to compile but then have to call psa_crypto_init() in order for things to work. That's not a problem, but "builds but then you have to do X" is still an improvement over "does not build", and more importantly, in all configurations that did build, no change to application code is need.

These compatibility issues related to psa_crypto_init() has been a major source of pain in the migration. They're the reason we can't even start enabling MBEDTLS_USE_PSA_CRYPTO by default in 3.x (we should have done so in 3.0), even less make it non-optional as we intended at one point...

Generally speaking, navigating this transition while maintaining strict backwards compatibility is a major source of pain and I can't wait for the transition to be over, but in the meantime we have to take care of users and handle the resulting complexity as well as we can.

[mpg]

Resolved by #6141 (apparently I managed to misspell the magic word in the PR's description, so it was not closed automatically on merge).