What Is a Message Authentication Code (MAC)?
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)

What Is a Message Authentication Code (MAC)?

Message authentication codes are hidden bits of code within online communications. In SSL/TLS connections, MAC “tags” offer assurance a message you received came from an authentic person and helps prove the message wasn’t altered in transit

In computer systems, data is binary, meaning that computers use bits (1s and 0s) to communicate it. Data frequently gets processed in either blocks or streams of individual bits (blocks = groups of 1s and 0s, streams = 1s or 0s). But how can you know whether the messages you receive via data streams online were sent by authentic users and haven’t been altered in transit?

You need a way to verify that a message came from an authentic sender (not an imposter) and that the data hasn’t been modified (i.e., it arrived as intended). This is where message authentication codes can come in handy. But what is a message authentication code and what role does it play in internet security?

Let’s hash it out.

What Is a Message Authentication Code?

A message authentication code (MAC) is a string of code that tells you who created or sent a message you received and whether that data has been altered. It does this in a way that validates the sender’s identity is legitimate (i.e., a MAC authenticates the sender) over the internet using a shared secret (i.e., a private) key known only by the sender and recipient.

A MAC is sometimes called a tag because it’s a shorter piece of authenticating data that gets attached to the message. It’s also sometimes referred to as a keyed hash function because it uses a symmetric key that’s shared between the message sender and recipient. (More on that in a little bit.)

Message authentication codes provide offer two critical properties:

  • Completeness. A sender can attach this secret string of code to any message and have the intended recipient verify it.
  • Unforgeability (Security). They also offer security by preventing bad guys who intercept those messages from trying to fake that tag in the future when sending fraudulent messages. How? By preventing them from forging tags for new messages they haven’t seen tagged previously.

An Overview of What a MAC Does (And Why You Should Care)

A MAC algorithm authenticates the legitimate sender’s identity so you know the data truly came from them. What it doesn’t do is protect the confidentiality of your data.

To put it another way, basically, a MAC helps a recipient check whether:

  • A message came from a legitimate sender (because they have the shared secret key), and
  • The message has been altered somehow (either accidentally or intentionally) since it was sent (because the MAC uses hashing to validate data integrity).

Why is this important? Because the internet is inherently insecure; it’s an open network that transmits data in plaintext, meaning that anyone who knows how can intercept your data in transit. What this means is that without the proper security mechanisms in place, someone could intercept your incoming messages in transit and replace it with something phony. Or, if you’re the sender, they could send entirely new messages and make it look like they came from you.

And if you don’t have mechanisms in place to check that you’re talking to the right person and that the data is unaltered, then you can’t trust the information you receive.

MACs Provide Authentication & Data Integrity Checks (But Can’t Support Non-Repudiation)

In one sense, message authentication codes are kind of like the symmetric key version of digital signatures. (Digital signatures are for use with asymmetric encryption systems only.) When using MACs, the sender and recipient use a single key; with digital signatures, a public-private (asymmetric) key pair is used where the sending party signs their message using one key while the receiving party accesses the message using the other.

But there is a big difference between a MAC and a digital signature that can be summed up in two words: non-repudiation.

  • A digital signature ensures that the sender can’t deny that they sent the message. This is because only one party has the private key.
  • A MAC doesn’t offer that additional layer of security because the symmetric key that it uses is known by more than one party. Since both the sender and recipient have access to the key, there’s no way to verify who was responsible for creating the message.

Because MACs provide authentication and data integrity protection, they’re incredibly useful for helping users’ devices determine whether to accept or reject a message. If the MAC is invalid, their devices won’t return the plaintext — they’ll display error messages instead.

Where You’ll Find MACs in Use

MACs are typically embedded in message headers and/or cryptographic ciphers. They’re frequently found attached to ciphertext as a way to enable authenticated encryption. As such, they’re used to validate the legitimacy and integrity of data that is

  • transferred via internal or external networks, including SSH and SSL/TLS connections (to help prevent malicious packets from being inserted into a connection)
  • stored in your organization’s internal systems, or
  • stored in external systems or devices.

What a MAC Looks Like

A MAC is created by combining a symmetric (secret) key with the message and then hashing it using a hashing function. Yup, that’s right. A message authentication code uses a specific combination of a message of any length and a secret key to generate a resulting output (message authentication code):



When you break down a message authentication code, it looks like this:

h(k,m) — or hash(key,message) to think of it another way

Basically, you combine your secret key with the message and then hash it to convert it to a fixed-length string of hexadecimal characters to disguise the size of the message.

