7
$\begingroup$

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?

Improve this question
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – Henrick Hellström
    Dec 6, 2016 at 0:17
  • $\begingroup$ Good point, glad you brought it up. Makes the question a bit redundant for TLS, but I guess it survives on its own. $\endgroup$
    – Maarten Bodewes ♦
    Dec 6, 2016 at 0:32
  • $\begingroup$ Related: Attacks of the MAC construction $\mathcal{H}(m||k)$ for common hashes $\mathcal{H}$? $\endgroup$
    – CodesInChaos
    Dec 6, 2016 at 8:03

2 Answers 2

Reset to default
6
$\begingroup$

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.)

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – cipher
    Dec 8, 2016 at 23:31
2
+50
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.