5
$\begingroup$

I want to use AES-GCM-SIV for authenticated encryption of messages in my protocol.

Since it is a wireless protocol I want to transmit as few bytes as possible. For successful decryption I need to transmit the nonce alongside the ciphertext and the tag and in theory this nonce is 12 bytes for AES-GCM-SIV, but I don't think this nonce needs to be fully random - unique is enough (correct me if I am wrong).

So I though 4 bytes / 32 bits may be enough to ensure uniqueness for a very very long time as the number of devices that share one key will be in the order of hundreds at most in my case. (If I wanted to be sure I could also use 5 bytes.)

My question now is what the rest of the bytes should be? Is it ok to set them to all zeroes or should I use some other constant or is there a general problem with this approach?

As a side note: What exactly are the security implications of nonce reuse for AES-GCM-SIV? My understanding is that it is "hardened" against nonce misuse, but I don't fully understand what that means in practice. The nonce must still be important or else you could just leave it constant, so at what point will this be a problem?

$\endgroup$
1
  • 2
    $\begingroup$ Reusing a nonce leaks when the same plaintext is encrypted since the same ciphertext will be produced. The RFC gives some examples of limits. The key thing is AES-GCM-SIV is designed for cases where you can't guarantee the nonce won't accidentally repeat a few times, not for scenarios where you don't want to use a nonce (equivalent to having a fixed nonce). The security degrades when you do that. $\endgroup$ Feb 9 at 13:46

1 Answer 1

4
$\begingroup$

In short yes, nonces just need to be unique. Just zeroing "leftover" bytes is fine if your protocol can guarantee uniqueness with fewer bytes. In protocols the zero bytes are often accompanied with the test "other values RFU" to indicate that updates of the protocol may use the bits for other means. The inclusion of RFU doesn't allow for forward compatibility, it's more of a hint to future protocol architects and designers of API's.

For the implementation I'd use a nonce of 64 bits as that is a common integer size and put that as big endian value in the rightmost bytes. Big endian is common for nonces (I also like big endian better than little endian, but that's not an objective reason to use it for a particular algorithm).


The implications of nonce reuse in AES-GCM are pretty scary. They include the almost complete loss of information about the plaintext as well as the potential loss of the internal authentication key used to authenticate the messages. AES-GCM-SIV protects against these vulnerabilities.

The reason why GCM-SIV is "hardened" rather than fully protected is that nonce reuse for the same message will result in the same ciphertext / authentication tag, which means that information about the duplication of messages is still apparent to an adversary. As ciphers should be indistinguishable from random - even with chosen plaintext - it still breaks fundamental security expected from a cipher.

$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.