2
$\begingroup$

I am using a Python library called PyCryptodome, which offers the following API for AES-GCM ciphers:

https://pycryptodome.readthedocs.io/en/latest/src/cipher/aes.html

As you see, IV is not applicable for GCM ciphers.

There are some C++ libraries that expect the user to specify the IV rather than the nonce.

Let's say that I get a message encrypted with a C++ library that uses a 16 bit IV. Later on, I want to decode this message using a Python library. Given that I know the key and the IV that was used, will I be able to properly decipher the message when I specify the nonce to be the IV?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
7
$\begingroup$

The term for the parameter to AES-GCM that must be unique from message to message for any single key is sometimes called ‘nonce’ and sometimes called ‘IV’.

  • The security contract for AES-GCM requires that only that this never be repeated, and so it is appropriate to call it a nonce, meaning number used once.
  • In contrast, for, e.g., AES-CBC, there is a parameter for a 128-bit string that must be unpredictable in advance to an adversary, and which is usually called an initialization vector.

That's the distinction that PyCryptodome is getting at when it distinguishes the ‘nonce’ and the ‘IV’—although it says ‘IV’ for AES-CFB and AES-OFB too when really they just take a nonce. However, in some other APIs, the corresponding parameter is always just called IV. To be confident, you should draft some code using two different libraries—like one of the C++ libraries you have in mind—and make sure they can interoperate, and include known-answer tests with fixed keys, nonces, and messages, as test cases in your code.

Caveat: AES-GCM is best with a 96-bit (12-byte) nonce chosen sequentially as a message sequence number. If you use a 128-bit (16-byte) nonce—as the PyCryptodome documentation wrongly recommends—it is as if you had chosen a 96-bit nonce at random, which means, because of the danger of a nonce collision, that there is a much smaller limit on the number of messages than if you had chosen a 96-bit nonce sequentially.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Why, exactly, is a 128 bit nonce the same as a 96-bit random nonce? Looking at the AES-GCM implementation in OpenSSL, it's possible to use EVP_CTRL_AEAD_SET_IVLEN and set it to 16 bytes or 32 bytes or whatever you please. And at that point a random number is probably better than a "possible to mess up" increment. $\endgroup$
    – Erik Aronesty
    Commented Sep 19, 2019 at 15:05
  • $\begingroup$ @ErikAronesty If you use a nonce other than 96 bits, GCM derives an initial block pseudorandomly from the nonce—so even if you choose a (say) 64-bit nonce sequentially you can get a nonce collision long before $2^{64}$ messages. The story is actually a little more complicated, and the originally claimed security reduction was wrong because the designers of GCM made a mistake in studying how non-96-bit nonces work. See crypto.stackexchange.com/a/67367 for some references and further information about GCM. I recommend you always use 96-bit sequential nonces with AES-GCM. $\endgroup$
    – Squeamish Ossifrage
    Commented Sep 19, 2019 at 15:15

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.