 The next talk will be about a new variant of PMAC beyond the birthday bound by Kanya Suda. Thank you. So this sentence pretty much summarizes what this work is all about. This work provides you a new block-style for model operation, which is based on the previous construction called PMAC. And the new model operation is highly secured and highly efficient. So in the following, the rest of this talk, I'll explain what this sentence really means. So first, I'll give you a brief introduction to MAC. Then I'll talk about work-cypher-based model operation for message authentication codes focusing on PMAC. Then I'll describe what I mean by highly secure. And here, highly secure means that construction achieves security beyond the birthday bound. So I'll talk about birthday bound problems and the security levels higher than that. And lastly, I'll describe what I mean by highly efficient by describing the construction itself and details. And I'll try to persuade you that it's actually efficient. And lastly, I'll discuss some possible improvements to the construction and some future work. So let's talk about MAC's method of authentication codes. MAC is a symmetric key preview. It takes possibly large data and mixes it with your secret key and produces small output. The output value is called a tag. The tag has a fixed length output, unlike the input. And the length is usually very small, like 64-bit or 120-bit, et cetera. And the purpose of using MAC for your data is to ensure the integrity of your data. And there are four ways to make a MAC. One is to design from scratch. That gives you a dedicated MAC preview. And second is to utilize a cryptographic hash function, like MD5 or SHA-1, and a well-known example of this type of construction is HMAC. And the third one is to construct your MAC from using a universal hash function. Universal hash function is a mathematical object rather than a cryptographic object. It has certain properties, but by combining it with some cryptographic hash function, you can construct secure MAC. And lastly, you can use a block cipher. And examples include C-MAC, the NIST standard, and PMAC. And of course, this work focuses on the last method block cipher-based construction. OK, so I'll talk more about block cipher-based MAC constructions. And I'll also talk about the PMAC. OK, so there are two major types of block cipher mode operation used for message authentication code. One is CVC iteration. And one is PMAC, the other one is PMAC structure. CVC iteration is basically your data is partitioned into blocks. And you iterate your encryption of your data. But before you increase your message block, you extra the previous output with your current message block. Then you encrypt that and you repeat that to the end of your message or to the end of your data. And whereas for PMAC, you prepare a special value called the mask in advance. And this mask needs to be updated at each step. And before you encrypt your data block, you extra with your data block with this incremented mask. Then you encrypt your extra value with your block cipher. Then the output value is extra altogether to go into the final process. OK. So, well, here's a very rough compression between CVC iteration and PMAC structure. As you can see, CVC is inherently sequential, whereas PMAC is parallelizable. It's actually fully parallelizable. If you look at the PMAC structure, these masks needs to be updated, but they can update itself. You don't have to look at the implementation of mask doesn't depend on your data. So you can increment your mask offline if you want. I'm sorry. And if you look at the extra operations outside your block cipher, well, for CVC, you only need extra operation. So that's pretty efficient. But for PMAC, well, you need, for each block cipher call, you need two XORs and masking mutation. Usually, masking mutation, mask update operation can be done pretty fast, but not as fast as XOR. So that's a bit slower than just XOR CVC operation. So I'm not going to really argue which one's better, but I'd like to emphasize that we choose PMAC here in this work because of not performance reasons, but for provable security reasons. Seems like because of the power of structure, PMAC seems to have a structure easier to analyze than the CVC duration. And in fact, some of our techniques cannot be applied to CVC duration. So let me explain what I mean by this. So, well, this is the intuition behind this feeling. So when we do security proofs for this type of modification, we have to treat various events and evaluate probability of these events happening. And if you look at the CVC iteration, well, it's sequential. So of course, you have to execute your data block in the order that's defined. And so the order of execution, there's no freedom in the order of the execution here. Whereas for PMAC structure, the construction is fully parallelizable. It means that usually you execute your data block sequentially because that's the most efficient way for mask implementation. But in security proofs, it really doesn't matter which data block you evaluate first. So and this is really the intuition behind why PMAC seems to have a structure easier to analyze from the point of view of security proofs, of course. And then I'll talk about both their programs. OK, so when we talk about security of masks, we usually use the notion of unforgeability. Which means that adversary, without knowing the key, should not be able to produce a valid tag value for new message, of course. And then there's a stronger notion than unforgeability, which is sort of randomness. And as you can tell, the randomness implies unforgeability automatically. If it's really random, looks random, then you can't predict it, so you can't produce a valid tag. And so if a MAC construction is a secure pseudonym function, it's called PRF, then it's also secure MAC. And this is the direction that we follow in this work. OK, so what is the birthday problem? Well, the birthday problem essentially says that if you use N-bit block cipher for your MAC, block cipher based MAC construction, then you only get half N-bit security. Which means that, for example, for using 64-bit block cipher, you only get 32-bit security. If you use 120-bit block cipher, you only get 64-bit security. And for 128-bit, this may not be a big problem, but for 64-bit block cipher, this is a big issue. And 2 to the 32 blocks corresponds to the 32 gigabyte. And we have 64-bit block cipher, not only the old ones, but also new ones, triple S, height, present, and LED. Well, of course, these are either legacy ciphers or lightweight ciphers. And it's questionable whether the 32 gigabyte is a lightweight or not. But in any way, the 32 gigabyte is just way too small. And it's too small number to be a security guarantee. OK, there are two different birthday problems, two types of birthday problems that exist for block cipher based multiplication. One is actually generic. It's not limited to block cipher based, but it applies to any iterated max. And essentially, the existing attack, the existing sort of forgery attack is possible for any iterated max at the half size of the state size. Well, the state size usually is the block size for block cipher based. This is one of the birthday problems. And bad news for block cipher based max is that for CVC type max, there is even a stronger attack that can produce universal forgery. So this is really bad. And another birthday problem that exists for PRP, for block cipher based multiplication, is so-called PRP, PRF switching lemma. Block cipher is, of course, a permutation for given key. And permutation is sometimes not very easy to handle in security proof. So what you do usually is to replace your permutation with a function. And you say that, well, this is secure. PRP means sort of random permutation. But let's just replace it with your PRS sort of function. Well, you can do that, but only up to the half the size of blocks of queries. So this causes another security degradation. OK, so this is our security result. Our construction achieves, unfortunately, not to the 2 to the n, but 2 to the 2-thirds of n. And so, for example, for 64-bit block ciphers, this corresponds to 42.7-bit security. And that corresponds to 51 terabytes. That's a significant gain. And our mark can be proven to be a secure PRF based on the sole assumption that the underlying cipher is a secure pseudo-random permutation. So of course, we don't use the switching lamina proofs. OK, so let's talk about our constructions. OK, before talking about our construction, I'll talk about some previous constructions that appears on a rather old standardization document, ISO 9797. And actually, the ISO 9797 specifies several algorithms, MAC algorithms, box alpha based all. And one of them actually achieves security beyond the birthday bound. It's slightly worse than an hour bound, but it's close. It's essentially the same 2 to the 2 to the n security. Unfortunately, the problem with this algorithm in ISO 9797 is that it's twice as low as the ordinary CBC or PMAX. So that's why it's called the right-half construction. So this ISO 9797 algorithm is essentially the sum of two independent CBC max. So basically, for the same message or for the same data, you compute CBC max twice using independent keys, then you take the sum, and the sum is your final tag value. Of course, you have to do the CBC max twice, so that's just twice lower. OK, so we don't want this. We want rate one. By rate one, I mean for one block of your data, we only want to call our block cipher only once. Rate one construction, so how to do this? Well, we don't want to double the block cipher call because that would immediately lead you to rate half construction. But we can double everything else. So let's look at the original PMAC construction. Here's the PMAC construction. After the PMAC iteration, it goes into some kind of finalization, which is a special form of block cipher call that produces a tag. Well, the masks, let's double them. We use two different masks and increment them in different ways. Block cipher calls, we don't touch them. But for the state size, we double the state size. And of course, we can't just double them because that would produce the same two things. So we have to sum. One state is just extra of all the outputs, but the other one must be computed in different ways. And we do finite feed multiplication by two to do this trick. And I apologize that this actually, figuring the process version, doesn't describe this correctly. That's just, it's wrong. Sorry. And the finalization, let's double them. Well, this increases your block cipher call because this requires two block cipher calls. But only at the finalization. So independent of your message block, this is just one extra block cipher call. So it's not really, it doesn't make it great too. Then we just take the sum and that's the tag. So this is our construction. OK, this is just how all the extra operations essentially done outside the block cipher is the finite field multiplication by two, or four. Modification by four is just that you do the multiplication by two times. And it uses three keys, sorry, one for the internal PMAC iteration and two keys for the finalization. And as you know, the finite field multiplication by two can be implemented quite efficiently. It's just one bit shift plus one conditional extra. So that's very efficient. All right, so I'll talk about a couple possible improvements to the construction and some open problems related to them. OK, so I said the construction requires three keys. Actually, we can make it two key without much effort. We do this for the finalization. Instead of using two independent keys, we can use the same key, except that now we have to do some tweaking in front of one of the finalization. But that can be done by, for example, multiplication by two. So that's fine. But after this, at the moment, we don't have ways to make it one key construction. The independence between the key of the PMAC iteration and the key of the finalization seems essentially in many places of particular deep proof. And we have a software, no clue how to make it one key. So this is an open problem. And another problem is that the security, two thirds of N. So one idea is instead of doubling, why don't you just chip everything? Well, that may work. But that doesn't give you still two to the N. It only gives you two to the three and over four at best. And you can do this four times, five times. But it doesn't give you two to the N security. And plus, tripling or doing four times, five times, it gives you a very large state size. And now you can still call it the rate one, but not practically efficient. And another point is that the bound may not be tight, two to the third, two to the two and over three. We don't know any attacks that break our scheme at this complexity and the proof may be improved. And thank you. That's it. While the next speaker is setting up any questions. So we don't need the diagram. We have the two parallel masks being updated at the top. To me, you're exhoring two things together. It's conceptually, it's just a really complicated update of one mask. So does your proof actually rely on the two different? Yeah, yeah. That's actually essential to obtain the security beyond the birthday bound. Because we need two to the, we want two and a bit randomness in evaluating our security because we have that's, and that's how we introduce two and bit randomness in the input of the PMACA direction. We can. OK, thank you. I'll have to read. Bye-bye. Yes. One more question. So the abundance of source and linear operations here gives some intuition that the attacks that may exist between the bound to have proved and two to the end, they might exploit some linear combinations of inputs and outputs. Do you try some attacks of this kind or do you have some non-trivial attacks that are in this gap? No, not really. I'm not quite sure what's, you're talking about the gap between the full security of M-dispand. Not quite sure which, I mean, I'm not quite sure how tight the bound is. So I haven't really explored any attacks, specific attacks. And we're really late, sorry. Yeah, we could take this offline. Sorry about that, we're running five minutes late now. So let's thank the speaker again. OK, the next talk is about authenticated and misused resistant encryption of key dependent data. The paper is by Mihir Bellarian, Suram QVD, and the speaker will be Suram QVD. Hello, everyone, good evening. I'm Suram. I'll be talking about authenticated encryption of key dependent data. This is joint work with Mihir Bellare. Classically, the security of encryption schemes has been captured by the indistinguishability under the chosen plain text attack, or the INDCPA in Ocean of Security. This was introduced by Golwasar and Mikali in 84 in the public key setting, and later by Bellarian others in 97 in the symmetric key setting. Now, over time, we have gained a lot of confidence on INDCPA, and we would regard it as sufficient for many practical applications. But INDCPA comes with a caveat. Messages cannot depend on the key. Now, there are certain applications where we would like security even when the message depends on the key. If we had this kind of security, we could get anonymous credentialed schemes. This was shown by Kamenash and Lishansky in 2001. A year later, Black, Rockaway, and Shrinton showed connections between key dependent messages and formal methods in cryptography. Now, they modeled key dependent messages by deriving the message from the key using a message deriving function, phi. It turns out, apart from these applications, there are several practical settings in which key dependent messages arise. Disk encryption tools, like BitLocker, sometimes end up storing the key use for disk encryption on the disk itself. Often, these keys are derived from the user's passwords, say, with a hash function. And this password could be lying on the disk. And sometimes, the hash of the password could also be lying somewhere on the disk. Because of concerns like these, the IEEE standards for disk encryption, IEEE 1619, rejected one of the candidate schemes they were considering because that scheme had a prominent KDM attack. This is kind of an indication that KDM security is important in practical concerns, too. More generally, we cannot expect users or designers of systems to ensure that the key and the data are not related. Rather, we want to design cryptosystems which are secure, even when the key and the messages are related to each other. And this is about misuse of systems and getting robust cryptosystems. Anyway, coming back to the work of Black, Rockaway and Shumpton, they extended the standard indistinguishability under the chosen plain text attack, INDCPA, to consider key-dependent messages. They provide models, definitions, and they show that this notion, KDM-CPA, there are schemes which are secure in this notion. They describe the following random model scheme. And subsequently, there has been a lot of work in KDM about removing this random molecule and getting standard model schemes which are KDM secure. If we look at these schemes, we find that they are usually, they consider security for restricted classes of message-deriving functions, and they are inefficient and impractical. On the other hand, cryptographers have asked about the possibility of key-dependent messages arising in other primitives. Halloween crotchic considers security of pseudo-random permutations and pseudo-random functions in the presence of key-dependent messages. Back as Fitzman and Skedra have extended the CPA scheme of Black-Rogway and Schimpton to consider a basic form of authenticated encryption. In this work, we revisit key-dependent messages in the setting of authenticated encryption. But we take a more comprehensive view and we focus on the practical aspects. Why? Because arguably, for symmetric crypto, authenticated encryption is the most important primitive going by the extent of usage. So we want to know what are the issues that arise when we think about key-dependent messages in AE in a practical sense. So let's first take a look at authenticated encryption. There is no KDM here, this is standard authenticated encryption. Now, the first thing to note is that, unlike CPA, authenticated encryption not only guarantees the privacy of the message, but also its integrity. If we look at the model of authenticated encryption considered by Back as Fitzman and Skedra, which we will call classical AE, we see that the encryption scheme takes in a key and a message and a random IV. Now, in practice, authenticated encryption schemes are more complex. Not only do they have to deal with the message, they also have to deal with associated data in the form of a header. This header is also provided as input to the encryption scheme. The interesting thing to note is that, the scheme has to guarantee only the integrity of this header, not the privacy. Another change is that unlike the classical AE, in modern schemes, there is no random IV. Instead, there is a nonce, which is provided as input. This nonce does not have to be random. We'll come back to the nonce issue in a couple of slides. So, if we want to look at authenticated encryption and KDM in practice, this is the form of AE we want to look at. And as I mentioned earlier, authenticated encryption is an important practical primitive, so there are many standards talking about authenticated encryption schemes in mobile security, in IPsec, et cetera. And these standards consider AE schemes with a nonce and a header in this form. So now, if we bring in KDM, what are the issues that we have to handle? As always, the message can depend on the key. This is what KDM is about. But now, we also have a header, and the header can also depend on the key. Not just that, the nonce that is given as an input to the encryption scheme does not have to be random. If the nonce is random, we are in one setting. This is the random non-security setting. But there is another setting called universal non-security where the encryption scheme is only guaranteed a nonce that is unique, that is non-repeating. It could be from any source. For example, it could be a counter. Now, it's easy to see that universal non-security is more attractive in practice. It's easier to maintain a counter than it is to maintain a source with good randomness or pseudo-random, good pseudo-random generator. Consequently, the standards that we saw on the previous slides, sorry, the standards that we saw, see here, actually talk about authenticated encryption in the universal non-setting. Let me just go back there. Okay, so we have to, we're starting to see that if we want to look at KDM in authenticated encryption, there are all these things we have to deal with, different kinds of nonces, messages, headers, et cetera. As a result, we're not looking at one object here, but we are actually looking at many variants. The message and the header could both be key dependent or not. And this already gives rise to four possibilities. And we also have random versus universal nonces. So we have to deal with eight possibilities in all eight variants. And the natural question to ask is, can we get schemes, can we get secure schemes in all of these variants? Or can we at least, so there is another issue here. So if we cannot get security in some of these schemes, can we at least show that it is not possible to achieve security? For example, can we show attacks that say that whatever scheme is there in a variant, the attack breaks the scheme? So one thing is easy to do here, if the message and the header are both independent of the key, then we fall back to normal authenticated encryption. We know we can achieve this. We have standardized and secure schemes that achieve security in this setting. So let's look at the other variants. Now we have six variants in all. The message can be key dependent. The header can be key remittant. Or both of them can be dependent on the key. And the nonce could again be random or universal. So in this work, we ask the question if whether it is possible to achieve KDM security in these settings. Our first contribution is a simple and universal, unified way to deal with all these variants so that we don't have to end up, I mean redoing some of the proofs and definitions, et cetera. And we show two attacks. Our first attack shows that with universal nonces, it's not possible to get KDM security. Now keep in mind that the standards that we saw all talked about authenticated encryption with universal nonces. So what this means is that none of these standardized encryption, authenticated encryption schemes can be extended to key dependent message security. This is already somewhat bad. And the other attack that we show rules out security in the presence of key dependent headers. So what is remaining? The only remaining setting is when the header is independent of the key and the nonce is random and the message still depends on the key. We show that it is possible to achieve KDM security in this setting. Our solution to this problem is a scheme, RHD, randomized hashed and encrypt. RHD actually is not a standalone scheme. It's a transform. It takes a normal authenticated encryption scheme and transforms it into one, which is secure in the setting. And it's a very lightweight, simple transform. It has minimal computational overhead. And we show that there are no extra elements being added to the ciphertext, so the overhead in bandwidth is also zero. And it can be thought of as some sort of a software patch that can be applied to a system to make it KDM secure. And we show that RHD is secure in the monocle model. Okay, so in the rest of the talk, I'll be focusing more on the results that I just mentioned, the two attacks on the RHD. So to look at these attacks, I should first define KDM security. And before I do that, let's just quickly recall authenticated encryption security. In fact, one of our contributions in this paper is to come up with a simple, novel authentication encryption security definition. But I won't go into that in detail here. I'll just look at this from a very high level so that we can make sense of that attack that we'll describe later. So when we want to describe the security of a scheme, we think of a game between a challenger and an adversary. And in the beginning of the game, the challenger chooses a random bit B and a key K. This is authenticated encryption security so the adversary can make both encryption and encryption queries. So when the adversary makes an encryption query, depending on whether this B was chosen to be one or zero, the challenger is going to reply either with real encryptions or random bits. There is one thing to note of interest that is if we are talking about universal non-security, the adversary gets to provide the nonce that will be used for encryption. But if you're talking about random non-security, this is not allowed. The challenger will choose its own nonces randomly. This will play an important role in the attack. Other than that, that adversary can make the encryption queries and if the decryption query corresponds to a valid ciphertext, then the adversary will get back a one, otherwise it will get a zero. This is if the bit B is one. Bit B is zero, then adversary will always get invalid decryption. The aim of the adversary is to find this bit B. If you talk about KTM security, the basic structure of the game remains the same. The only difference is that now, encryption queries, rather than taking a message as argument, now have a description of a function, a message-deriving function, fee. And the challenger will evaluate this fee on the key to get the message. Everything else remains the same. Okay, so now let's look at the first attack. Recall that what we're saying here is if the authenticated encryption scheme does not get random nonces, but gets nonces from some arbitrary, non-repeating source, then it's not possible to have KTM security. The starting point of our attack is an earlier attack was presented by BlackRock and Strimton, and their attack was on stateful encryption schemes. So before we dive into the attack, let me just give a high-level idea of what's going on here. The adversary, if you're in the universal non-setting, the adversary gets to provide the nonce. We saw this earlier. So one of the strategies of the adversary could be to embed this nonce in the message-deriving function, fee. Recall that fee is evaluated by the challenger on the key. So fee knows both the nonce and the key. In other words, fee can simulate the encryption of random messages. So here's a high-level idea of what adversary could do. The aim of the adversary here is to get just one bit of the key, K of one. And what it's going to do is choose a random nonce, an arbitrary nonce, and another random string S, and embed them both as part of fee's description. And fee's job is to, fee knows the key, fee's going to be evaluated on the key. So fee's job is to somehow find K one and communicate it back to the adversary. So how can fee do this? The only thing fee can do is output a message, and this message will subsequently get encrypted, and ciphertext will be given to the adversary. So fee does this following thing. Fee just randomly, arbitrarily, chooses different messages, tries encrypting them, and checks if the dot product of S and the ciphertext is the same as the bit of the key. Once fee finds such a message, it stops and outputs this message. The challenger now takes this message and encrypts it, and gets the same ciphertext that fee got, and returns this ciphertext to the adversary. What can the adversary do? It already knows S. It knows that S dot product of S and this ciphertext is the same as the first bit of the key. So it can just recover that bit. In fact, the adversary can repeat this for all the bits of the key, and recover the key completely. This attack seems to work, but there's one problem. We don't know how long evaluating this, I mean, how long five will run for. We don't know when five will find such an M that satisfies the property. So we can fix this. It's easy to fix. The only thing to do is to make sure that fee stops eventually, when it realizes that it has gone for too long. So we do this by, you know, putting a bound on the running time of fee, saying that it can only try L times, but L is a parameter that we provide to the adversary. If fee does not find a required message within L times, it's going to just output some arbitrary message. And instead of a dot product, we are now going to look at a family of power's independent hash functions. So we can show that this works. I'll not go into the details. We can show that if we choose L to be comparable to the number of bits in the key, then we will get an adversary which recovers the key with a high probability. So let's stop for a second and see what we have done here. So this attack is somewhat serious because we are not just distinguishing between B equal to zero and B equal to one. We are actually recovering the key. And maybe this attack is artificial, but it still rules out the possibility of getting schemes that are secure with universal answers. We have a similar attack in the paper that shows how it is not, I mean, how in the presence of key dependent headers, it's not possible to get security. But I'll skip that attack here in test of time. So what do these mean? What do these two negative results mean for us? And we go back to the table of variants that we started off with. We see that whenever we have universal answers, it's no longer possible to get security. And similarly, whenever we have key dependent headers, again, it is not possible to get security. So the most important takeaway is that standardized schemes require universal answers and we can't get KDM security in these settings. This is rather sad. So what is left to do? The only variant where we can still hope to get secure schemes is with random answers, key independent headers and key dependent messages. And we show that this can be achieved by our scheme, randomized hash and encrypt. So our scheme is actually a transform. It takes an existing authenticated encryption scheme and converts it into a scheme that is secure in the setting we saw earlier. And internally it uses a hash function. So this is what it looks like. If you look at the new encryption scheme, it takes in a key L, a non-SAR, a header H and a message M. And from this key L and the non-SAR, it generates a new temporary key K. This is interesting because every time the encryption routine is called, a new key will be generated. And this new key is what is going to be used for encryption. It will be fed to the encryption routine along with the header and the message. Decryption proceeds in a natural manner. Assuming this works, it's easy to validate all the properties we claimed earlier. Minimal computational overhead because the only extra thing we are doing here is making a call to a cryptographic hash function, like SHA-1. And these things are notoriously fast in practice. When we ran experiments with CCM for the base authenticated encryption scheme and SHA-1 for the hash function, we found that the overhead due to this whole process was less than 1% when the message was 50 kP or larger. And zero bandwidth overhead because anyway, for authenticated encryption schemes, we need a nonce. And the only thing we are doing here is using the nonce in a different manner. Instead of feeding it to the encryption scheme, we are using the nonce to generate a key. Similarly, simple software changes. We can just think of a patch that makes a call to a random molecule before actually running the encryption routine. So that brings me to the end of my talk. Thank you. We have some time for questions. No questions, so let's thank the speaker.