 Before we look at message authentication codes, let's summarize some things that we know about symmetric key encryption and we'll summarize them as a set of simple statements or equations and then we'll use them to expand to message authentication codes. So I'll just write down a few things that we know for symmetric key encryption. Let's say, so some of the properties that we know, if we obtain some ciphertext encrypting with symmetric key encryption, let's say with some key Ka, some message or some plaintext p1 and then we obtain c2 by encrypting with the same key Ka, p2. If p1 and p2 are different, they're not equal, what do we know? What can you say in this case? So we encrypt p1 with key Ka and then we encrypt same algorithm, p2, a different plaintext with the same key. What can we say about c1 and c2? What can we say about c1 and c2 under this condition? Can you say anything about them? What's our assumption with symmetric key encryption? Will c1 and c2 be the same? Will they be different? We assume that they will be different. So if this is a basic assumption with encryption, if we encrypt two different plaintexts using the same key, we'll get two different ciphertexts. That's all we can say in this case. So if p1 and p2 are different, then we know that c1 and c2 are different. So we've made this assumption many times, but just to clarify, if we encrypt different plaintexts with the same key, we'll get different ciphertext values. And in the reverse, I will not write it down, but if you decrypt different ciphertext values with the same key, you'll get different plaintext values. If we decrypt c1 with Ka, we'll get a plaintext p1. If we decrypt c2 with key Ka, we'll get a plaintext p2, and p1 and p2 will be different. So the same happens in reverse. We'll use that knowledge shortly. Slight variation, another thing, if we obtain ciphertext c1 and we encrypt using Ka, some plaintext p1, and at another time obtain ciphertext c2 by encrypting with Ka, the same plaintext p1, if the two keys are different, Ka is not the same as Ka, what do we know? Again, the ciphertext will be different. Take the plaintext, encrypt it with two different keys, we'll get two different ciphertext values. These are two assumptions that we make about symmetric key encryption. And in the reverse, if we decrypt two different ciphertexts, right, no, if we decrypt, we can think if we decrypt the same ciphertext with two different keys, decrypt c1 with Ka, decrypt c1 with Ka, we'll get two different plaintext values. So if we change one of the values, either the key or the plaintext, we'll get different outputs. That's a simple way to summarize. We'll use those assumptions when we look at message authentication codes. We'll have the same assumptions. If we change one of the inputs, we'll get a different output. So even if you don't write them down, I think just remember, if we change a key, we'll get a different output. If we change the plaintext, we'll get a different output. The problem that we were discussing about using symmetric key encryption for authentication, it works sometimes. I decrypt the message. If I can recognize the correct plaintext, we can authenticate the source and the data. But there's two problems. Sometimes we cannot recognize the correct plaintext. If the plaintext was random, it has no structure. And more practical, it's hard to recognize the correct plaintext automatically. I decrypt something. I get some plaintext. My computer needs to check, is this valid or is this plaintext correct or not? Well, to do that check, it would need to compare the plaintext against many known structures of plaintext, against the number of English letters, against different languages, whether it's an image, what type of image, and that becomes a complicated task. So symmetric key encryption, we commonly don't use it on its own for authentication. We introduce another technique or another piece of information to authenticate to be sure when we get plaintext, is it correct or not? And that's where max come in. So for now, let's assume when we decrypt something with symmetric key encryption, we may not be able to recognize if the plaintext is correct or not. So we'll use message authentication codes or max. Not medium access control, not an Apple product, but message authentication codes in this case. We see this acronym come up many times. What is it? Well, the concept will go through and see examples of the concept. The idea is that a message authentication code or a MAC is a function or an algorithm that takes two inputs and produce one output. We will talk about or we will give you the names of some of those functions which are used in practice later. We'll just assume we have such function called a MAC that takes two inputs and the inputs are a key, it will be a secret key and a message like a plaintext. A key is used as an input and a message is taken as input and it produces an output which is sometimes the output is called the MAC and that gets confusing. We apply the MAC function and the output is a MAC, a message authentication code. So that's sometimes hard to talk about. Another name of the output is a tag and that's a little bit easier to talk about. We can say we apply the MAC function using the key and message as input, the output will be a tag. So I'll denote the output as t, the tag. The t is a tag or it's also referred to as the code, the message authentication code. Now some characteristics of those inputs and outputs. The input message can be of any length, so our MAC function should be able to take an input of any length, it's not fixed in the length, and the key is of a defined length, k bits, a secret key, it will be kept secret between the pair of users we'll see, k bits in length. It's a shared secret key, that is when we send an authenticated message from A to B, A must know the key and B must know the key. And the tag will be of a fixed length output, n bits we'll denote here. So we take messages in, we use a key as well and we get a tag as output. There's some similarities to symmetric key encryption. If you look symmetric key encryption, take a key as input and a message as input, get a ciphertext as output. So let's write that down and see and talk about the differences. When we write down equations for symmetric key encryption, like I just did, for encryption, symmetric key encryption, we write the equation as a ciphertext, encrypt, that's the function, using a key as input, and a plaintext, but we could also call an M the message. Take some message, apply some key and our encryption function returns ciphertext. Whereas with a Mac, we can write that as we apply some function, we'll denote it as a Mac, take a key as input and return a message. So there is some similarities here, both take as a key as input, a shared secret key, take a message as input with and produce the output, ciphertext and a tag. There are differences regarding the length of the inputs and outputs. With a Mac, we can normally take any length input and we produce a fixed length output tag. With encryption, assuming we have a mode of operation, we can take any length input message, I can encrypt a large file, a small file with a key, and the ciphertext output would be the same length as the message. So the lengths differ amongst these. So let's say the length of the message is, this is p bits, the key is k bits long, the ciphertext with encryption will also be p bits. When we encrypt a message, we get the same length ciphertext. With a Mac, we take a message of input, let's say it's p bits long, we take a key k, which is also k bits long, lowercase k that is, and the tag is not the same length as the message, it's generally shorter and we'll denote that as n bits. So there's a slight difference here in terms of the length of those parameters. With symmetric key encryption, the message and the ciphertext are the same. With applying a Mac function, the message is usually large or arbitrary size and the tag is a fixed length, usually small, n bits we'll say. And the length of the tag will be a characteristic of the Mac function. We'll come back to that in a moment. What else is different between symmetric key encryption and a Mac? The inverse operation. With symmetric key encryption, we must be able to decrypt. So there needs to be some operation such that we can do the reverse. The inverse of symmetric key encryption, we know quite simply we get a message from decrypting. We denote if we know the key and we know the ciphertext, we can decrypt. And we say that that's easy or possible, easy if k is known. So we should be able to decrypt. That's a simple assumption. With a Mac, that's not the case, inverse. The inverse of the Mac is, we can think, applies some function, the Mac inverse function such that we take a key and a tag and we get the original message. And the difference in the design of these functions and how we apply them is that we must be able to decrypt when we use symmetric key encryption. We must have an inverse function. With a Mac, we don't need one and we generally don't want one. So when we design such a function, we don't need to be able to inverse and find the original message. So conceptually there's some similarities with symmetric key encryption and even the design in some parts are similar but symmetric key encryption, we must be able to inverse but with a Mac, we don't. So when we use it for authentication, we'll see why. But what it means is that when people design Mac functions, then it's usually simpler than designing encryption functions. Designing a function that you have to inverse and is secure is harder than designing a function which just has to go one direction. You don't have to inverse. So there's some differences in how they are designed. So we don't need to inverse a Mac function. So let's see why and see how a Mac function is used for authentication. How can we be sure that a received message hasn't been modified and comes from the right sender? So that's the point there. We don't need a reversible Mac function. Makes it easier to design strong Mac functions that are faster than encryption. The next topic is about hash functions and we'll see there's a relationship between Mac functions and hash functions. And sometimes a Mac function is called a keyed hash function but that will come up in the next topic. So how do we use this? What we do is that to provide authentication we take our message, we calculate the Mac on that message and we attach the Mac or the tag with the message and send them both. We don't just send the message across the network. We send the message and the tag that was calculated and there are variations of how we can do that. We'll use the top one first and then later we'll return to the last two. I'll draw it slightly different but just to explain this top picture, user A is on the left, user B on the right and what it's showing is that user A has some message M that they want to send to B and they want to provide authentication. That is when B gets the message B wants to be sure that this message hasn't been modified and that it came from A. That's their aim. In the top case they don't care whether someone sees the message. They're not trying to provide confidentiality. I don't care if someone sees my message I just want to make sure B when they get it knows it was from me and hasn't been changed. That's our aim. What does the diagram show us? We take our message at user A and it's different notation here. They use C in this picture to represent the MAC function. C is the short case for the MAC function. The MAC function is applied on the message using a key as input. We get a tag as output. We combine the message and the tag. This is the concatenate operation. Just join them together. Join them both across the network to B. What B receives, if nothing has changed, is the message followed by the tag. The tag was the MAC of the message and the key. What user B does to verify that everything is okay is they calculate the MAC of the received message and compare that to the received tag. The C in the box here indicates apply the MAC function. We receive a message, calculate the MAC function using the same key as A used. We get a tag as output. We receive a tag as well. We compare them. If they are the same, we assume everything's okay. If they are different, we assume something's gone wrong. What we'll do is we'll go through using this scenario, we'll go through what happens if the attacker tries to modify something or tries to masquerade as someone else and see why using a MAC function provides authentication. We're going to use this approach, but I'm going to draw it slightly different, a little bit simpler so it doesn't take me so much time and maybe a bit different notation. Then we'll see those properties come up. The properties of symmetric key encryption and the characteristics of the MAC function. Let's start, we have user A on the left, user B. The aim is to send a message from A to B such that B is sure it came from A and that if it's modified, B can detect that it's been modified. So B knows it's the original message. So what does user A do at the start? User A calculates the tag on the message. Let's assume that they have a shared secret key, KAB. So assume both of them know this key, somehow they've exchanged that. How could we exchange this key? Diffie-Hellman. So we could have used Diffie-Hellman in the past to exchange this key. So we assume that we've done something to exchange KAB. So the first step that A does is they calculate the MAC or what we'll call the tag. I'll denote it as T1. The tag using the MAC function and the MAC function takes a key as input and we use the shared secret key, KAB. And the message that we want to send, I'll denote as M1. So we calculate the tag, apply our MAC function on it and the tag will be short normally, fixed length. Let's say our message was one megabyte in length. The tag is usually a characteristic of the MAC function. Maybe it's 128 bits. So it's usually quite short compared to the message. We'll talk about the consequence of that later, but for now it's a short value. And the MAC function, like an encrypt function, the MAC function produces random looking output. When we encrypt a message, we get random looking ciphertext. When we apply a MAC on a message, we get random looking tags. That's the assumption. So we get a random value T1 as output and we send from A to B, we send the message combined with the tag. This is a concatenate operation and we've agreed that our protocol for communications is I'm going to send you a message and at the end of that message is going to be, let's say, a 128 bit tag. So the receiver, when they receive the message, knows that the last n bits are the tag and the first bits are the message. They know where the split is between message and tag, simply based upon the length. They send it, but we have a malicious user in the middle who intercepts the message. Let's see what that malicious user can try to do. Our malicious user intercepts this message and we'll try several attacks. The first one, let's try and change the message. As the attacker, I want to change the message forward on to B, hoping B gets the modified message and doesn't realize it. If we do such an attack, then that's, if B doesn't realize, then it's a successful attack. So they modify the message. What do they send on? They change the message M1 and they change it to another value. Let's call it M2, where M1 and M2 are different. M1 was decreased Steve's pay by 10,000 baht this month and the malicious user changes it to increase Steve's pay by 10,000 baht this month. So they change the message to M2 and in this first attack, they send the modified message. It's the same length as the first one and they simply attach the original tag T1. They don't change the tag. So they send M2, concatenated with T1, that arrives at B, B does the check. And just to recap what we do at the receiver. When we receive a message, we calculate the MAC of the receive message and compare that to the receive tag. Let's try. We receive M2, so we calculate the MAC. B, I'll denote T3 is calculated from applying our MAC function, the same one that A used. We use a key and we apply that on the receive message M2. What key do we use? We use the same one that A would have used. B and A are communicating. So when B receives a message from A, it's going to use KAB in this case. So this is the first step at user B. Calculate the MAC of the receive message using the key shared with the sender. The sender is A. It's not the malicious user from B's perspective. It thinks it came from A. And now compare. And we say does T3 equal, is it the same as the receive tag? In this case, T1. That's the comparison operation at B. We compare the calculated tag, which I denoted as T3, with the receive tag, T1. Are they the same? And to answer, think about the properties we stated at the start about encryption and similar properties apply for the MAC. Will T1 equal T3? Why not? Because the MAC function, the same MAC function has been applied on two different messages. And the same property that we saw with encryption, if we encrypt two different plain text, two different messages with the same key, you'll get two different outputs. We assume the same property for the MAC function. Here we have applied the MAC on M1, using KAB and got T1. We applied the same MAC function using the same key but a different message. And the assumption is that we'll get a different tag as output. So we'll have the same properties as an encrypt function. Two different messages, same key, will give us two different outputs, two different tags. So are they equal? No. What does B do? What are your B? What do you do if they're not equal? Guess, request, first thing. What are we trying to do? What's our aim? Our aim's not to decrypt, our aim is to verify that the message we sent is A, not modified, B came from A. Are we sure that this message is not modified and it came from A? No, we're not sure because, and we know that something's gone wrong because if it did come from A and it was not modified, then the tag should be the same. If nothing was changed, if it was still M1 here, then the tag we get as output, T3, should be the same as T1. If they are not, something's gone wrong. What's gone wrong? We don't know, but we don't care. We assume there's some error and ignore the message. Ignore it or report this error back to A using some other means. So don't trust this message is the outcome here. If the tags don't match, don't trust the message. Delete it because someone has either modified it or maybe they've pretended to be A. This works if the assumption is similar to our symmetric key encryption and we'll write it down to be clear. The MAC of two different messages with the same key, that's what we had in this case, produces different tags just to be clear. This is our assumption of our MAC function. Take our function, apply using KAB with two different measures, we'll get two different tags. That was this assumption that we had with encryption. Encrypt two different plain texts with the same key get different ciphertexts. So we have the same assumption for applying our MAC. That's why there's similarities between a MAC and a symmetric key encryption. Our attack was unsuccessful because the malicious user tried to modify the message to get me M2, but B detected it was modified or at least detected something went wrong. And that's how we provide security with authentication. We can't stop someone modifying the message but we can detect something's gone wrong and therefore not trust that message which provides our security or authentication. I know many of you are much more malicious than the user just went through. What are you gonna try next as an attack? Can you be more malicious? What are you gonna try as another attack? You want B to be fooled into thinking the message received is the original one. Here we just changed the message M1 to M2. What else could you change? We changed M1 to M2. That is the plain text. What else could we change? T, let's try. Try and change the tag as well. Any questions on this one before we delete it? Right, in this case, the malicious user, we're assuming doesn't know the key KAB, okay? So KAB is shared between A and B. It's a shared secret key and we're reverting to our original assumptions. If it's a shared secret key between A and B, no one else knows it. Now if we used Diffie-Hellman to exchange it, we saw that a man in the middle attack may have allowed someone to know it. Let's assume we've got a way to defeat such an attack. Sometimes men in the middle attacks, we've got other ways we'll see later to stop those attacks. Or maybe KAB was exchanged by a piece of paper securely through some other means, okay? So no, the malicious user doesn't know KAB. Let's try a different attack, slight modification. And what we'll try, almost the same, but try to modify T as well. A and B, A will do the same thing again. A calculates the tag T1. They both know KAB. The malicious user doesn't know KAB, that's our assumption. We calculate the MAC of our message M1, obtain the tag and send it. We send the message, concatenate it with a tag. So that's the same as before. Our malicious user intercepts. They change the message from M1 to M2 and instead of concatenating the existing tag, they try to calculate a new tag. Let's call it T2. Given the modified message M2, they try and calculate a tag for that modified message. What do we fill in here? What do we fill in in the space for the MAC function? K, K what? Or what can we not use there? KAB is not possible. That is, the malicious user generated a new message. Their fake message or modified message M2. They know if they keep the old tag, it won't work, it'll be detected. So what they try to do is modify the tag. They would like to calculate the tag of this modified message M2. So they know the MAC function, they know M2. They need to use a key here. They cannot use KAB. They don't know KAB. If they did, it wouldn't be a shared secret between A and B. So if they want to do this, they must use some other key. Let's denote it, the key of the malicious user. Just to make it clear, the key of the malicious user is not KAB. Doesn't matter what it is, but it's not KAB. We attach T2, send it to B, and B goes through the checks. We calculate T3, the MAC using key, what? What key? Key A, B. Message came from A, I, M, B, use key KAB. Of the received message, M2, and compare. We ask, does T3, the calculated value, equal, is it the same as the received tag T2? What do you think? Assuming the same assumptions of symmetric key encryption. Sorry if you can't see on the right, this is M2 here, and this is T3, yeah, okay. Does T3 equal T2? No, it will not. Why not? Different key. Same message, M2, M2, apply the MAC function, but using a different key will produce a different tag. That's our assumption. If you apply the MAC function on the same message, but using different keys, you'll get different tags. And that's what we assume with symmetric key encryption as well. If you encrypt the same plain text using two different keys, you'll get two different ciphertexts. So no, it does not equal T2, and we assume there's an error. There's an error. Don't trust this message. And this assumption was that the MAC of same message using two different keys produces two different tags. Similarities with symmetric key encryption. Encrypt to the same message with different keys. You'll get different ciphertexts. Or the other way, encrypt different messages with the same key, you'll get different ciphertexts. We assume the MAC function has that same property. Different keys, same message, you'll get different tags. And the one above was different messages. Same key, you get different tags. And if those properties hold, we see that when the malicious user tries to change something along the way, B detects it because the tags don't match and therefore doesn't trust the message. And essentially the authentication is provided because we know which messages to trust and not to trust. What could you do as a malicious user? You want a full B. What are you gonna do? Find the key, okay, find KAB. If we did find KAB, the attack would be successful. So authentication depends upon that the key KAB is secret. Same applies with encryption. Make sure the key is long enough such that a brute force attack is not possible. If the key is too short, the attacker could try many possible keys and eventually get the right one. So the key must be large enough to prevent brute force. Anything else the attacker can try? Change both K and M to generate the same tag. That is, if we could, we changed M from M1 to M2, we have a different key. If we could have these values, K malicious and M2, such that the output T2 is the same as T1, then the attack would be successful. Because if T2 was the same as T1, then actually in the previous one, sorry. If we can produce the same tag, let's scroll up in this attack. Let's try one more and see it work. Our assumption so far, if we calculate the MAC of a message with some key and get T1, then if we use a different key on the same M1, we'll get T2 different than T1. And similar, if we use the same key, so this is summarizing what we've seen, the same key and a different message, we'll get a tag where T3 is different than T1. Change the key, get a different tag. Change the message, get a different tag. What if the assumption didn't hold? If the assumption didn't hold, then we can do a successful attack. And we'll look at the attack in a moment, but will the assumption hold? And let's come back to the lengths. We said the tags are generally short, shorter the messages. So let's consider some simple cases. Let's say the tag, put some numbers to it, the tag is five bits long. In practice, they're much longer, but we can use that as the simple example. And that the message, let's say a message, our message M is 10 bits. How many messages are there? How many possible messages are if our message is fixed with 10 bits? Two to the power of 10. We can say there's M1, M2, M3, up to M1024. Two to the power of 10 possible messages. How many tags are there? Five bits, there's two to the power of 32 possible tags. Our MAC function takes a message as input and produces a tag as output. Can two different messages lead to the same tag? Why? Our input has 1024 different inputs, messages. The number of outputs possible is just 32. So some of those inputs must map to the same output. We don't know which ones, but some messages, maybe we encrypt message M1 and we get T2, M2 maps to a different tag, but some messages must map to the same tag. Because the function takes the inputs and maps them to the output. When we have more inputs than outputs, some of those inputs must map to the same output. So when we have a short tag, shorter than the message length, then some messages will map to the same tag and our assumptions will no longer hold. That is we may be able to have the MAC of two different messages and get the same tag. But we said that that wasn't the case. The MAC of M1 and M2, we said gives T1 and T3, we assume that there'll be different tags. And if they are different, our system is secure, but we just see now that if we have more messages than tags, they may be the same. So our assumption is not always true. Some messages will map to the same tag. And if the attacker can find two messages that do map to the same tag, then they can successfully do a modification or a masquerade attack and it will go undetected at B. So that leads to some characteristics of the design of a MAC function. We want a MAC function where two different messages produce two different tags. But in practice, it's impossible because we also want a MAC function that takes any size message and produce a fixed, usually short tag. The reason for a short tag is that we need to attach it to the message and send across the network. If we attach a large tag to the message, we increase the communication overhead. Every message we send, we need to send a large tag. So we want a short tag for performance, but with a tag shorter than the message length, we will have some messages mapping to the same tag. And therefore, it may be possible that the attacker can be successful. So the security of the MAC depends upon how hard it is for the attacker to find those messages. Find two messages, M1 and M2, such that when we apply the MAC with the same key, we'll get the same tag. If we can find those two messages, then we can defeat the authentication mechanism of using a MAC. Okay, that's the concept. How do we make that hard for the attacker? How do we make it such that, even though it's possible in theory in practice, it's hard to find two messages that produce the same tag. Increase the tag length. If we have more than five bits, let's say we have 128 bits. So they're two to the power of 128 possible tags. Again, if our message is larger than 128 bits, multiple messages will map to the same tag. But still, the attacker must find two messages and note that not all messages make sense if we rely on the structure. They must find two messages which both of them make sense so that they can do a modification, for example, and that the modified message can be useful for the attacker. For example, the original message, decrease Steve's salary by 10,000 baht. The modified message shouldn't be random characters, maybe it's increase Steve's salary by 10,000 baht. Now the challenge for the attacker, find that message such that we get the same tag as the first message. And that becomes difficult as the number of tags increase. So the fewer tags, the easier it is to find the message. Therefore, the security of a MAC depends upon the tag length. And in general, the attacker must, in an attack, try to find a message that produces the same tag, they need to try all possible tags. That was maybe a bit much discussion of the concept. Let's return to our examples to recap and get one more example before we finish. So, authentication with a MAC. Send the tag with the message. The receiver verifies by calculating the tag of the received message and comparing it to the received tag. If they're the same, everything's okay. If they're different, don't trust the message. It works, at least in the two cases we've seen, it will work if you take two different inputs, you'll produce two different tags. But if the attacker can find two different inputs to produce the same tag, it won't work. The system is insecure. So it must be difficult for the attacker to find two different inputs that produce the same tag. Let's see one more. Do we have space? Questions on these two attacks first before we show another one. Questions on attack one. These attacks and this role of authentication comes up when we look at other techniques as well, hash functions, digital signatures. Any questions on attack one or two? These are modification attacks. The malicious user tries to modify the message. Try to perform a masquerade attack. See if you can draw the picture for a masquerade attack and see what happens. And as a hint, and I'll let you do it for a few minutes, as a masquerade attack, there is no user A. There's only the malicious user pretending to be A, sending a message to B, hoping that B thinks it came from A. See what the malicious user needs to do for a masquerade attack. Try it. The masquerade attack involves just the malicious user sending a message, but pretending to be A. That's the idea of masquerade. I'm malicious. I'm gonna send a message to B and the source or the from message, the from field in the message was saved from A. Send to B. Pretending to be from A. Right, we denote the message. T1, where T1 was calculated. What key? Well, not KAB. The key of the malicious user. We send it to B saying it's from A. B does the check. B calculates the tag of the received message. M1 was received. And it received this message from A. Or so it thinks. Therefore it uses the key shared between it and A, KAB. Does the calculator tag equal the received tag? Does T2 equal T1? Our assumption is if we use two different keys on the same message, we'll get two different tags. So if that assumption holds, then the answer is no. They won't be equal. Similar to the previous attack. The MAC of two, the MAC of the same message using two different keys produces two different tags. But of course, if this assumption didn't hold, if the attacker could find, in this case, it could find a message when it applies its malicious key, gets a tag T1, such that that tag T1 is the same as the tag when we take the same message in a different key, KAB, then this attack would be successful. That is if T1 and T2 were the same, B thinks everything's okay, when in fact the message was faked from the malicious user pretending to be A. So it relies on these assumptions. You can't find two messages that produce the same tag or you can't use different keys to produce the same tag. So the assumption for this one is the same as the previous one. If we have two different keys, but the same message will get two different tags. Anything else the malicious user can do? Those three attacks didn't work. First one, change the message only. Second one, change the message and the tag. First one didn't work because the two tags were different. We had two different messages. The second one didn't work because we didn't know KAB and this masquerade attack doesn't work because we don't know KAB. Anything else we could try? Yep. In this case, there is no A sending. A masquerade attack, you pretend to be someone else. There is no cipher text here. This message is plain text. There is no confidentiality provided in these examples. So we can see later we could apply encryption for confidentiality, but we're just providing authentication. So the message is always known by the attacker. So this is a scenario where we don't care who sees the message, but I care that it's received correctly. So here, what the malicious user does, it just makes up a message, M1. Like they create an email. They create an email, they write the message, they attach at the bottom of the email a tag, T1, and they send the email and they set the from address as user A. They pretend the message is from user A. User B gets that email. Think it's from user A, therefore they calculate the tag and compare to the received one and finds they don't match. So you can, in this case, there's no confidentiality. What else could you try as the attacker? Brute force key, again, we can't brute force a key if we make it long enough. Find two messages which are different that produce the same tag. If we could do that, we'd be successful as the attacker. And in general, brute forcing the key or finding two messages that produce the same tag are the only two solutions for the attacker. Brute forcing the key depends upon the key length. Finding two messages that produce the same tag, attacks depend upon the tag length. Make the tag large enough, make the key large enough and the attacker will not be able to defeat this authentication. Let's return to the slides. Next week we'll look at these variations. Basically, they combine authentication with encryption for confidentiality. We'll talk about them next week. Let's just summarize what we know, not in much depth. The aim of the attacker, we assume the MAC function is known. The key is not. What they want to do for a tag, the MAC code here, MAC code code for a tag, find a particular message or another way to think of it. To find a message that produces a particular tag, the same as an existing tag. And to summarize, the main points are two different approaches. Find the key, the effort depends upon the key length. The key of k bits, the effort for a brute force attack requires two to the k attempts. Make the key length large enough and that will take too long. Or try and find the tag without knowing the key. There's an approach, but it essentially depends upon the tag length. If we have an n-bit tag, we need to try on average as many possible combinations as for that n-bit tag or two to the power of n attempts. We may see that attack in a simple example next week, but the end result is that the attacker either has to break the key or try all tags. So the security of a MAC depends upon the key length and the tag length and in fact the minimum of those two. If my key length is 1000 bits, my tag length is 40 bits, the effective security of the MAC function is 40 bits. It depends upon the minimum of the two. I think that's a place to stop. We've gone through different concepts. What you should try to pick up from authentication is if we have these assumptions hold, understand why the attacker, when they do a modification attack or a masquerade attack, why the attack will be detected. That's important points. We'll recap on MACs next week and then move on to hash functions for authentication.