An basic graphic that shows how to create a message authentication code (MAC) tag
Image caption: A basic graphic that illustrates how message authentication codes are created.

We mentioned earlier that message authentication codes are sometimes referred to as keyed hash functions. This is because they do use hash functions as part of their makeup, but unlike traditional hashing, MACs also use a symmetric key.

Here’s a quick overview between traditional hash and MAC functions:

 Traditional Hash FunctionMAC Function
What It IsA one-way cryptographic function that uses a single input to generate an output of a fixed length (called a hash value or digest)A cryptographic function that uses two inputs (a message and a symmetric key) to generate an output (i.e., a tag or MAC) that varies in size depending on the input  
What It DoesEnsures any changes (no matter how small) to the input message will result in an entirely new hash value outputEnsures any changes (no matter how small) to the input message or key to generate an entirely new hash value output  
How It HelpsOffers data integrity protectionIt offers two essential properties: authentication and data integrity protection  
Examples of AlgorithmsMD5, SHA-1, SHA-2CMAC, HMAC, KMAC  

What Message Authentication Codes Are Used For (Authenticity & Integrity Validation)

In a nutshell, a message authentication code is a string of code that enables you to authenticate that the messages came from a legitimate user or device. It’s a unique string of data that’s generated by combining a cryptographic symmetric key with a plaintext message and then hashing it using a cryptographic process called a hash function. (We’ll speak more about hashing a little later in the article.)

Imagine that you’re communicating with a friend who owes you money. They ask for your bank account and routing number so they can transfer funds to reimburse you. You send them the info, they use it to pay you, and you’re both happy.

But what if an attacker intercepts your message and wants to take advantage of an opportunity to make some easy money? Instead, they could replace the bank account information you’ve provided with info for an account they control. What this scenario means is that without a MAC:

  • You’ve sent your friend the legitimate banking info;
  • Your friend receives the attacker’s account information instead; and
  • Neither you nor your friend realizes this info swap has taken place — the friend sends money to an account they think is yours, and you never receive the money.

As you can imagine, this will lead to an unpretty situation with both of you thinking that the other one is being untruthful. But the truth of the matter is that neither of you realizes that you’re not talking to the other legitimate party. This is where message authentication codes play an important role.

How MACs Work (A Quick Overview) 

When you create a MAC, you combine the secret key with the message you want to protect. This information is then hashed to a fixed length, creating the string of data that serves as your MAC. Once this is done, your message is sent and makes its way to the recipient. Their client then computes the MAC using the same function.

If the resulting digest matches the one you provided, it tells your recipient that the data/message:

  • Is authentic (i.e., it was sent by the legitimate sender), and
  • hasn’t been compromised somehow (i.e., the message’s integrity is assured).  
A basic illustration that shows how message authentication codes work and how MAC values are verified
Image caption: A basic overview of how message authentication codes are computed to ensure the values match and that the data hasn’t been altered.

Of course, for this to work, you need to keep your key secure. This may involve storing your key in a key vault or a hardware security module (HSM). While it’s true that you want your recipient to know the key, you want to ensure that no one unintended gets their hands on it. If they do, then your key is useless and should be destroyed immediately.

Be Precise: How You Carry Out the MAC Process Matters

Just because you have all the correct elements doesn’t mean that you can create the right MAC. When you combine a secret key and the input message you wish to protect, you and the party you’re communicating with must do so in a specific way to generate the same message authentication code. Otherwise, if you combine the key and message in one way but your recipient does it in another (different) way, you’ll both wind up getting completely different values.

Simply put, preciseness and order matter. Think of it in terms of making cookies. (I mean literal cookies — not the bits of data that track web users.)

When you’re baking chocolate chip cookies, for example, you typically want to cream your softened butter and sugar first before introducing other wet ingredients (eggs and vanilla) and your dry ingredients (flour, baking powder, etc.) little by little. If you simply dump in your dry ingredients and then try to later add in your butter, sugar, eggs, etc., then you’re going to get a dough that’s a very different (and often unpleasant) consistency. 

The same concept applies to message integrity. As you can imagine, not having matching hash values doesn’t bode well when your recipient is trying to verify the data’s integrity.

