Understanding AES-GCM IV (Nonce), Tag/MAC, Message & Transmission

Joseph

12/1/23, 6:50 AM

I am working on a project that uses PAKE (SRP) for authentication. When we send the M1 to the server we are encrypting the payload using AES-GCM. I mention SRP only to set the context:

A message is being sent to the server with content we want to protect
The client and server have a unique (one-time) symmetric key shared between them (thanks to SRP)

Before I encrypt the payload I generate a unique IV (nonce). After running the message through the cipher I have the encrypted message and a tag (message authentication code).

Therefore, the REST payload to the server roughly looks like:

{
  "kid": "LJNZZFQYWGTLBN4OROQ4J7GLBD",
  "enc": "AES-GCM",
  "iv": "AkR5QsOAwokwwopEBDDDjQ==", // base64
  "tag": "8ja1fhFeoUbgOmNzYV9zEQ==", // base64
  "data": "MIyMy3p3GIUZG6rJV3cZA7qXEcREIKumfAtT"
}

I am struggling to understand the benefit of sending the tag. Since we are using SRP the client and server are already using a unique (one-time) session key K.

Can't I just rely on the session key K to determine authenticity? That is, if the message is authentic, then I would be able to decrypt it using K and parse the JSON result into a valid value. (Note: In SRP the shared session key K is a symmetric key which can be used for encryption)

Further, would I send the tag in plaintext as listed above? Maybe asked differently, do I need to have any special handling of the tag when transmitting it to the server? (Is base64 a reasonable format?)

I am very green when it comes to cryptography (and trying to pick it up quickly). Any support appreciated.

576

1 + 0

aes

srp

aes-gcm

Score:1

Crypto

Maarten Bodewes

12/1/23, 10:40 AM

Can't I just rely on the session key K to determine authenticity? That is, if the message is authentic, then I would be able to decrypt it using K and parse the JSON result into a valid value.*

Generally no. The authentication tag ensures that the message is encrypted properly for this particular key. GCM does not provide key commitment, so the message might also be valid for a different key (so the same message may authenticate two different users!). However, it should be impossible for an attacker to find a message that is valid for your current key - as long as you don't allow replay attacks.

GCM uses CTR as encryption mode. This mode XOR's a message with a generated key stream, created using the block cipher and a counter. It doesn't pad, and since any plaintext is valid, it will itself never find any error during decryption. Furthermore, it allows attackers to flip any bit, so if part of the message is known then an attacker can use that information to create any other message. For instance, it could flip only the values in a JSON message, leaving the JSON headers intact.

Further, would I send the tag in plaintext as listed above? Maybe asked differently, do I need to have any special handling of the tag when transmitting it to the server? (Is base64 a reasonable format?)

Yes, the tag can be "plaintext". The tag is binary. If you use a text interface such as JSON then base64 is reasonable yes (~33% overhead, easy conversion, well understood and usually available).

In your scheme it looks like "kid" identifies the key used. This might be dangerous considering that GCM doesn't commit to keys. Personally I'd be more happy with a HMAC computed value for entity authentication and a GCM with a derived key for message integrity / authentication. This will also allow you to distinguish between mangled messages and failed entity authentication more easily.

You might want to use / study TLS-SRP.

+ 1

Joseph

12/3/23, 6:17 PM

Thank you, that is more or less what was in my head, but good to hear someone else confirm it! As for the `"kid"`, we are using stateless requests, so we have to have a way to "retrieve" the SRP state over multiple REST calls... But I'm actually work on a separate question about that so will link that here once ready.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Understanding AES-GCM IV (Nonce), Tag/MAC, Message & Transmission

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.