 So, as you might have guessed, I'm going to speak about IBS and how to build them generically using some kind of Mac. So, my talk is going to be somewhat classical. First, I'll try to explain why we thought it was an important problem, how people already tried to tackle it, and how we managed to solve this issue. Then I'll present our new primitives that's an affine Mac, so how we define that, what the security property around, and we propose to instantiation to show that it's easy to build. And then I'll try to explain how we move from an affine Mac to an identity-based encryption. So, an identity-based encryption, it's a nice primitive that was introduced by Adish Amir, where you have two users, Alice and Bob, and as usual, Alice wants to transmit to Bob some encrypted message. But contrary to the standard setting, Bob doesn't have a public key. And so, Alice is reduced to use Bob identity to be able to encrypt the message, and the identity can be anything, it can be a phone number, an e-mail address, the ICR membership number if you want. So, let's go back into the history, so the problem was introduced in 84. Then we needed to wait for 2001 to see the first instantiation by Bonnet Franklin and Cox in the random miracle model. Then if we waited a little longer, we have the first instantiation in the standard model by Bonnet Boyan and Waters. And waiting a little more, you have an instantiation by Waters, and last year by Shen and V, using the dual system framework. And, sorry, last year, paper, last year, crypto paper was the first IB proven with a tight reduction. And in fact, you have plenty of other schemes, but every time you have another construction that starts from nothing, and that's not really interesting, because what we'd like to have is to have a generic way to build an IB, so to have a primitive from which we can start. And we know that if we have this primitive, then we will be able to have an IB. So, for example, for signature, we know that we can start from one way function and be able to build a signature. For CCA2 encryption, we know that as soon as we have a hash proof system, we can have a CCA2 encryption, but for IB, we don't really know. So, if we consider a map of some standard primitive in cryptography, so IB, signature, and MAC, we know, thanks to the narrow transform that you can, starting from an IB, you can have a signature. The public key and secret key of the signature are going to be the public key and secret key of the IB. The signature itself will simply be the user key generation from the IB. And to verify the signature, you simply encrypt a message under the identity, under the message of the signature, and you try to decrypt using the signature. If you recover what you picked at the beginning, then the signature is valid. You are in 89, there was another transformation from a MAC plus some non-interactive zero hash proof to a signature. Now, this time, you commit to the secret key of the MAC, and to generate a signature, you are going to build a MAC on the message and then do a zero knowledge proof that the MAC is valid with respect to the committed secret key. So, of course, you can go from a signature to a MAC by simply not publishing the public key. And for completeness, there was a transformation in 2012 from an IB to a MAC. But as you can see, none of these arrow end up on IB, and we wanted to try to find a way to do so. So, I'd like to come back to the transformation from MAC plus SNESIC to signature. So, as I said, you start from the secret key of the MAC. You commit the secret key with some randomness, and then you're going to keep the secret key of the MAC and the randomness as your secret key for the signature. And then to sign a message, you simply compute the MAC on the message using the secret key, and then you do your zero knowledge proof that, indeed, this MAC is valid. So, as I said before, valid means it's indeed with respect to the secret key committed previously. And to verify the validity of the signature, you simply verify the validity of the SNESIC. So, okay. Now, let's try to do a parallel with the null transform. So, now, what happens if instead of wanting to build a signature, we try to build an IB? So, first, we replace the name of the scheme, so that is a part. Then we know in the null transform, the secret key of the IB is the secret key of the signature. The public key of the IB is the public key of the signature, so nothing changes. Then we know that the user key generation, the IB, is the signature. So, let's say that, okay, here we can still do it. And now, that's a tricky part, because the verification of the signature is supposed to be the combination of two algorithms from the IB, because you are going to decrypt an encryption. And here, we are somewhat stuck because we need to define two functions using only one algorithm that's supposed to output a bit. So, that's what we are going to propose is to find a way to use this verification algorithm to define encryption and decryption. And for that, the idea is that we are going to need to exploit some kind of underlying structure in the combination Mac plus SNESIC. So, here, that's what we propose, how to build an IB and even an hierarchical IB using an affine Mac and pairings, or any system that's somewhat affine with SNESIC. So, we are going to show how to build an asymmetric primitive using a symmetric primitive. And so, an affine Mac is just going to give us a set of affine equations or affine relations. And the pairings, for example, are going to give us some kind of zero knowledge proof that are going to be some tweaked growth-side proof and an affine verification. And so, those affine properties are going to help us define our two algorithms, encryption and decryption. Because intuitively, the growth-side verification, it's a pairing product equation with elements that are going to come from the signer and elements that are going to be public at the beginning. So, to encrypt the message, you are going to rely only on the public element at the beginning. And to decrypt the message, you are going to use the rest of the equations that rely on the secret element. So, now let's move to our affine Mac. So, as it was explained already, lots of time yesterday, we are going to use the bracket notation to simplify the writing in our scheme. So, the bracket notation, you have a group that generated by some group element g, a matrix of a scalar. And when we denote the matrix with a bracket around, it's just g raised to the scalar. So, a Mac is a set of three algorithms, a set of algorithms that's going to generate the secret key, a tag algorithm that takes a message and the secret key, and outputs a value, and a verification algorithm that takes the secret key, the message, and the tag, and checks that the tag is indeed valid under the secret key with respect to the message. So, here, for our affine Mac, we are going to want the tag to have some specific shape. So, first, a random vector, t, that's going to be completely independent from the message and the secret key. And then an element, u, that's going to link t, the secret key, and the message together. And this part, u, is what we are going to call affine. So, let's go a little more into the detail. So, the secret key is going to be in two parts. So, first, a set of vector x, so that's going to be in blue for the rest of the talk. And then a set of scalars, x prime, that's going to be the second part of the secret key. So, to tag the message, so first, we generate a t at random. So, random will depend on the security assumptions that we use. It can either be uniform or some pull according to some distribution. And u is going to be our tag, so it's going to be affine. So, we are going to have two sets of public functions, fi and f prime i. And we are going to compute the sum of the fi applied on the message times the first part of the secret key times t plus the sum of the other function multiplied by the second part of the secret key. So, this fi will really shape our instantiation, and then there can be anything. So, we can consider fi to be the identity. It can be a constant function equal to 1. You can have some things like fi is equal to 1 if mi is equal to 1. So, there can be anything. And then, to verify the validity of the MAC, you simply take the tag, use t to recompute the value u, and check if it's equal or not. So, for the security of our scheme, we are going to define a slight variant of the standard security of the MAC, of the tag. So, usually, we rely on USTMA. So, that's after creating several tags, the adversary should not be able to generate a new one. And here, instead, we are going to use a decisional variant. So, after creating several tags, the adversary will host for a tag on a message, and he has to decide if the simulator gives him the real tag or a random value. So, intuitively, the PRCMA scheme should be USTMA, but the other reaction is not necessarily the case. So, we are going to, in the paper, report us to instantiation. The first one is based on a variation of the narrow-angle PRF. So, we are going to use a randomized version and a fine. So, instead of considering the productivity of the exponent, we are going to have the sum of the exponent. And we show the security under any matrix, the fielman assumption. So, this includes any k linear assumptions, a uniform assumption, or the cascade assumption that was presented yesterday. So, the matrix fielman assumption was also introduced last year on crypto. So, to give a little more detail, so the tag here is just a random vector in the zq to the k. And the tag u is going to be simply the sum of the key corresponding to the value of the bit of the message. So, we define function f i b that are equal to 1 if m i is equal to b. And for the f prime, we only consider one value x primate from them. So, such construction was already implicit in last year crypto paper from GNNV. So, as you can see, we need to define lots of x i values. So, we are going to have a linear size parameter. But using some random self-itusability property, we show that the reduction can be tight. And this gives us a tight affine mark for the rest of the talk. So, another way to do that is to use the HPRO system. So, in 2012, it was shown that the HPRO system imply a UFCMA mark. So, in this paper, we show that the KELIN-based HPRO system, or matrix-based HPRO system implies PRCMA affine mark. So, once again, we show that it can be instantiated under any matrix if you have an assumption. So, especially the K-linear assumption. So, the tag is a little different. Now, t is sample at random in zq to the k plus 1. But in fact, in a space, in a subspace of dimension k. The tag is way simpler because we are going to have only two f-function, a function f0 that will be constant equal to 1. And a function f1 that's simply going to be the identity and the message. So, in fact, we show that we can have even more f-function if we want, but that's not useful. And so, the nice thing with this construction is that we have constant parameter. However, we have a loose reduction because we are going to, in the security proof, we are going to have sequence of game where we are going to change the query one by one. So, now we have shown that we can instantiate a fine mac. Let's move to I-B. So, if you remember the first information, so we start from the secret key of the mac. We are going to commit this secret key. So, for each part of the secret key, we pick new random. We commit to this random. So, for simplicity, you can imagine some kind of generalized Pedersen commitment. We just need the commitment. If the commitment is perfectly adding, it's more than enough. So, we are going to have a set of commitments in the public key. To do the user key generation, so the first two lines, we are going to use the mac, simply without any other consideration. And the last line is going some kind of proof of opening of the mac with respect to the committed secret key. And so, here we use the same function f, but instead of choosing the value x of the secret key, we use the randomness used to commit the secret key. So, just to simplify the notation, we are going to note big f, so function. And the only thing that you need to know is that they are somewhat linear in the randomness used, so t and 1. So, to encrypt a message, someone is going to pick s at random. So, once again, random is to take, depending on the security assumption that you use, is going to compute a self-text. So, that's f, those function f computed for now, because the user that encrypts don't know the secret key of the mac, is just going to use the public key, so z, the value commit, the commit month, for the random s. And the key is now going to be the function f prime on id for the same s, using z prime. And to decrypt, so if both ideas are the same, using a pairing, you will be able to cancel the blue part. The user possessing the secret key will be able to cancel the blue part of u and v with respect to c. And the transformation that works on fx, fy to become fz will also be applied on f prime. And you're going to have, is going to compute the value f prime of z prime for the identity under the scalar s. And so it will be able to compute the same value key and so recover the committed message. And here you can show that under some matrix Diffie-Hellman assumption, this transformation is tacked with respect to the mac. So let's sum up. So we've shown how to build an IB using an affine mac in pairings. So instead of studying a complicated symmetric primitive, we can come back simply to some simple symmetric primitive. It was proven under the key matrix Diffie-Hellman assumption, which can compass more or less a huge number of assumptions, like the key linear assumptions, the cascade and the uniform distribution. We have shown how to have a tight reduction using a mac based on the narrow angle PRF. And we can have a compact construction, so with a very short public key using a mac based on the hash proof system. So to give out some numbers, our IB is twice more efficient than last year's IB presented by Shannon V, who was also tight. And in fact, by using an additional trick that's completely independent from our construction, we can reduce the size of a public key to be just directly linear in the size of the message that you're going to sign. So now if we are OK with a loss in the number of signing or encryption query, we can compare to the previous scheme. So we have the same kind of size for the public key. We use a secret key that's comparable, and a size for text that's comparable. But our transformation, at least, is generic and maybe improved in the near future. So there are some other results in the paper that I didn't have time to speak about. So because we have a tight IB, we managed to have a tight signature. And so we proposed a tight signature under 6DH with only three group elements. And that can be done using the standard transformation where you can obtain a tight multi-challenge CCH for encryption. With a reasonable size. We are the first tight IB with anonymity. And we managed to propose a HIV construction. So the HIV based on our angle is going to be tight, both in the number of encryption query and the important thing on the number of delegation level. And the HIV based on the hash proof system is going to be anonymous. And also, as a side result, we propose an identity-based hash proof system. So we are the first identity-based, tight, and based on a non-Q assumption. And this allows them to build CCH2 IBs. And one huge problem that remains is to build an affine mac with tight security and a constant tight secret key. But it seems more easy to work on this kind of primitive to try to do it directly on an IB. So thanks for your attention.