1

I'm confused about something that makes AES GCM great. It uses MAC to sign data it encrypts. I also uses nonce.

But lets say I encrypt data in software A. Software A produces a ciphertext and a tag as shown here : https://pycryptodome.readthedocs.io/en/latest/src/cipher/aes.html

But when I want to decrypt the ciphertext in software B, it fails because software B does not know the nonce not the MAC code.

So how does software like TLS and such work ?

tommy lee
  • 11
  • 1

1 Answers1

1

It usually works because the treatment of the nonce (sometimes just called the IV) and the authentication tag is contained in the protocol description, see for instance this Q/A for TLS 1.2. The configuration options for a scheme are normally defined and the protocol needs to describe how they are fulfilled.

Sometimes there are defaults, hopefully explicitly defined for the scheme. If not then the wrinkles need to be removed by compatibility testing. It can also be the case that the configuration settings and placement of e.g. the authentication tag are hidden somewhere in a referenced RFC such as RFC 5116. Obviously the data to be authenticated and/or encrypted does need to be defined.

Quite a lot of proprietary implementations forget to define a protocol, and in that case it may be very tricky to find out how the scheme is used. This problem often occurs on StackOverflow where countless hours are spent trying to get code replicated in different languages. This is particularly tricky for encryption as a single wrong bit will lead to decryption errors.

Note that GCM is described in NIST SP 38D and the test vectors are available (CAVP) and generally the GCM implementations themselves can be configured for any protocol, although NIST has indicated that support for nonces other than 12 bytes may be missing. It might be that some shorter authentication tag sizes are also not supported for verification but this is less likely.

Note that there are a few ways of creating a GCM API which may also make it harder to make compatible code:

  • single shot API's where all parameters such as nonce, associated & plaintext / ciphertext & authentication tag need to be supplied at once
  • update / final API's where the (associated) text can be supplied piecemeal
  • streaming API's where the data is usually provided by some kind of input stream or source and/or supplied to an output stream or sink

And then there are the ways of handling the authentication tag: as part of the ciphertext or separately. The nonce is generally part of initialization and the handling is up to the user.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323