Memory management in nrf_crypto

It is necessary to allocate some memory for the nrf_crypto library and its backends for them to work properly. In some situations, the required memory buffers may be big, so putting it on the stack is not always a good solution.

Using the NRF_CRYPTO_ALLOCATOR configuration parameter, you can change how nrf_crypto allocates and deallocates memory. The following configuration values are possible:

• 0 - Default configuration
• 1 - User macros
• 2 - Allocating memory on the stack (alloca)
• 3 - C dynamic memory (malloc)
• 4 - SDK Memory Manager (nrf_malloc)

More details about memory consumption can be found in the description of the specific backend. See nrf_crypto backend modules. There are two backends that needs some special attention:

• nrf_cc310 backend, because of its high memory consumption.
• mbed TLS backend, because of its high memory consumption and extensive use of memory allocation and deallocation.

Memory handling in nrf_crypto is done using two macros: NRF_CRYPTO_ALLOC and NRF_CRYPTO_FREE. Additionally, NRF_CRYPTO_ALLOC_ON_STACK indicates whether memory is allocated on the stack or not.

Default configuration

In the default configuration, memory is allocated on the stack, except in two situations:

• The toolchain does not support the alloca() function. Currently, this is the case with IAR Workbench 7.80.4.
• Some of the enabled backends do not support memory allocation on the stack. Currently, this is the case with mbed TLS backend.

When allocation on the stack is not possible, then the default behavior is to use the nRF5 SDK Memory Manager.

See Allocating memory on the stack (alloca) and SDK Memory Manager (nrf_malloc).

User macros

You can create your own custom implementation of memory management used by nrf_crypto. The library must then include the nrf_crypto_allocator.h header file created by the user. The following defines must be located in the file:

• NRF_CRYPTO_ALLOC - memory allocating macro
• NRF_CRYPTO_FREE - memory freeing macro
• NRF_CRYPTO_ALLOC_ON_STACK - macro indicating whether memory is allocated on the stack

Allocating memory on the stack (alloca)

This configuration uses the standard alloca() function to allocate memory on the stack. It is not possible to use it with mbed TLS backend, because mbed TLS relies on dynamic memory allocation.

Warning

Using nrf_cc310 backend leads to extensive stack usage.

C dynamic memory (malloc)

This is the simplest configuration option using the malloc() and free() functions from stdlib.

SDK Memory Manager (nrf_malloc)

This configuration uses Memory Manager to allocate and free memory. Two versions of the manager can be used (2.0 and older). This module requires initialization and configuration before using it, so it must be done before initialization of nrf_crypto. How the module should be configured depends on the enabled backends. For details regarding memory consumption, see nrf_crypto backend modules.

Sizes of the types defined by nrf_crypto

Size of each type defined by nrf_crypto may change significantly when configuration has changed. Following tables summarize each type size depending on selected backend and its configuration.

RNG - Random Number Generation

Type	CC310	nRF HW	nRF HW with DRBG
nrf_crypto_rng_context_t	232	4	324
nrf_crypto_rng_temp_buffer_t	6112	4	4

Hash - cryptographic hash algorithms

Type	CC310	mbed TLS		Oberon		CC310_BL
		SHA-256	SHA-512	SHA-256	SHA-512
nrf_crypto_hash_context_t	248	116	224	112	208	124
nrf_crypto_hash_info_t	24

HMAC - Hash-based Message Authentication Code

Type	CC310	mbed TLS		Oberon
		SHA-256	SHA-512	SHA-256	SHA-512
nrf_crypto_hmac_context_t	384	256	492	304	592
nrf_crypto_hmac_info_t	24

AES - Advanced Encryption Standard

Type	CC310	mbed TLS
		CMAC	ECB	CBC, CBC-MAC, CFB, CTR
nrf_crypto_aes_context_t	88	80	292	308
nrf_crypto_aes_info_t	36

AEAD - Authenticated Encryption with Associated Data

Type	CC310		mbed TLS		Cifra	Oberon
	CCM, CCM*	ChaCha-Poly	CCM	GCM
nrf_crypto_aead_context_t	176	40	76	408	252	40
nrf_crypto_aead_info_t	16

ECC - Elliptic Curve Cryptography

Type	CC310	mbed TLS	µECC			Oberon			CC310_BL
			secp 192r1	secp 224r1	secp 256r1, secp 256k1	secp 256r1	Curve 25519	Ed 25519	secp 224r1	secp 256r1
nrf_crypto_ecc_key_pair_generate_context_t	844	-	-	-	-	-	-	-	-	-
nrf_crypto_ecc_public_key_calculate_context_t	-	-	-	-	-	-	-	-	-	-
nrf_crypto_ecc_private_key_t	824	20	32	36	40	40	40	72	-	-
nrf_crypto_ecc_public_key_t	896	44	56	64	72	72	40	40	64	72
nrf_crypto_ecdh_context_t	908	-	-	-	-	-	-	-	-	-
nrf_crypto_ecdsa_sign_context_t	2256	-	-	-	-	-	-	-	-	-
nrf_crypto_ecdsa_verify_context_t	1416	-	-	-	-	-	-	-	144	164
nrf_crypto_ecc_curve_info_t	12

Empty cells show types that are not used by specific backend. Such types are defined, but they have some small default content up to 4 bytes.