MAC where key is provided afterwards

Question

I was just wondering if there is a MAC scheme where the key provided after part of the message has been hashed. I was just looking at TLS 1.3 and a comment of Thomas Pornin where the messages needed to be stored before they were hashed with the session key. But I wonder if it isn't easier to first hash the messages and then provide the key.

Of course the hash algorithm would have to be established, but the ciphersuite is established after the Server Hello message. In that case it could be benificial to something similar to $\operatorname{HMAC}_{K_{mac}}(\operatorname{H}(M_1 | M_2 | M_3))$ (where M is a handshake message), but preferably with a single primitive.

Is there a reason that the key is put in first within HMAC / or SHA-3 / KMAC? Are there reasons that the key cannot be put in last? Or are there schemes that already do this?

This is however not supposed to be as much of an issue with TLS 1.3, as it was in older versions of SSL and TLS. Normally, the client will send its key share as an extension of the client hello, so after server hello both the client and the server will have established the shared key. — Henrick Hellström, Dec 06 '16 at 00:17
Good point, glad you brought it up. Makes the question a bit redundant for TLS, but I guess it survives on its own. — Maarten Bodewes, Dec 06 '16 at 00:32
Related: Attacks of the MAC construction $\mathcal{H}(m||k)$ for common hashes $\mathcal{H}$? — CodesInChaos, Dec 06 '16 at 08:03

score 6 · Accepted Answer · answered Dec 05 '16 at 21:59

If you have a secure MAC algorithm $M$ and a collision-resistant hash function $H$, then you can define another secure MAC algorithm $M'$ such that $M'(x) = M(H(x))$. Historically, though, HMAC was defined as a construction that provides reasonable security as a MAC even for an underlying hash function which is a bit flaky in that respect (in that case, Merkle-Damgård functions like SHA-1, that suffer from the so-called length extension attack, which illustrates the subtleties of MAC-building out of hash functions).

(For reference, my comment in the TLS-1.3 mailing-list is about the need to buffer incoming data until the MAC can be verified; this is unrelated to the moment the key is injected in the MAC process.)

I'm not saying you said they do, but not all M-D functions suffer from length extension attacks though. For instance, SHA-384 is not affected. — cipher, Dec 08 '16 at 23:31

score 2 · Answer 2 · answered Dec 05 '16 at 22:06

One practical reason to put the key first (or, more generally, to involve the key in the MAC computation from the start) is that it provides resistance to collision attacks.

In particular, if your MAC is deterministic and of the form ${\rm MAC}_K(m) = f(K, g(m))$, then any collision attack on the key-independent part $g$ will directly translate into a forgery attack on the full MAC under the usual security definition.

As a practical example, HMAC-MD5 is still (apparently) unbroken, but using unkeyed MD5 as a preprocessing stage before the MAC computation would be trivially insecure.

MAC where key is provided afterwards

2 Answers2