0
$\begingroup$

The process of verifying integrity through MAC involves two separate algorithms (as mentioned here). On the server side, a signing algorithm runs which calculates the MAC of the message using the shared key, while on the client side, a verification algorithm runs which uses the secret key, the received MAC and the message to verify whether the message was altered in transit or not.

But we can simply dispense with a separate verification algorithm by simply calculating the MAC of the received message using the shared key. If the calculated MAC and received MAC are the same, the message has not been altered.

Is that what actually happens in all MAC verification algorithms?

Improve this question
$\endgroup$
3
  • 4
    $\begingroup$ Actually, I have come across symmetric MAC algorithms which supported a verification method that wasn't a straight-forward 'compute the MAC tag and compare'. However, I don't recall any particular advantage those alternative approaches gave, and in any case, for essentially all the MACs we use in practice, we do follow the 'recompute-and-compare' method... $\endgroup$
    – poncho
    Commented Jul 11, 2020 at 16:25
  • $\begingroup$ Assuming MAC calculation is time/cpu/memory-intensive, I could imagine cases where it could be beneficial to compare partially-calculated MAC with the remainder of (potentially cancellable) computation running in parallel, assuming the MAC algorithm would allow for it. Having said that, I didn't come across such case. $\endgroup$
    – user80928
    Commented Jul 11, 2020 at 16:32
  • 1
    $\begingroup$ The answer is no. See the related question Are there any non Canonical Verifiable Cryptographic MACs $\endgroup$
    – kelalaka
    Commented Jul 11, 2020 at 18:16

2 Answers 2

Reset to default
2
$\begingroup$

Signing and signature verification are concepts related to public key cryptography.

In case of message authentication codes, there is a single secret key and one function:

T = MAC ( K, M )

Where:

  • T - tag
  • MAC - MAC function
  • K - secret key
  • M - message

Messages can be signed by either the client or the server and verified by the other, depending on the case. Both parties calculate MAC the same way, using the same function and secret key, over the same message. There is no separate function for MAC verification. The only extra step on the receiving end is associated with comparing if both received and calculated tags match, and then acting accordingly. But this has nothing to do with a MAC algorithm itself.

Improve this answer
$\endgroup$
2
  • $\begingroup$ The Wikipedia page lists a the MAC verification algorithm as a separate thing $\endgroup$
    – Daud
    Commented Jul 11, 2020 at 16:22
  • 2
    $\begingroup$ What they call "MAC verification algorithm" is defined as follows: "The receiver then compares the first MAC tag received in the transmission to the second generated MAC tag. If they are identical, the receiver can safely assume that the message was not altered or tampered with during transmission". This is in fact just a different wording of what I have included in my answer, as well as what you included in your question: "But we can simply dispense with a separate verification algorithm by simply calculating the MAC of the received message using the shared key" $\endgroup$
    – user80928
    Commented Jul 11, 2020 at 16:28
2
$\begingroup$

The function to calculate a MAC takes a message and a key, and outputs a tag.

To verify a MAC, you want to take a message and a key, and output a boolean (true if verified, false if not) instead of a tag.

Thus, the two functions can't be the same, since they have two different type signatures. In C-like pseudocode

uint8_t* MAC(uint8_t key[], uint8_t message[]);

vs

bool VerifyMAC(uint8_t key[], uint8_t message[], uint8_t tag[]);

Of course the implementation of VerifyMAC is essentially just to compute the MAC and compare the result with the received tag. But the process of computing the MAC and comparing the result with the tag is a function, which is different from just computing the MAC. Some cryptographic libraries might require you to implement this comparison yourself, since it's not excessively difficult (constant-time comparison is often provided, and simple if not, but catastrophic if forgotten), but others include it to make usage easier and safer.

Improve this answer
$\endgroup$
2
  • 3
    $\begingroup$ "Some cryptographic libraries might require you to implement this comparison yourself, since it's trivial," I think in general you will want to do a time-constant compare, and I think you can therefore not call it "trivial". Actually, it is relatively error prone because of it. Another common implementation mistake is to rely on the size of the received authentication tag and only compare the minimum amount of bits / bytes rather than one configured in the protocol. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 12, 2020 at 0:38
  • $\begingroup$ Yeah, there's no good library I can think of that doesn't include it. But there are some terrible old libraries that don't. Edited to address your points. $\endgroup$
    – SAI Peregrinus
    Commented Jul 13, 2020 at 13:19

Your Answer

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

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