lib/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-07-29 11:41:15 +03:00
Code Activity

Suggest strategy for intra-crypto dependencies

Browse Source 
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit is contained in:
Manuel Pégourié-Gonnard
2022-07-20 11:46:49 +02:00
parent d82a9edc63
commit bdc8fd630a
1 changed files with 21 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/architecture/psa-migration/strategy.md
View File

@ -281,16 +281,25 @@ crypto modules have similar issues, for example RSA PKCS#1 v2.1 calls
Regarding PK, X.509, and TLS, this is mostly achieved with only a few gaps. Regarding PK, X.509, and TLS, this is mostly achieved with only a few gaps.
(The strategy was outlined in the previous section.) (The strategy was outlined in the previous section.)
Regarding libmbedcrypto, including the PSA Crypto core, this has not been Regarding libmbedcrypto, outside of the RNG subsystem, for modules that
studied yet. For dependencies outside the PSA Crypto code (such as RSA currently depend on other legacy crypto modules, this can be achieved without
PKCS#1 v2.1 depending on MD), it should be checked whether this can be backwards compatibility issues, by using the software implementation if
achieved without backwards compatibility issues (currently applications can available, and "falling back" to PSA only if it's not. The compile-time
call `mbedtls_rsa_xxx()` functions without calling `psa_crypto_init()` first), dependency changes from the current one (say, `MD_C` or `AES_C`) to "the
otherwise a new compile-time option might be needed. For dependencies in the previous dependency OR PSA Crypto with needed algorithms". When building
PSA Crypto core, splitting `psa_crypto_init()` might be a topic (which might without software implementation, users need to call `psa_crypto_init()` before
also help for dependencies outside the core), with likely questions about calling any function from these modules. This condition does constitute a
ordering (can we initialize drivers before the RNG or do some drivers expect a break of backwards compability, as it was previously impossible to build in
working RNG?) and trying to avoid circular dependencies. those configurations, and in configurations were the build was possible,
application code keeps working unchanged. An incomplete example of applying
this strategy, for RSA PKCS#1 v2.1, is here:
<https://github.com/mpg/mbedtls/pull/4>.
There is a problem with the modules used for the PSA RNG, as currently the RNG
is initialized before drivers and the key store. This part will need further
study, but in the meantime we can proceed with everything that's not the
entropy module of one of the DRBG modules, and that does not depend on one of
those modules.
**Strategy for step 2:** **Strategy for step 2:**
@ -302,8 +311,8 @@ compiled in (such as `rsa.c`).
It is suggested that, as a temporary solution until we clean this up It is suggested that, as a temporary solution until we clean this up
later when removing the legacy API including its identifiers (G4), we may later when removing the legacy API including its identifiers (G4), we may
occasionally use ad-hoc internal functions, such as the one introduced by PR occasionally use ad-hoc internal functions, such as the ones introduced by PR
6065 in `library/md_internal.h`. 6065 in `library/hash_info.[ch]`.
An alternative would be to have two different code paths depending on whether An alternative would be to have two different code paths depending on whether
`MBEDTLS_PSA_CRYPTO_C` is defined or not. However this is not great for `MBEDTLS_PSA_CRYPTO_C` is defined or not. However this is not great for