Hashes and MACs share a special relationship in cryptography. They’re both cryptographic functions and while one involves the other, that relationship is a bit of a one-way street. You see, hashes don’t use MACs, but MACs do use hashing as part of their process:

  • Hashing combines a cryptographic hash function with the message to create a fixed-length string of randomized data (i.e., a hash output or digest) without authentication. Hashing, on its own, doesn’t offer assurance of the sender’s identity. Because there’s no shared secret key, it’s used to validate the integrity of the message’s data only and not the identity of the sender.
  • A message authentication code uses a single key with the message and hashes it to validate the message’s sender identity and ensure data integrity. If the two components are combined in the wrong way, it’ll result in generating a different MAC. This offers assurance that the sender is who they claim to be, but it doesn’t offer assurance that their message hasn’t been compromised or altered since they sent it. Unlike hashing alone, this requires the use of a secret key that you combine with the message prior to hashing it.

MACs May Leave Your Data at Risk of Compromise If Not Implemented Properly

It’s important to note, however, that MACs aren’t foolproof as some may be susceptible to padding oracle attacks. These are attacks in which a bad guy uses the padding validation of your encrypted message to decrypt its ciphertext. Basically, there are ways to potentially change messages — even if an attacker doesn’t know the secret key — via an approach known as a length extension attack if you’re using insecure hashing algorithms (MD5, SHA-1, etc.). This involves an attacker using your hash(m1) and the length of your message to calculate.

To help avoid this issue, many organizations will instead use a specific type of MAC, known as an HMAC, instead and will carry out applying their MACs in specific ways. (More on both HMACs and MAC application methods in a few moments). But first, let’s quickly cover a couple of the risks when you don’t use an authenticated symmetric encryption security mechanism…

Chosen Plaintext Attacks (CPAs)

While it’s great to learn about what message authentication codes are and how they work, it’s now time to explore how cybercriminals can try to use a chosen plaintext message attack to gain access to your plaintext message via existential forgery. A strong MAC must be resistant to this type of attack.

A chosen plaintext attack is a type of attack wherein an attacker creates a new valid message-tag pair they can use without knowing the key required to generate it. Basically, they’re attacking your encryption function.

Let’s consider a quick example. Say, an attacker wants to get their hands on your message authentication code tag. (Tags are long strings of data, often anywhere between 64 and 128 bits — TLS tags are 96 bits in length.) The following scenario plays out:

  • The attacker sends a series of random messages to you (the recipient), which you use to compute a corresponding message tag.
  • You then send that message tag back to the attacker.
  • The attacker then figures out a new valid message-tag pair (one different from any others you have) they can use to their advantage.

The goal here for the attacker is to perform an existential forgery attack. This is where they use what you’ve sent to create a new valid message-tag pair — one that doesn’t match any of the existing message-tag pairs that were given to him.

  • If the attacker is successful: The attacker was able to create a new valid message-tag pair, which means the message is insecure.
  • If the attacker is unsuccessful: The attacker was unable to create a new message-tag pair, which means the message is secure.

Chosen Ciphertext Attack (CCA)

Of course, chosen plaintext attacks aren’t the only thing bad guys can do. They can take things up a notch by targeting specific ciphertext that they wish to decrypt or change. This is known as a chosen ciphertext attack (CCA), and it involves an attacker having access to a decryption oracle at some point.

There are two varieties of CCAs:

Non-Adaptive Chosen Ciphertext Attack (CCA1)

In this type of attack, also known as CCA1, a bad guy can make decryption queries while not knowing the ciphertext. This is because the attacker can only access the decryption oracle prior to the target being revealed (i.e., receiving the challenge ciphertext). So, if they don’t have access to it after receiving the encrypted string of data, it’s essentially useless.

Adaptive Chosen Ciphertext Attacks (CCA2)

In an adaptive chosen ciphertext attack, on the other hand, an attacker isn’t limited in the same way. They can make decryption queries even after their intended target ciphertext has been revealed. So, they can send additional queries afterward to leverage the information they’ve learned to decrypt ciphertexts of their choosing.

The SSL/TLS ROBOT attack is more recent example of such an attack in a public key encryption scheme.

Types of Message Authentication Code Algorithms

If you didn’t know before, you sure do now: There are multiple types of message authentication code functions. However, the National Institute of Standards and Technology (NIST) says there are only three approved general-purpose MAC algorithms that are recommended by NIST or FIPS (the Federal Information Processing Standards) for use by federal agencies.

1.     Hash-Based Message Authentication Code (HMAC)

Wait, doesn’t a MAC already using a hash function? Yes, that’s true. But unlike the traditional MAC we talked about earlier, a hash-based message authentication code, or HMAC, is a type of MAC that uses two keys and hashes stuff twice. Essentially, you combine key #1 with the message and hash it. After that, the next step is to append it to key #2 and hash everything again. This gives you a hash-based MAC.

