pk: return PK_USE_PSA_EC_DATA to pk.h
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This commit is contained in:
parent
2e0275d2a1
commit
0f6d565d26
2 changed files with 25 additions and 24 deletions
|
@ -208,32 +208,11 @@
|
|||
#define MBEDTLS_PK_PARSE_C
|
||||
#endif
|
||||
|
||||
/* Internal helper to define which fields in the pk_context structure should
|
||||
* be used for EC keys: legacy ecp_keypair or the raw (PSA friendly) format.
|
||||
* It should be noticed that this only affect how data is stored, not which
|
||||
* functions are used for various operations. The overall picture looks like
|
||||
* this:
|
||||
* - if USE_PSA is not defined and ECP_C is then use ecp_keypair data structure
|
||||
* and legacy functions
|
||||
* - if USE_PSA is defined and
|
||||
* - if ECP_C then use ecp_keypair structure, convert data to a PSA friendly
|
||||
* format and use PSA functions
|
||||
* - if !ECP_C then use new raw data and PSA functions directly.
|
||||
*
|
||||
* The main reason for the "intermediate" (USE_PSA + ECP_C) above is that as long
|
||||
* as ECP_C is defined mbedtls_pk_ec() gives the user a read/write access to the
|
||||
* ecp_keypair structure inside the pk_context so he/she can modify it using
|
||||
* ECP functions which are not under PK module's control.
|
||||
*/
|
||||
#if defined(MBEDTLS_USE_PSA_CRYPTO) && defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY) && \
|
||||
!defined(MBEDTLS_ECP_C)
|
||||
#define MBEDTLS_PK_USE_PSA_EC_DATA
|
||||
#endif /* MBEDTLS_USE_PSA_CRYPTO && !MBEDTLS_ECP_C */
|
||||
|
||||
/* Helper symbol to state that the PK module has support for EC keys. This
|
||||
* can either be provided through the legacy ECP solution or through the
|
||||
* PSA friendly MBEDTLS_PK_USE_PSA_EC_DATA. */
|
||||
#if defined(MBEDTLS_PK_USE_PSA_EC_DATA) || defined(MBEDTLS_ECP_C)
|
||||
* PSA friendly MBEDTLS_PK_USE_PSA_EC_DATA (see pk.h for its description). */
|
||||
#if defined(MBEDTLS_ECP_C) || \
|
||||
(defined(MBEDTLS_USE_PSA_CRYPTO) && defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY))
|
||||
#define MBEDTLS_PK_HAVE_ECC_KEYS
|
||||
#endif /* MBEDTLS_PK_USE_PSA_EC_DATA || MBEDTLS_ECP_C */
|
||||
|
||||
|
|
|
@ -200,6 +200,28 @@ typedef struct mbedtls_pk_rsassa_pss_options {
|
|||
#define MBEDTLS_PK_HAVE_ECC_KEYS
|
||||
#endif /* MBEDTLS_PK_USE_PSA_EC_DATA || MBEDTLS_ECP_C */
|
||||
|
||||
/* Internal helper to define which fields in the pk_context structure below
|
||||
* should be used for EC keys: legacy ecp_keypair or the raw (PSA friendly)
|
||||
* format. It should be noticed that this only affect how data is stored, not
|
||||
* which functions are used for various operations. The overall picture looks
|
||||
* like this:
|
||||
* - if USE_PSA is not defined and ECP_C is then use ecp_keypair data structure
|
||||
* and legacy functions
|
||||
* - if USE_PSA is defined and
|
||||
* - if ECP_C then use ecp_keypair structure, convert data to a PSA friendly
|
||||
* format and use PSA functions
|
||||
* - if !ECP_C then use new raw data and PSA functions directly.
|
||||
*
|
||||
* The main reason for the "intermediate" (USE_PSA + ECP_C) above is that as long
|
||||
* as ECP_C is defined mbedtls_pk_ec() gives the user a read/write access to the
|
||||
* ecp_keypair structure inside the pk_context so he/she can modify it using
|
||||
* ECP functions which are not under PK module's control.
|
||||
*/
|
||||
#if defined(MBEDTLS_USE_PSA_CRYPTO) && defined(PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY) && \
|
||||
!defined(MBEDTLS_ECP_C)
|
||||
#define MBEDTLS_PK_USE_PSA_EC_DATA
|
||||
#endif /* MBEDTLS_USE_PSA_CRYPTO && !MBEDTLS_ECP_C */
|
||||
|
||||
/**
|
||||
* \brief Types for interfacing with the debug module
|
||||
*/
|
||||
|
|
Loading…
Reference in a new issue