Best practices: AES-GCM parameter (initialization-vector, ...) transport

Question

Apparently there is no mandatory method to transport AES-GCM parameters. I only read that the initialization vector often will be prefixed to the ciphertext. So, regarding the other parameters too, I could send a string like this

my_string = ':'.join([
  'a_unique_iv',              # initialization vector
  '128',                      # the tag size in bits
  'id-1234',                  # associated_data
  'the_cipher'                # cyphertext (converted to string)
])

to a REST API endpoint that stores the data. Or another example (that I would prefer because I already use json objects): Add all parameters as json fields:

my_json = {
  'field_a': 'value b',
  'field_c': 'value_d',
  ...
  'aes_gcm_parameters_and_data': {
    'nonce':           'a_unique_iv' ,
    'tagBits':         128,
    'associated_data': 'id-1234',
    'cyphertext':      'the_cipher'    // converted to string
])

Regarding best practices: Are both approaches fine? Is there a better way? Thx.

Answer 1

Are both approaches fine?

Both are fine. The entire point of GCM is that the ciphertext (and nonce and ciphertext) is protected, and so any method of transporting them is fine.

I do want to add one note: what the 'associated data' is typically used for is binding a ciphertext to a context. For example, if you're encrypting database records, one thing you want to prevent is someone taking the ciphertext in one field, and copying it to another. The associated data is designed to protect against that; if the associated data may be the record key, then the attacker can't do that; the record that the ciphertext is copied to would have a different key, and so the decryption would fail.

Because of this, the associated data typically has meaning to the application; depending on what you're protecting with GCM, what you have may be fine (e.g. if the application knows to look into the associated data you provided to verify the context), or it might not be.

Is there a better way?

Cryptographically, you're fine, as I said. As for whether there's a method that would work better (faster, cheaper) for what you're doing, well, you're actually more qualified to say than we are...