# What is the overhead of GCM? And how are GCM tags signed by RSA/PKI?

I'm mainly trying to wrap my head around the pipeline of encryption, hashing and signing.

I've read over this question, describing the overhead of GCM, which I understand to be configurable for space-efficiency at the cost of security, but will be at most 196 bits.

This article by IETF, describing the overhead of TLS, appears to state that the GMAC/MAC is 128 bits long - which I'll understand as an average value

-----------------------------------------------------------------
AES_128_GCM, AES_256_GCM
-----------------------------------------------------------------
Per-packet overhead (TLS 1.0, 1.1, 1.2)                  29 bytes
Explicit Nonce                                         8 bytes
GMAC                                                  16 bytes
-----------------------------------------------------------------


My first question is: If we're using the cyphersuite TLS_AES_128_GCM_SHA256; and GCM is using Encrypt-then-MAC (which appears to be always?) and is configured to use a 128-bit tag; and AES_128 is encrypting plaintext in blocks of 128 bits; then is GCM adding a 128-bit tag onto each one of those blocks (thus, halving the amount of cyphertext that can ultimately fit into the data payload of the L3 packet)? Or, is each tag XORed (or transformed in someway) into the next, to produce a single 128-bit tag (2) that is the result of all the previous operations?

The Wikipedia page for GCM repeatedly mentions "authentication", however it seems to be using it in place of "integrity" - ie. ensuring data hasn't been manipulated/corrupted in transit. I have a very basic understanding of the three types of EtM/MtE/EaM functions, of AEAD and of PKI... so my second (multi-part, sorry...) question is:

How/where exactly is SHA and RSA (or any signature algorithm) used in this process?

SHA I know to be a hashing algorithm - used in HKDF during the initial DHKE. It's also used to create small hashes/"fingerprints" of large pieces of data, such as Certificates - which I suppose are then signed by the private key of the private/public RSA key pair for the sake of "authenticating" each message/session.

(1) Is the RSA private key used to sign the tag/tags after they're generated, or are they used in the generation of the tags themselves?

(2) Is the RSA private key of the sender used to "sign" each tag of each block, or just the single 128-bit tag after the whole payload of plaintext is encrypted?

(3) Is the client signing hashes/MACs as well after communicating their public key, or is that usually only done by the server/owner of a signed RSA Certificate?

This thread seems to state that symmetric keys are used instead, but discussion kind of made me more confused.

If we're using the cyphersuite TLS_AES_128_GCM_SHA256; and GCM is using Encrypt-then-MAC (which appears to be always?) and is configured to use a 128-bit tag; and AES_128 is encrypting plaintext in blocks of 128 bits; then is GCM adding a 128-bit tag onto each one of those blocks (thus, halving the amount of cyphertext that can ultimately fit into the data payload of the L3 packet)?

No, the GCM is performed on the entire record; hence the overhead added by the GCM tag is 128 bits per record. That is, the GCM encryption operation is given the plaintext (which is the original unencrypted record), the AAD (which is made up by the record header plus the record sequence number) and the nonce (the 8 bytes given in the record plus 4 bytes from the key negotiation step), and it produces the ciphertext (which is exactly as long as the plaintext) and a 16 byte GCM tag. TLS doesn't worry about what GCM does to perform this operation.

The table you cite gives the overhead per record (however, it is mislabeled as per packet; TLS records do not correspond to 'packets'; there may be several records per TCP packet (segment), or a single record may extend over several packets).

How/where exactly is SHA and RSA (or any signature algorithm) used in this process?

SHA and RSA are not involved at all during the record encryption/decryption process, so none of your three options describe the situation. They may be used (and generally are) during the connection set up phase (which verifies that the server is who he claims to be (and optionally the client as well), and also generates the symmetric keys that GCM uses.

• Thank you. I've had a read over the RFC for GCM+TLS1.2 || additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; || AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data) || I understand that TLS will fragment data (+may/may not compress it) into records based on data-type. GCM+AES will then encrypt these records and assign each a 128-bit MAC for integrity. TCP will then segment this cyphertext. But the recipient will always receive the MAC+nonce in the first segment? Jan 19 at 3:47
• I understand the methods used for session authentication (PKI/Certs etc). But what about per-segment authentication? Or is there only per-segment "integrity" with MACs? I imagine someone else inserting a segment wouldn't have the symmetric key anyway, but I'm still curious. Jan 19 at 3:53
• @Rory: No, the recipient is not guaranteed to receive the MAC+nonce (did you mean tag+nonce) in the first segment. TLS does not actually define how the record is mapped into TCP segments (even if TCP is the transport protocol - that's not mandatory); an implementation is free to place the first byte of the TLS header in one segment and everything else in another. Jan 19 at 3:55
• @Rory: as for per-segment authentication, the knowledge of the GCM key (which is needed to generate valid GCM tags) is what is used for per-segment integrity (and authentication - only someone who knows the GCM key can generate valid tags, and only two entities; the client and the server; know that, and the side who receives the ciphertext knows he didn't generate the tag, so it must be the other side) Jan 19 at 3:58