nfr_crypto_aead AES GCM nonce size question

[Valerii_Ie]

Hi, 
I'm trying to implement radio transfer protocol with symmetric encryption and auth - AES GCM. The main requirements are low overhead in packet added to encrypted payload and relatively high security.
I'm not security expert and trying to compare available in NRF SDK mbedtls backend implementation with data described in RFCs. 
What i found in nfr_crypto_aead.h 

/**@brief Integrated encryption / decryption function.

 *

 * @param[in]  p_context        Context object. Must be initialized before the call.

 * @param[in]  operation        Parameter indicating whether an encrypt (NRF_CRYPTO_ENCRYPT) or

 *                              a decrypt (NRF_CRYPTO_DECRYPT) operation shall be performed.

 * @param[in]  p_nonce          Pointer to nonce. For nonce_size == 0 p_nonce can be NULL.

 * @param[in]  nonce_size       Nonce byte size. Valid values for supported modes:

 *                                - CCM         [7 ... 13]

 *                                - CCM*        [13]

 *                                - EAX         nonce size can be any length

 *                                - GCM         nonce size can be any length

 *                                - CHACHA-POLY [12]

 * @param[in]  p_adata          Pointer to additional authenticated data (adata).

 * @param[in]  adata_size       Length of additional authenticated data in bytes.

 *                              For CHACHA-POLY mode must be > 0.

 * @param[in]  p_data_in        Pointer to the input data buffer for encryption or decryption.

 * @param[in]  data_in_size     Length of the data in p_data_in buffer in bytes. Size of the

 *                              p_data_out buffer must not be smaller than this value.

 *                              When selecting CC310 backend data_in_size value shall be limited

 *                              to 65535 bytes. Data out buffer must be at least the same length.

 * @param[out] p_data_out       Pointer to the output buffer where encrypted or decrypted data

 *                              will be stored. Must be at least 'data_in_size' bytes wide.

 *                                - GCM: On encryption, the p_data_out buffer can be the same as

 *                                       the p_data_in buffer.

 *                                       On decryption, the p_data_out buffer cannot be the same

 *                                       as p_data_in buffer. If buffers overlap, the p_data_out

 *                                       buffer must trail at least 8 bytes behind the p_data_in

 *                                       buffer.

 * @param[out] p_mac            Pointer to the MAC result buffer. Fo mac_size == 0 p_mac can be NULL.

 * @param[in]  mac_size         MAC byte size. Valid values for supported modes:

 *                                -CCM          [4, 6, 8, 10, 12, 14, 16]

 *                                -CCM*         [0, 4, 8, 16]

 *                                -EAX          [1 ... 16]

 *                                -GCM          [4 ... 16]

 *                                -CHACHA-POLY  [16]

 *

 * @retval  NRF_SUCCESS  Message was successfully encrypted.

 */

ret_code_t nrf_crypto_aead_crypt( ...



So I tried to tune AES example with next params: 
mac_size: 4B
nonce_size: 0B

The operation fails with next output

Error = 0x8517

Invalid combination of input parameters

The reason is 0 nonce. 

nonce_size       Nonce byte size. Valid values for supported modes:
*                                - GCM         nonce size can be any length

I suggest nonce can be length >0

What the security effect making nonce less than 12B (as RFC recommends)?

[Vidar Berg]

Hello,

It is a bit surprising to me that it says it can have any length, but I'm not a crypto expert either. Maybe there are cases where a short nonce would be acceptable. Either way, I found this publication from NIST explaining why nonces should not be reused: "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC"

Excerpt from from chapter 8 of the publication:

So think what you need to determine is if you can keep a < 2⁻³¹ probability for nonce collisions if you reduce the nonce to less than 12 bytes.

I guess you may have constraints with regards to what crypto algorithms you can use. Otherwise, I think AES CCM could have been a good alternative to allow everything to be offloaded to HW. It's the same encryption used in BLE, and there is also a demo showing how it can be used with ESB here: https://github.com/NordicPlayground/nrf52-esb-ccm-example.

Best regards,

Vidar

[Valerii_Ie]

Hi Vidar, thanks! 
So nonce should be 12bytes or some procedure of regular rekeying should be established to keep communication secure enough. 
I also found https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf
What interesting i found there 

Another useful property is that it accepts initialization vectors of 
arbitrary length, which makes it easier for applications to meet the 
requirement that all IVs be distinct. In many situations in which 
authenticated encryption is needed, there is a data element that could 
be used as a nonce, or as a part of a nonce, except that the length of 
the element(s) may exceed the block size of the cipher. In GCM, 
a nonce of any size can be used as the IV.