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.