Many of the presentations at The Third NIST Workshop on Block Cipher Modes of Operation 2023 complain about the lack of key commitment in AES-GCM.
But isn't that one application of "associated data?" For instance, can't one include a hash of the key (or something similar) in the associated data?
But isn't that one application of "associated data?" For instance, can't one include a hash of the key (or something similar) in the associated data? Maybe I'm missing the point...
Actually, that doesn't help with GCM.
With GCM, the tag is computed by converting the message and the AAD into a polynomial, and evaluating that polynomial at a value $H$ (which depends on the key).
If you include the hash of the key into the AAD, all the attacker needs to do is:
Pick a nonce and two keys $K_1$, $K_2$, and the corresponding $H$ values $H_1, H_2$, and a target ciphertext message with one block unspecified.
Generate polynomial 1 (which depends on the hash of $K_1$) and the value that is xor'ed into the tag as the constant value (that value depends on the nonce and $K_1$), the unspecified block in the message will translate to a coefficient of the polynomial, which we will treat as an unknown.
Generate polynomial 2 (which depends on the hash of $K_2$) and the value that is xor'ed into the tag as the constant value (that value depends on the nonce and $K_2$), the unspecified block in the message will translate to a coefficient of the polynomial, which we will treat as an unknown.
Find the value of the unknown coefficient for which polynomial 1 (evaluated at $H_1$) is equal to polynomial 2 (evaluated at $H_2$). This is a linear equation in one variable, hence it is easy.
The solution of that gives you the open entry in the message; hence that, with the corresponding tag value (which is easy to compute) will validate with both $K_1$ and $K_2$, thus violating key commitment.
If you want a message that validates with $n$ different keys, that's pretty much the same procedure (except you need to solve $n-1$ linear equations in $n-1$ unknowns).
Now, one idea that does work with GCM is 'include a fixed block in the plaintext (say, all zeros), and reject the decryption if that block doesn't decrypt to the expected value'. This works with 12 byte nonces [1] (because it's a hard problem to find two distinct keys $k_1, k_2$ and a counter value $c$ (derived from the nonce) where $AES_{k_1}(c) = AES_{k_2}(c)$, which is what would be needed). It does add some extra ciphertext expansion, however, it also introduces a second path to reject messages, and so doing that without introducing a timing difference requires some care.
[1]: For nonces other than 12-bytes, you need two blocks of fixed data; that's because that uses a key dependent 'nonce -> counter' transformation; hence for a single fixed block, the problem becomes $AES_{k_1}(c_1) = AES_{k_2}(c_2)$, which is easy. With two fixed blocks, it becomes $AES_{k_1}(c_1) = AES_{k_2}(c_2) \wedge AES_{k_1}(c_1+1) = AES_{k_2}(c_2+1)$, which is hard...
This blog post gives a great summary of modern proposals for generic transformations from existing non-committing AEAD schemes to committing AEAD. The two excellent papers referenced are "Efficient Schemes for Committing Authenticated Encryption" by Mihir Bellare & Viet Tung Hoang; and, "On Committing Authenticated-Encryption" by John Chan & Phillip Rogaway.
Key commitment in GCM (or AEAD in general)[ ?]
The generic transformations defined by the above papers provide varying levels commitment (from just key commitment to the full commitment of all inputs) with no additional ciphertext expansion. From my reading, it can be said that the transformations consider two principle approaches. The first is fixing the production of the final tag to be the output of a difficult to forge function, like a collision-resistant PRF, instead of a polynomial. And, the second is creating an input-specific key which is the output of a hash.
The later paper uses a simplified approach which is a combination. The ciphertext $C$ & tag $\tau$ are processed normally, but then the final tag $\tau^* \leftarrow H(K, N, A, \tau)$ replaces $\tau$. But, this only effects the authentication tag, meaning it doesn't assist in any way in blending $n_{once}$ misuse-resistance & committing AEAD (e.g. further affecting the ciphertext randomization).
The former paper separates the approaches. First turning a non-committing AEAD scheme $\textsf{SE}$ into a key-committing $\textsf{CMT-1}$ scheme $\textsf{SE-1}$ by using a collision-resistant hash for the final tag production. Then, treating the $\textsf{SE-1}$ scheme to another generic transformation to a fully committing $\textsf{CMT-4}$ AEAD scheme $\textsf{SE-4}$ by replacing the encryption key $K$ with a keyed-hash output $L \leftarrow H(K, (N, A))$ & the associated data $A$ with an empty string $\epsilon$. This results in $\textsf{SE-1}(K, N, A, M)$ being transformed into $\textsf{SE-4}(L, N, \epsilon, M)$.
But isn't that one application of "associated data?" For instance, can't one include a hash of the key (or something similar) in the associated data?
The existing answer by poncho explains why just altering the associated data to include the hash of the inputs doesn't help in the case of AES-GCM.
However, this approach is essentially what is done in $\textsf{SE-4}$ schemes, except that the key becomes the hash of the inputs, instead of the hash of the inputs being used as the associated data.
