 My name is Eli Berstein and today we're going to talk about SHA-1. It has been a joint collaboration with many people, the four, the five people who were helping were Max Steven from CWIP, Pierre Kaepermann from NREA, Angelle Bertini, Yarek Markov, and Alex Petty-Bionco, who are also from my team. And today I'm going to tell you about how we created this SHA-1 collision. Before that, I will tell you a little bit about the story about how you do cryptanalysis and breakhash function and then we'll talk about what happened in the past collision world. We had a little bit of problem with the calibration of the video projector, so I tried to shrink down a little bit of slide. Everyone can see them correctly? Yes? All right, awesome. So let's get started. To make sure everyone is on the same page, let me briefly recap what a hash function is. A hash function or cryptographic hash function has two unique properties. The first thing is when you have two files, when they are different, they should hash to a different digest or short hashes. So basically a short hash is a fixed string which compresses your arbitrary long file into this unique identifier. And people use that as a unique identifier for files. The other thing that is obvious for many of you is that a hash function is one way. You can hash a thing, but you cannot go back and you cannot learn anything from the file by just looking at the hash. There are the two main properties of a hash function and a lot of people depend on it. For example, a hash function I use are involved in documents and software signing. You can use them, for example, for Windows update, Firefox update and so forth. They are using, they are used to make sure we can verify the signature. They are also used in the same way for HTTPS certificate. They are involved into helping on sharing that the SSR certificate are signed by a CA authority and are therefore valid. They are used in version control, and you will see that play a huge role in our talk. And finally, they are also used in backup integrity to check which file has been backup and if the file has been backup correctly. They are also using a slew of other software including databases, some file system and so forth. And this is this huge and variety of software which make it very hard to understand all the consequences of what happened when you use a collision. I will give you an example later in the talk about unforeseen consequences when you try to play with collision. So, what we are going to talk about today. We are going to talk about three things. First, as I said, we are going to look at how we are going to attack hash function, then we are going to discuss how we found the hash function, the collision, what happened and what not. And finally, we will discuss post collision world and most specifically how you deal with legacy software. We still use SHA-1 and how you do what is the future hold for hash function. What we are going to. So, before getting started, the one thing that is very important to mention is SHA-1 collision is just the final straw of a very, very long line of research and we are standing on shoulder of giants. Among all the people who contributed and there is a lot of people who did over the last 15 years, two standards giant and they are not me. They are Wong who was the first one who in 2005 came up with a theoretical way to attack both MD-5 and SHA-1. She is the one who divided the method that has been refined and finally led to the collision. The second one is my co-author Mark Steven who for the last 10 years actually was the one who kept going at it and despite other people dropping out, decided to hold strong and basically carry out all the work till the end. So there are the two who deserve most of the credit for the work. I was just lucky to be there and be able to give them a helpful hand. Actually, if an anecdote is, as it was my second attempt at SHA-1, when I was standing back in 2009, 2010, we looked briefly at the idea of trying to help to break SHA-1 and we were like, no way. That's way too complicated. It's too much resource incentive. Can't do it and we give up. And I think a lot of people did give up as well because it seemed except to mark an impossible task. So I'm glad we were able as Google to help providing the resources. So if you take something from the talk, it's like Mark Steven is the awesome guy and Wong was the genius behind the theoretical attack who get all started. So attacking hash function. There are quite a few confusion about what are the different types of attack are so I'm going to sum them up. But before that, a quick show of hand. How many of you know what a collision attack is? Right a few. Okay. Okay. How many of you know what is a pre-image attack? Well, less people, right? Okay. How about a second pre-image attack? Okay. So to make sure we're all on the same page, we're going to briefly recap, we'll see a bunch of few diagrams. It's going to be very quick. So collision attack and the topic of today is basically the attacker have two files in control and the goal is you create two files who hash to the same thing. So basically you are violating, as I said, the early principle that two files should hash to a different hash function that is a collision attack. We have also another type of attack which is called pre-image attack. In that case, there is an unknown file and you know the hash and the goal as an attacker is to be able to engineer a second file which will hash to the same thing. So second pre-image attack which is the one which is confused the most people is where you know a file, let's say your SSL certificate and as an attacker you create a file which is a doppelganger in the sense that it actually has the same hash. So far so good? Yeah, awesome. Okay. So how do you create a collision attack? The one where basically we have a lot of practical result, pre-image and second pre-image don't have a particular attack for the main hash function such as Shawan but also MD5 and of course the newer one like Shawan 256. So we're going to focus on the collision attack which we can do in practice. So collision attack are not brute force attack. So the first thing which is important to understand, you cannot brute force your way out of creating a collision. It's impractical. Even if you were to use GPU and if you were to use a ton of GPU you can't. To give you an idea we think it's about 12 million years of computation with a GPU to get to a collision, not going to happen. So if you can't do that, what are you going to do? You are going to use something which is called cryptanalysis and the idea of cryptanalysis is we are studying how the function diffuses the bit and how they scramble them in a way to find biases that we can exploit to reduce the size of the computation to a point where we can finally do it. So I'm going to give you a primer on cryptanalysis. I'm going to skip a ton of detail. It's just for you to get an idea. If you want more detail, research paper, not me. All right. So here is a view of, we're missing a sign here. Okay. Okay. We're missing a sign. Okay. So here is the unrolled version of the SHA1 compressed function. So the SHA1 compressed function is not the one you're going to find on Wikipedia. If you go to the Wikipedia page you get a more simpler function. So the reason why we use this representation is because when we do cryptanalysis we need to understand very precisely each of the steps of the function. This is what happens when you have a block. So you chop up your file into a small block and you hash them and then you pass it to the next and to the next using something called a damgar, miracle construction. So basically it's a function for do the scrambling, right? And we study it. It's 80 steps long and you see them on the screen. Or at least a representation of them. And we do study how the bit flows through the thing. And the thing which provides the scrambling are these little purple blocks like F is a nonlinear function plus is a 32-bit modulo operation and so forth. So how cryptanalysis works? The idea is we are studying message differential paths. So the idea is we try to understand for a group of messages how the bits are moving and how they have been swapped around or flipped and so forth. And that's the red dot you see on the screen. So when we have this understanding that give rise to what we call a equation system and for SHA1 we know exactly what happened for the first 16 steps. Remember there's 80 of those. So for the first 16 it's basically solved and we understand what happened. So we can understand how to reduce the computation. Now we have reduced the computation by 16 steps. Then we use a bunch of tricks including boomerang, neutral bit and so forth which is basically try to counteract the chaos and the entropy creeping up to the point of pushing the computation to a smaller part by another eight steps which is up to state 24. And then, well we don't know. And that's the part where you need this huge computation that's the intuition at least where this is a part from 24th to 80 where we have kind of we cannot really understand what happened and it's too big, the state expression is too large so we cannot, that's why we use a GPU to actually compute all the possibility or a huge fraction of those because we cannot understand what happened there. So how do you create a collision? Well we use the idea from Wong which is the idea of using two blocks. So you have a bunch of the beginning of the file which we call the prefix and this is whatever you want. And then we have a first block which we call a near collision. So what is a near collision? A near collision is two blocks which basically are very close to each other for a definition of closeness. Basically imagine that those two are good candidates and they are different but they are sufficiently close that we have a good guess or we have a good belief that they're going to be resolved with a second block. So basically we take the input of those two blocks and then we have the second block who basically cancels those two collision and then we end up with the same output. So at that point the left and the right will have exactly the same output and after that you can put whatever you want after that because the collision has been resolved. That is the basic idea of the collision and the non-intuitive part is where you two block. All you have to really remember is we have a prefix which is basically something you have to choose in advance. Then you have the near collision collision and then after that it's all the same. From perspective it's all the same because there is no dependency in how you can create a hash function to the past. So at that point it's an identity code and you can put whatever you want for the suffix. So, okay. So we just keep this one, this was the one before. I'm not sure what happened. So how do you exploit collision? So exploiting collision. The one we do it for shell one is what we call a fixed prefix attack which means we had to create a prefix. So choose a green box before we're doing the computation because we can't change it afterward because it feeds into the collision. So we selected the prefix and you have to select it in a very smart way and then we have the collision blocks and after that you can do what we call an arbitrary suffix which is you can jam whatever you want before after that and you can create many, many documents which have a collision in it and we'll show you how we can exploit that in a minute. So here's how it works. So it doesn't seem very powerful, right? Because you're like, well, you have to choose everything and everything is pre-computed. That is true. But the prefix you choose would actually influence how much you can do. In our cases we use PDF and GPEG. You can think of other stuff like EES, like other type of file format which have flexibility but PDF for us was the best one. And so the idea is we use a collision block to change the length of specific fields such as comment and that way what we display on the screen will be different from file one because it's going to point to one part of the suffix and on the other file it's going to point to another part of the suffix and that way even though we have the same suffix we are able to display different view of the world because the collision blocks themselves are used to control some of the display function. I'll show you a practical example later on in the talk. All right. Chosen prefix attack. So that's why the one which was used in MD5, this is for reference, MD5 is way more weaker so in that specific case you don't have to worry about choosing a specific prefix. You can use the one you want and that gives you way more flexibility and I'm going to show you a practical attack that was using the MD5 attack to illustrate the purpose. All right. Enough theory. Now we're going to go to the real world attack and I'm going to show you exactly how to use those things in practice and we're going to start with MD5 because that's the one which happened about eight years ago and so we have a lot of hindsight to look at and a lot of real attack to show you. The first one is too new to have those kind of stuff. It gives you a sense of what you can do when you have those collisions. So the first attack which was created using the MD5 collision in practice was creating a rogue SSR certificate. If you're able to manipulate the signature of a certificate, it turns out you can create a signing certificate for everything you want which is valid and you can impersonate any websites on the planet. This is what Mark did with Alex and a bunch of other people back in 2009. And so the way it works is as follow. This is what the necessary certificate look like. You have a bunch of fields which are the serial number and the validity period which are from the, which I give you by the register and then you have the real search name which is basically which domain is your certificate signing for and then below that you have something very important which is the extension CA force. What it means is your certificate cannot be used to sign other certificates because obviously you're not a CA. So the whole goal when you create a, when you forge a certificate is to swap those two fields. So how you do that with a collision here's how you do it. First, you obviously you write a certain name to say well I want to be able to sign for everything. So I remove the real domain name and I put a star instead. Then I put my own public key obviously so I can actually do the creation and then I say well I'm a CA certificate, right? And then after that you have to hide the real, the real public key and you do that by hiding it into what we call the Netscape command extension. So a lot of SSL certificates have a lot of field and one of them is the ability to jump commands in it and you can use that as a neat trick to hide the previous public key and you use this space to create a collision. Then you leave the signature, you copy pass it to your new brand new FEC certificate and you have a signing certificate. But basically how you create a FEC valid SSL certificate. If you think that's a academic attack, it's not. It turns out that in 2012, a malware was discovered which was mainly spying on an Iranian computer. The malware was called Flame. I don't know if you remember it. This malware was fairly unique in a sense that it was using a colliding certificate to push FEC Windows update. What happened is someone well funded decided to create a collision by stealing, by lifting the signature of a Windows terminal server which should not have and removing the restrictions. They all certificates were only used for compatibility and they had a bunch of restrictions. So what they did is they took the certificate, changed the C name and then removed the say, it's only for Windows XP. They said no, no, it's for everything. We packaged it and used it to deliver malware as a form of Windows update which was saying it was a certificate to attack Iranian computer. What's very interesting about this attack is because it used collision, we mark and his team was able to reverse engineer how this malware works and were able to figure out how the collision was created. And lo and behold, it didn't use any of the techniques which were discussed in Academy in 2009. It was using a completely other technique which were using a four block collision. If you remember, I told you the two block collision is the way we do it because it's the most efficient. So now the people who created the Flame FEC certificate was not using two blocks. They were using four blocks which is less efficient. You can still do it. And we're using a vector which was another one discussed in Academy. So someone in the world had enough cryptographic knowledge and enough resources to pull out this kind of attack which led a lot of people to hypothesize it was a state-sponsored malware and that's the explanation behind it. If you want to know more about it, there is a very, very neat paper by Mark which is called reverse engineering of the cryptanalytic attack using Flame to Supermower which explains all of this in detail but that's the bottom line. So basically you can weaponize collision to create attack and it has been done in the past and that's why taking collision seriously is so important. So where do we live today? Well, for the old function, the old dead. MD4 is dead for a very, very long time. MD5 is so dead that you can do it on your smartphone. No kidding. You can literally create a collision in your smartphone and then SHA-1 is a new attack we created and it took us two to the 63 computation which is pushing the limit of what we can do. It's one of the largest computation in the world as far as we know. So how did we find this collision? Well, we started in 2015 and as I said the prefix has to be fixed for SHA-1 so we had to create a clever prefix. Ange Albertini was the one who looked at this because he is very, very well known for how to do world experts into crafting interesting documents and so he came up with the idea of using PDF and GPEG so we can actually have a prefix which gives us malleability to show one image or another and make it very, very easy. I'll show you a demo in a minute. And then I ran the first computation between 2015 and 2016. It took me about nine months and 300,000 computers. Then excitement began. We ported the result and then we had to develop the full attack and we had quite a few sweat there. I'll tell you that in a minute as well. And finally, we did the second large computation early 2017 and then we issue the release in the press in February 2017. So what Ange came up with to be able to use the collision to the full extent was to embed a GPEG into a PDF header to create collision which would be like valid PDF document. And the trick is GPEG has something called a comment. And the idea is you will use the collision as a boundary for the length of the comment. So both file while having the same hash will actually display differencing because in one case the length will point to the first image and the other case by rebounding on comment of comment will rebound to another image. So while the content of the two file is the same, if someone is to open it you will see two different images that the power of creating collision and of course you can use whichever images you would like so now you can create any pair of the plunge and gear files. So try to imagine two insurance contracts one day you only have to pay $1,000 and one day well no actually you have to pay $1 million and those would hash or something. That's the kind of stuff you can do without. So then I took max code and tried to scale it up to, as I said to use about 300,000 core in multiple data center around the world. And most of the complexity was to find the right balance between resilience and performances. So every time you have to dispatch a new job we have to copy stuff in memory, move things between computer and so forth. So there is a lot of overhead so you want to run as long as possible. At the same time computer fail and we have to reboot the job or the job has been preempted and so forth. So we settled on after if you try and out about one hour batch and we run well quite a few of those like millions of those. And then I also refactored the code to be stateless. One of the difficult thing when you do this large computation is when you have a database where you have to pull all the job. Instead of doing that we were making each job stateless so you can restart them and then we're using basically a random generator to decide which chart to use instead of having a synchronization because otherwise you have to deal with failover and replication of the master and become even a bigger hell to manage. And last but not least I make a huge mistake. MapReduce is a very famous computation framework and the idea is you map your computation and you're going to reduce to all the solution and like that's perfect. That seems to be the great tool to do the job. So now it's absolutely the wrong tool for the job because the map is very very complex. You expose the entire space but reducing the part where you aggregate all the solution is very small. It's only a few bytes and so we were spending a lot of time waiting for the last part of the computation to finish. I was running batches of I think a 50,000 job at the time. So 15,000 hours by 50,000 hours. And so as you can see on the graph most half of the time of the job was used for basically waiting for the last bits to finish. So for the second computation part we actually moved away from this paradigm to using a simple job system where we have a factory and a bunch of job and make them all independent which was way more efficient. So lesson learned don't choose not produced for this job. We learned that the hard way. Then becomes a part where we was the most carry. We finished the first computation sometime in I believe January and in the middle of the night my phone rang and then I know we found the first collision really excited. I sent an email to Mark and said hey we found it. Great. Okay and then he started to look at it and I'm like can we get to it? Can we get to it? And I'm like wait, wait, wait. Looking at it and then turned out that at first glance what we found was not solvable. Which means that we didn't know how we got an equation system to find the second block but we couldn't figure out what was the equation system had no solution. And then we were very, very scared for many, for quite a bit of time that we couldn't do it. But then Mark and Pierre figured out how to add extra condition and fix the sort of ability using that technique to actually make it work again. And then we were able to find more speed up to accelerate the computation and then we were able to run the computation and then Eric from my team actually run the second stage of the computation through GPU. So GPU is very interesting. A lot of people say GPU is great for crypto. That's true. Except the architecture is fundamentally different from a CPU so you have to rethink how you do things. In particular memory transfer is very expensive so we couldn't do load, unload, load, unload and those kind of stuff. You have to allocate memory, do your computation, allocate memory and so forth. So what we started to do when that's Pierre's idea is to use a feed forward where we compute the base solution in CPU and then we move on to the first few steps between 14 and 26 and we compute a ton of potential solution. Use a GPU to compute all the next step and until we have exaustic do one step and move one step, move one step. When we don't have a solution, go back and forth. The reason why that work is because the first few steps you have very, very little solutions. This is a graph in logarithmic scale, right? So it means that the first step you do maybe a hundred thousand computation. The one in the middle you have up to a hundred trillions of solution. So it quickly ramps up. So what we do is we were saturating the memory with as many potential next step, do all of them at once and if we don't find a solution backtrack, generate more solution and move back and forth and so forth. So it's a completely different way to approach cryptography. So while GPU is great for crypto, it also requires a lot of new way of distributing, scheduling your computation because you don't have the same memory and general memory manipulation as you have in CPU. All right. And then we spend a hundred and ten years of GPU. A far cry from the 12 millions we would have spent if we were using brute force. So we succeeded. That being said, before we succeeded, we had a funny incident. I mean, I didn't find it funny at the time but now it's okay. So Yarek finished a computation for my team and sent an email to Max saying, hey, we found the collision and we're ready to celebrate, you know, the champagne is there for a week. She would like, well, we're going to celebrate so it's going to be awesome. And Max said, it doesn't work. And you're like, what? It doesn't work. What do you mean? It doesn't work. And it doesn't work. And it turns out because the way we did the computation, we had it done in big Indian instead of little Indian and it was looking at it the other way. So we fixed it. It was fine. It was like a one line change. But and then it was all fine. But I'm telling you, we were white. Anyway, so and then we were happy. We were able to create those colliding PDFs in my have from them online. So basically you have the same shell, the same shell one in the different chat to 56. And as you see, because we use a comment of common trick, one is blue, the other one is red, that the idea we had. And then we were like, okay, we're going to give the world 90 days before we release the code to create two PDF, which are Doppler Ganger. Well, trust the internet to do it in two days. So they have a better tool than ours. So here's the link below it as a GitHub one. So I'm using that tool. Thank you for recreating it. And so basically that's easy as it. So we have two PDFs which have different value, a cat and a tiger. And what you do is you basically use the collider script. And the collider script will basically merge both of them into one PDF and align the comments from one point to another. And that's how fast it is. That's like literally real time. And then as you can see, boom, you have two PDFs which have the same. Okay. And then you have the chat to 56. All right. So here is the gig version behind the scene. You have the fixed part, as I promised you, which says the PDF headers. And then below it, we have the GPEX dot. And you see, and then following that, we have the GPEX comment. And then at the border of the GPEX comment, we have our collision block, right? And you can see it here. Let me try to do this. You see it here, right? You have the last bit of the comment which is inside the collision block. So they would be different in both cases, right? And so one of the comments is 173. The other one is 17F. So as a result, you do create a disconnection. And in one of the files, the image starts way lower and it's a comment in the other file. Well, so in one case, I say it's a GPEG. And then in the other case, it's a real image. And that's how it works, right? So a lot of people were confused when we showed the attack how we can do and create as many as we want. Try to explain that to the press. And then that's what it is. I want to also give a big prop to Hector Marta, which is a guy who actually created the visualization. Again, I had a great one and he did way better one. So I'm stole with his permission, his version, because I think that's a clearer version we have. So thank you for him to do that. So post collision world. So what happened when you create a collision? First thing, and that's the thing which actually was the goal, we released a collision a few days or I think even on the day of a meeting between browser, which was a, which is a consortium to decide what is the future of web browser. And there was, there was about to have discussion about prolongating the lifetime of Shawan, except it was, was supposed to be sunset but people were like no, we might extend it because some people have complained. But in the light of the attack, Firefox finally gave up and they find we're going to immediately ahead of schedule, stop it, which was exactly our intention. If we engage into doing such a long computation is not for the fun. Also it was very fun. It was because we really wanted to push the world to stop using Shawan once and for all and as many, many of the cryptographic loom, unless you really show the money to people and the real attack, they tend to delay it for another year. Right, you know, out of the sight of the mind. So we decided to put it in front of you. So you have to do it. And I think for us that was the most important thing is we deprecated Shawan and as a result, user we feel are safer. So that's really the goal of the entire exercise and it was a well worth investment. Microsoft is the same in May. So now all I believe every browser are deprecated Shawan. So now we are in a better world, better place. We got leaked. Someone put a bet that Shawan will be broken in 2017, literally mere hour before we were about to release. I have no idea who it is, but the guy made 8 Bitcoin and I want my share. So also I saw Mark, so the release was about 5 AM PST because he's in Netherland and so I saw him a few hours before scrambling to try to get the bug bounty for Bitcoin. So there is this people who are giving a little bit of Bitcoin money for the people who break Shawan to incentivize them to do one. I was seeing him rustling to get the data as a money but he did. So he did claim the bounty just in time. So Mark was a bounty, that's fair. Hopefully no one stole it from us. And then I spoke about unforeseen situation. And I think the most impressive one and it completely took us back was when you get had problem and I'm going to talk about it in a minute. But we didn't sort of SVN because none of us used SVN for a very long time so we didn't sort of it. But then a guy from WebKit was like WebKit which is the web wanderer for Safari. One of the engineers was like, oh, we use Shawan. Let me make sure we don't are vulnerable for collision, which is a great idea. And so he pushed his unit test to the SVN of WebKit and the WebKit SVN died. It's not like you can revert, it just died. And for eight hours you see all the WebKit engineer completely freaking out like, did you try this command? Can we do this? And ultimately they were able to recover it but it literally destroys the entire SVN for WebKit for eight hours. And then Apache did issue an SVN emergency path to say, please do not test collision on the SVN. We know it's broken. Don't do this. So that's an unforeseen situation. If we had known we had an advanced notice but we didn't. We didn't have the test vectors. We didn't know it would break anything. But we broke Git, which means there are other software somewhere which are broken by Shawan so you have to find a way to mitigate those and that's going to be the next part of the talk, which is what do you do when you think there is a Shawan software looming into your network? Right? What do you do? Well, we have a great example. Git. So despite early warning and there was a long thread and I put a link there and they were on the slide about people trying to warmly use Torval to not use Shawan. Like no, no, that's fine. I'm going to use Shawan. Don't do it. No, no, that's fine. I'm going to do it. So at the end of the day Git use Shawan and it's back in so many assumptions that it's really hard for them to move away from Shawan. They are moving away from it finally but it took a lot of discussion and it's still not there. So now we have a very well used software. How many of you use Git? Yeah. So all of you use something which is able to put theoretically to Shawan collision where we can have two blobs which are the same collision and you end up with two different view of the world for the same Git repository. Not good, right? So how do you mitigate that? Well, it turns out we have a tool and actually Mark invented this tool. He invented this tool and then applied it as I said to Flame but it's also well for Shawan. The idea is to use counter crypt analysis. It's a very mouthful word but the idea is because the way you create collision creates unique property into the file. Most likely there are trivial differences due to the way we use differential paths. You can with a single file detect if this file is part of a collision. It is very, very high precision. It's like zero, zero point zero zero zero zero, like 1701. So you can run it in a production system. It has a little bit of overhead but it's okay. And it's only a source for you which is very cool to understand if you see a collision how it has been constructed. So you know if it's ours or if it's a new one we never seen. So that's how they did to reconstruct the Flame one. So counter crypt analysis Mark improves the version he had and push it on GitHub so if you have a sha one software using sha one please use counter crypt analysis we do. And we did that. So someone from Google shown peers fixed G Git to basically do counter crypt analysis check when you submit. So G Git will refuse any collision block. The other one who did the same thing is GitHub. GitHub in March announced in their blogs like well fine we're going to use counter crypt analysis. So if you use GitHub how many of you do you use GitHub? That's it. I'm kidding. A lot of people use it right. You are protected as well because they did put in place a check when you push your commit to actually do this. So the way you actually deal with legacy software is by doing detection and proactive mitigation. And even Git got on to the counter crypt analysis bandwagon actually it was deployed in 2012. So now we have this thing. We have counter crypt analysis also for every Gmail document and every drive document will go to our system. Some of our user did test on the day of the release to see if it was working as internet. It does. The reason why we do that is because we are concerned about people using old client software that we don't know of. They might actually sort them in backup software we don't know of. We have a lot of corporate users as well so we don't know what their backup system are so we basically prevent collisions that way and you can do the same. As I said we are concerned that crash legacy software like SVN might have colliding documents with different terms like contract, lease, power of attorney and so forth. And of course black one which is unforeseen consequences that we don't know of and we really don't want to know of. And so how much does it cost us? About 4.5% of extra computation for every email attachment that we scan that way. That's based on the 1 billion data set we tested after we released it so we believe that's a well worth investment. It's not a huge number. It's significant it's not like impossible to do. So what does it leave us? Right? Well future is bright. It's awesome. We have a lot of new hash functions coming online. We have Shattu 56 and the Shattu family and we also have Shattu and Blake and what's great about all of them is they are using different construction which means that if one breaks it's unlikely it's going to break all of them at the same time so we have a lot of diversity to choose from. We have different perspectives so we are in a very good place. So hopefully you won't have that kind of talk for the next 10 years hopefully. So take away, Shawan is finally dead. Long live to Shattu 56. Counter-corruption analysis is a really cool tool and I hope I inspire you to check it out and the future is good. So thank you very much. I'm going to take any question you would have. Thank you very much.