HMAC was introduced in the late 90s in the Internet Engineering Task Force’s request for comments (RFC 2104) as a way to ensure greater data integrity protection. It’s also been talked about and expanded upon in multiple FIPS and NIST documents since.

Be sure to stay tuned to our blog as we’ll speak more about HMACs in another article in the next couple of weeks.

2.     Cipher Based Message Authentication Code (CMAC)

A cipher-based message authentication code, or CMAC, is a variation of a cipher block chain message authentication code (CBC MAC). Unlike the basic CBC MAC, which is useful on fixed-length messages, the CMAC can be applied to messages of virtually any length.

To learn more about CMAC, check out NIST’s special publication (SP 800-38B).

3.     KECCAK Message Authentication Code (KMAC)

A KMAC is a type of variable-length MAC that’s based on the KECCAK algorithm (which is used for SHA-3 hashing related functions). KMAC comes in two variations: KMAC128 (128 bit) and KMAC256 (256 bit). The difference? The security strength and output sizes in terms of bits.  

NIST and FIPs talk more in depth about KMAC in their documents NIST SP 800-185 and FIPS 202, so be sure to check out that publication to learn more about it.

How to Apply a MAC Functions to Your Data

So, how exactly do you apply a message authentication code to your data? The answer depends on what you’re trying to achieve. Let’s quickly look at two common approaches of applying MACs to data:

Approach #1: Encrypt-Then-MAC (ETM)

The encrypt-then-MAC approach is widely used in TLS 1.2 encrypted data transmissions, like what your customers’ browsers do when they visit your website. But what does this process look like? In both of the following examples, you’ll need to generate unique keys for the encryption and MAC functions.

In the encrypt-then-MAC approach, you’re going to:

  • Prepare your plaintext message.
  • Apply an encryption function to your plaintext message using an encryption key. This will create a ciphertext (i.e., an unreadable string of hexadecimal characters).
  • Apply the MAC function to the ciphertext using the second key. 

A basic example of the process looks like this:

A basic illustration that shows how the encrypt-then-mac approach works. Symmetric encryption is applied to the plaintext, and the resulting ciphertext is then hashed, creating the MAC tag
Image caption: A simplified illustration of how to employ a MAC code via the encrypt-then-MAC approach.

Approach #2: MAC-Then-Encrypt (MTE)

This method was used for older variations of SSL/TLS protocol (prior to the publication of Internet Engineering Task Force’s [IETF] RFC 7366) because it was once considered secure. The processes involved in this approach are much the same as ETM, but they’re carried out in a different order. This variation requires a bit of a “switcheroo” but the end result is secure.

In the MAC-then-encrypt approach, you’ll apply your MAC function (using the MAC key) to your plaintext message first, which creates your MAC tag. After that, apply your separate encryption key to that message-MAC tag combination to generate the ciphertext.

Here’s a quick overview of how the process looks:

A basic illustration that shows how the MAC-then-encrypt approach works. Your MAC hash is applied to the plaintext message, and the combined value is symmetrically encrypted, resulting in the ciphertext
Image caption: A basic illustration that shows how to employ your MAC code using the MAC-then-encrypt method.

Have we lost you? Don’t worry, that’s as technical as we’re getting in this article. It’s time to wrap things up.

Final Thoughts on Message Authentication Codes in Cyber Security

As you can see, message authentication codes play important roles in internet security in multiple areas. Message authentication codes help validate a message sender’s identity and verify that the data they’ve provided hasn’t been messed with since they sent it. It doesn’t offer data confidentiality, and that’s okay — data confidentiality isn’t the purpose of message authentication codes. (You can use encryption separately for that purpose.)

There are several varieties of message authentication codes that you can use depending on your needs and goals. And while they don’t provide the non-repudiation afforded by public key digital signatures, they still play important roles in cybersecurity as a whole.

There are many different understandings and misconceptions about what MACS are. We hope this article has shed some light on message authentication codes and provides clarity on the topic. Be sure to check back for another article relating to MACs, which will dive into exploring hash-based message authentication codes more in depth.

Be the first to comment

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *


Casey Crane

Casey Crane is a regular contributor to and managing editor of Hashed Out. She has more than 15 years of experience in journalism and writing, including crime analysis and IT security. Casey also serves as the Content Manager at The SSL Store.