CC310 crypto library ROM usage size

[jacksong]

Hi, all

I tested nRF5_SDK_17.0 crypto library example with nRF52840, and compile information:

1>test crypto ECDH and ECDSA with enable CC310 :

==============================================================================

Total RO Size (Code + RO Data) 59692 ( 58.29kB)
Total RW Size (RW Data + ZI Data) 36072 ( 35.23kB)
Total ROM Size (Code + RO Data + RW Data) 59852 ( 58.45kB)

==============================================================================

 2>and remove crypto test but keep print log:

==============================================================================

Total RO Size (Code + RO Data) 24976 ( 24.39kB)
Total RW Size (RW Data + ZI Data) 39888 ( 38.95kB)
Total ROM Size (Code + RO Data + RW Data) 25120 ( 24.53kB)

==============================================================================

you can see CC310 crypto consume about 34K flash, that's too big to us

in my opinion, crypto library just some control code for register and the compute is implemented with hardware.

is there any misunderstand, and method?

[Vidar Berg]

Hello,

Not all of the supported crypto routines are fully HW accelerated, which is one of the reasons for why the runtime library is bigger than what you had expected. However, as you may have seen, we do have a minimal size reduced variant of this runtime library intended for bootloader applications. Maybe you can use that library instead? It has support for the following curves:

source: ECC - Elliptic Curve Cryptography

[jacksong]

thanks for your reply, and , I tried to migrate to CC310BL, it really reduced the rom consume!

==============================================================================

Total RO Size (Code + RO Data) 35192 ( 34.37kB)
Total RW Size (RW Data + ZI Data) 40144 ( 39.20kB)
Total ROM Size (Code + RO Data + RW Data) 35336 ( 34.51kB)

==============================================================================

However, the bad news is that CC310BL does not support "ecc key pair generate " , it's a important feature to our application, any more suggestion?

clue from nRF5_SDK_17.0.2_d674dde\components\libraries\crypto\backend\cc310_bl\cc310_bl_backend_ecc.h #L111:

#define NRF_CRYPTO_ECC_SECP256R1_ENABLED 1

typedef struct
{
    nrf_crypto_internal_ecc_key_header_t header;        /**< @internal @brief Common ECC key header */
    nrf_cc310_bl_ecc_public_key_secp256r1_t public_key; /**< @internal @brief CC310_BL specific key representation */
} nrf_crypto_backend_secp256r1_public_key_t;

/** @internal See @ref nrf_crypto_backend_ecc_public_key_from_raw_fn_t.
*/
ret_code_t nrf_crypto_backend_secp256r1_public_key_from_raw(
    void          * p_public_key,
    uint8_t const * p_raw_data);

/** @internal See @ref nrf_crypto_backend_ecc_public_key_to_raw_fn_t.
*/
ret_code_t nrf_crypto_backend_secp256r1_public_key_to_raw(
    void const * p_public_key,
    uint8_t    * p_raw_data);

// Dummy and empty definitions for unused symbols
#define nrf_crypto_backend_secp256r1_key_pair_generate    NULL
#define nrf_crypto_backend_secp256r1_public_key_calculate NULL
#define nrf_crypto_backend_secp256r1_private_key_from_raw NULL
#define nrf_crypto_backend_secp256r1_private_key_to_raw   NULL
#define nrf_crypto_backend_secp256r1_private_key_free     NULL
#define nrf_crypto_backend_secp256r1_public_key_free      NULL

#define NRF_CRYPTO_BACKEND_SECP256R1_KEY_PAIR_GENERATE_CONTEXT_SIZE    0
#define NRF_CRYPTO_BACKEND_SECP256R1_PUBLIC_KEY_CALCULATE_CONTEXT_SIZE 0

typedef uint32_t nrf_crypto_backend_secp256r1_private_key_t;
typedef uint32_t nrf_crypto_backend_secp256r1_key_pair_generate_context_t;
typedef uint32_t nrf_crypto_backend_secp256r1_public_key_calculate_context_t;

#endif // NRF_MODULE_ENABLED(NRF_CRYPTO_BACKEND_CC310_BL_ECC_SECP256R1)

[Vidar Berg]

Sorry, I didn't think to check if there were other limitations with this library build, I just assumed ECC was fully supported. As the "ecc key pair generate" function had been removed, I'm afraid you will have to use the regular runtime library. Alternatively, see if you can reduce the memory footprint by using Oberon, uECC, etc without the cryptocell (at the cost of more CPU processing time).

[jacksong]

emmm, it's OK.

the aim we try to apply CC310 is to optimize process time, the software scheme is much slower

and now, it seems that we have to give up using CC310_BL to reduce ROM.