 So we present an authentication encryption algorithm based on EES. Why we focus on authentication encryption? We see yesterday Kino's speech speaking about what's so important about authentication encryption and the context. And the reason is mainly because the cryptography is not only about encryption. It is about encryption, but also about encryption. Encryption several times is not sufficient for many applications. For what you need to do, you need something more. And sometimes you need even only the authentication. It can be what you really need in specific cases, and this is specified also as some standard. When we speak about authentication encryption, it's basically a function which has a plain text and a key and gives you back a cycle text and a key which is the authentication mark. And you can have also an additional kind of data is authentication encryption with additional data. With associated data is A, the data which are transmitted in plain text. And you get the A also the output of the authentication encryption. You can build authentication encryption schemes using different constructions. One of the construction is requiring the use of a nose. And the nose is a nice thing for the designer because it allows you to make some hypothesis and exploit the fact that there is a freshness. The nose is a number which is used only once for each authentication encryption. Nevertheless, this is a warning slide which is taken from the direction of authentication encryption last year presentation. You have a nose which is added to the authentication encryption scheme. So you have the N coming together with the key, the plain text and the additional data, the associated data. But when you implement the warning as a designer, even if the nose can be even a counter or something like this, you have to enforce the presence of the nose somehow, maybe with a secure apron or whatever. Nevertheless, you must be warned that sometime, even if your scheme for seeing the use of a nose, it must be difficult to enforce. So be aware when you do construction with the nose that you have to implement it. One of the most used authentication encryption schemes based on the nose is the OCD. OCD is starting with an initialization function depending on the nose and the secret key, which defines delta. Delta then is incremented again depending on the key and on specific functions. And with these two functions you can perform the authentication encryption of each message by XORing with the delta, encrypting with the block cipher, which is a yes. XORing again and you get the cipher text out. So you do vertically authentication with this of the messages. Then the last part is you do a checksum of all the messages. And this gives you the tag and the addition to the other. So what is nice in this scheme is that you just have one core of a yes per block, 120 bits. And you can see that it's perfectly parallel, so you can easily parallelize this thing, which may lead you to an I through. But certainly more the security, only forger is possible when you have the nose to use. And then you support the associated thing. So it's nice, you have some nice properties of this algorithm. But there are also some droplets. So the decryption is not the same as the encryption. So you have to add the support for the encryption to implement it. If you want to implement this in a lightweight fashion, you have to remember that you have to use four states for implementing the key, the incrementation of the delta, the messages for computing the checksum, the state of the yes. You need four states of 128 bits, which is pretty big of a writing time sphere. And finally there is a patent pending, which may be very big. This incentive in use is depending on the policy of the company as much as the cost. It may be a very big effort. Again, if you move to another authentication encryption scheme, which use NOS, we have ASC1. ASC1 derives the X from the counter, key 1 0 and key 2 0. From the counter, key 3 0, again as described here, it takes the function. The counter is then passed through four rounds of the yes. You have the link here with the message. We get the ciphertext. And then you propagate the chain here with the state to compute. At the end after the final exploring with key 3 0, the target. The key schedule here is derived from the key schedule of the yes to 156. The world design is serious. So which one are the good things of this ASC1? Is that you have only four rounds of the yes here. So performance wise compared to the ten rounds of the previous algorithm are nice. And the decryption and decryption are similar. There is a very little override if you want to implement the decryption using the same device. Nevertheless, you need four states of 128 bits if you want to implement this. So the area of error for implementing in low, constant life with average PTR. Then is serial, which means you can't parallelize it. Unless you have an assumption that you should do many, many things in parallel so you can still see it. This can't be parallelized. I hope you've seen the messages before. One, two, and three is here in serial. Security wise, you can do state over when nothing is used. But one of the biggest drawbacks is that it's very slow when you do it in compact implementation in ASIC. Because the key schedule derived from the ES256 is pretty complex. So you need to reach a specific key to derive the key you used for the first thing. Then you have to roll back the key to arrive to the other specific key you need to do the other key here and so on and so forth. So you need to go on, forward and backward with the keys. Which, unless you want to spend more, I think another register of storing the intermediate value of the keys to arrive is taking a big amount of time and a huge timing over us. This is not the best way to analyze the implementation. And finally, it doesn't support associated data. So being this, the picture of what is our goal. Our goal is to design, design, and dedicate an application to the creature's key, which would require less operation than average compared to OSCB. Resulting a very compact implementation in hardware. Which means supporting encryption and encryption in a more way, in a more aerial way. And the low power and energy figures, compared to the other hardware. And the good news software, both is embedded and in PC with AS&I instruction. Also we want to rely on some existing cryptanalysis, in particular the one of Pelikan and the one of London. Based on this goal, we propose a authentication likelihood encryption. The dates of the algorithm that we picture in this block diagram. There is the initialization phase here, the associated data here, the messages and the tag file. The first thing is the initialization with the nodes. And you encrypt AS with the key. And this is going to enter the key schedule of AS here. The second part of the authentication is the same thing here. Starting with zero, you encrypt the zero with the AS. And then this is the input of the AS. You do another complete round of AS using the key schedule, coming from this one. And then you begin to add the associated data, if they exist. The associated data are added with four rounds of AS. And then you propagate XOR in blocks by block here. The key schedule is taking four, key schedule of AS, and then you complete, till you finish the associated data. Then you can begin to add the message. You XOR the message, and when you XOR the message, then you use again four round of AS using the Lex-Leak, which is the beacon in this figure. For the whole round, you pick up this four-byte. For the even round, you pick up this four-byte. And you end up having the data you need to XOR with the message. The final step is encrypting everything with AS, again completing with the key and get the tag file. That's the work feature describing the algorithm proposed. And we can see the advantages and disadvantages of what we designed. Among the advantages is that including the initialization, excluding the initialization and finalization, we have four round of AS service. So it's not the peak of the random types of computation. The encryption and the encryption is similar, is what is wanted, what is designed. To implement all of this, we need only two states of 128 bits, so it's pretty lightweight. And the results are very compact, easy implementation. Also supports the associated data, so it's exactly what we designed it for. Among the drawbacks is that it's serious. Still, you can't parallelize it here. And you can do state recover with it, when the nodes are used. Security-wise, the assumption we made for it is that the first term is no subtracting adversary, which means a node is used only once with the same master key. And the second assumption is abortive verification failure, which means that no additional information is returned if the tampering is detected. In particular, we don't give anything about the planer's background. The claim for it is this T, R3. The first is the state recover. The state recover with complexity T data blocks succeeds with probability at most T22 power of minus 128. The K recover is the same probability of success. And the forger without state recovery succeeds with the probability at most T22 power of the claim to the algorithm. And as we were implementing targeting lightweight, we implemented and we evaluated in lightweight ASIC and Dorsun software. So the lightweight implementation of ASIC was carried out starting from the smallest existing AS architecture presented so far, which was in 2011 Europe. And thanks to Axel Boschman for sharing the source code of the implementation. So starting from this, we modified to support the next leak of AS and to be at some control state to carry on and compute correctly the algorithm. Comparing with the state of the art, we did implementation in hardware using the same technology and the same AS starting point for several algorithms of identity data encryption including OCP and the other CBC data. We ran a bunch of synthesis using very different technologies ranging from high speed technology, low power technology, old technology leak technologies, small technology, open technology and we reported the table only the technology we the result we have we testing microelectronic 65 nanometers using the low power HPT library which is specifically designed for low power having low leakage but is a bit larger compared to the other. And we synthesized using the synopsis using standard option to the tool. We were passing only the idea of we were pushing the tool to minimize the error and we synthesized the design with 20 megahertz. Also we arranged a different we synthesized with different range of clock constraints we were able to successfully synthesize up to 200 or 300 megahertz depending on the specific level but we reported in this table only the one 20 megahertz because for life we typically clock it's not the constraints while paying power at the area. The data reported here for the implementation we see the gate equivalent which is slightly different from one implementation from one library to another because it's not perfect a division you do with the reference gate but this is this is what we get for less T65 low power. The number of clock cycles per block 100.7 the overhead which is the initialization and the power computed with an energy is reaching the utility of the gate of one library. What we see from the table is that the overhead of A compared to the reference say yes it's meaningful there are few gates also when we have to add the control for support in the distribution but the amount of clock cycle is very reduced because we don't have the complete A.S. This graph shows when you reach the optimum compared to the overhead which is basically around this point roughly 200 300 messages and you see the table is here. Concerning the software implementation we used two target platforms we estimated the embedded one because we are optimizing currently for microcontrollers that are not available yet and we implemented one version using Sandy Bridge 3.1 gigabit using the A.S. and I instruction why one should ever run a lightweight algorithm on Sandy Bridge technology 3.1 gigabit is that one of the possible reasons is that those lightweight device sooner or later have to send the data somewhere to a server and the server has to connect probably doing the encryption communicating with the creature so the server has to communicate most of the time as the communicator with lightweight implementation so it makes sense to consider also the performance of lightweight algorithms on the machine. How do we compare the parallel implementation we implemented in a parallel fashion of course and when there was no possible parallelize the implementation because they were silly like me we make several instances imagine that we have different messages arriving in parallel I think parallel implementation of the message we assume that we have different screen types the standard Sandy Bridge we used is normal desktop at 3.1 gigabit per second and we repeated the measures 100,000 times and we average to get the numbers we stable reports the software implementation on Sandy Bridge depending on the message length of 128 to 156 and so on so far the performance of A on the last line and the star on the table means that those are not parallelized are the one where you have several instances in parallel but because it's not parallel as we can again this table shows the overhead of the initialization and the finalization and when you reach the optimal finally it's still under development of the library implementation of the library devices but we can estimate based on the assumption that usually serial construction do not have a very large overhead we can estimate that should reach an improvement in time 2 to 2.5 faster than ASUSB this is an estimation we come to the conclusions we develop the we propose dedicated nodes based on encryption with associated database on AS we used some print analysis of Pelikan Mac and Lex to derive the security and analyze the security of the algorithm we propose implementation which has a small hardware footprint and we prove it comparing with the state of the art and implementing using the smallest ASS base system and we get the first after measurement we get the first after performance measured with ASNI and we estimate the better ones available if you have any questions thank you time for question and comment okay so I have a question it's a very general question not for ARE so we use ARX or Xbox for non-media it was next one so which one is better in view point or the right way it depends what's your goal we try it with a bunch of also during the synthesis we switch between different as box of ASP proposal far we use the one proposed by Canva we use just to look up table like from the tool synthesizer for you we use version proposed by Mantens we use couple of other version which are supposed to be more resisting in the task it's really depends if you're looking for power the best one is the one published if you look about area if you look about the overall optimization considering also the developing type but if the IP property available is the table because the tool does a decent job so the answer is not really which one is the best which one is what you want to any question or comment ok let's thank you ok