1
$\begingroup$

Looking at HMAC and KMAC it seems that the key is always required up front, i.e. before starting to process any other data. However, in many protocols the key may not be known it advance. For instance, in TLS, the PRF (MAC) is calculated over the messages produced before key agreement.

TLS 1.2 solves this by producing a separate secure hash:

    PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

That's great but somewhat inefficient as it requires a separate hash (both regarding processing time and configuration options). Are there any MAC algorithms that can configure the key afterwards without caching the data? Or are there any reasons not to do this?

Improve this question
$\endgroup$
7
  • 2
    $\begingroup$ Any MAC with a bounded amount of state, and which processes the key last would need to do a collision resistant mapping from the message to the state. Given this, wouldn't it be best if you used a designed collision-resistant function for this purpose? $\endgroup$
    – poncho
    Mar 12, 2018 at 20:22
  • $\begingroup$ @poncho Um, I'm trying to see what you are meaning. So uh, you're saying that you'd need a hash anyway (the collision resistant function) so you might as well do $\operatorname{MAC}(K, \operatorname{Hash}(M))$? $\endgroup$
    – Maarten Bodewes ♦
    Mar 12, 2018 at 20:25
  • $\begingroup$ It would certainly look like the best option to me; the alternative would be to rely on a mapping that's not designed to be a collision resistant hash function; perhaps that's doable (as the state size need not be limited to twice the target security strength, it might be a tad more efficient), but still to me, it would raise concerns... $\endgroup$
    – poncho
    Mar 12, 2018 at 20:31
  • 2
    $\begingroup$ Until you stir the key in, there's nothing in the MD that the adversary can't compute, hence (unlike MACs in general), collision attacks are certainly on the table. $\endgroup$
    – poncho
    Mar 12, 2018 at 21:14
  • 1
    $\begingroup$ I think it might be worth noting that the TLS 1.2 handshake messages includes a "client random" and a "server random" value in the Client Hello and Server Hello handshake messages. Would this mitigate the collision attacks? $\endgroup$
    – Luis Casillas
    Mar 12, 2018 at 23:02

0

Reset to default

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.

Browse other questions tagged or ask your own question.