 Okay, great So I'm going to talk about some this is like a fun paper, but we're here for fun. So that's good This is not there's no sort of major vulnerabilities here, which is good So we'll just have some fun the sort of setting for this work is This is kind of the theme of like a lot of my research So you guys are all familiar with the law of large numbers, right that these sort of Statistics you the average behavior converges almost surely to the expected value as the number of samples increases, you know kind of You expect things to essentially converge this way So there is a sort of counterpoint to this law, which was formulated by Diakonis and Mosteller Which is that when a sample size is large enough any outrageous thing is likely to happen All right, so if you want to show the existence of some kind of strange behaviors Then You just collect enough data points and you will find some weird outliers Then okay, so in the cryptographic context I would like to formulate a cryptographic law of truly large numbers Which is that if you're given samples from enough independent cryptographic implementations any outrageous vulnerability is likely to be present So this is essentially this is my conjecture I conjecture this based off of a number of data points, which is essentially my publication record So this is my form, you know, this is how I got tenure. I don't know about you guys so So in that spirit this paper this work, which I should mention is joint with Joachim Breitner who is a DFINITY is Taking advantage of this observation So I guess it was sort of nice that we got an introduction to Elliptic Curve Diffie-Hellman in the last talk so now we're going to talk about ECDSA in this talk So we don't care about the elliptic curve aspect at all. We just care about the DSA aspect But most people are using ECDSA and not finite field DSA, so we'll push ahead with elliptic curves So ECDSA we have some global parameters. We have an elliptic curve E We have some generator point which has order n Your private key is some integer Your public key is, you know, that integer times your generator point We also don't really care about those details So in order to sign a message you hash it possibly in some complicated way Did you know that most ECDSA implementations hash the message twice? It's kind of weird Or One bit less secure than than once it's yeah, it's it's a little odd. I Did not know this until doing this paper for whatever reason so You learn amazing things. Okay, so You hash the message and we really we don't care about the details of that that doesn't really come into this So we'll just say the message hash we're going to treat it as an integer h and we don't really care so Each signature so the ECDSA the way it was originally written it is a randomized signature scheme So you have a per signature nonce which is really like an ephemeral private key It's some integer k this k is extremely important as we will see very shortly and So this should be generated sort of per signature And then your signature itself is a pair of values r and s r is the x-coordinate of k times your generator point and this s value is computed as Written down k inverse times the hash of the message plus the private key times this r value mod n so that's just an integer and For our purposes it is useful that Like this is just an integer and this is done using normal integer module or arithmetic So we don't care about like all of this elliptic curve garbage. We can ignore that part because that's hard and confusing so Okay, as much many of you probably in this room probably know As I said the value of k is extremely important So this k must remain secret for all of the signatures you ever generate or else your long-term secret key d is revealed and using Basic integer arithmetic you just like invert this question. Okay, very straightforward Like good good undergrad intro crypto like exercise probably You can amplify this a little bit This is also super well known if this secret Nonsense k is ever reused to sign two distinct messages with different hashes h1 and h2 Then it is trivial to compute this value of k basically by Solving two equations with two unknowns and then you get this value of k and then using the sort of equation on the previous Slide then you can compute the long-term secret key and then you're you're done. So this Comes up over and over again random number generation issues blah blah blah This is well known flaw people have been exploiting it for a long time. Okay, also a fun undergrad project The thing that we are going to be playing with in this talk is kind of an amplification of this maybe but it's much more complicated so This these nonces must be generated sort of perfectly uniformly at random or else If they haven't been We can possibly use a number of signatures to compute the long term secret key D So and the way this works is we essentially have some nice linear relations that we can dump into a lattice There is also an algorithm that uses Fourier analysis. We're going to ignore that for the purposes of this talk so we dump this into a lattice and then it the secret key is just spat out and kind of the high-level version of these attacks is that if These secret nonces k i are small then the system of equations likely has only one solution and the lattice mat like lattices can magically find it and if they are not small then I Don't know other other there are other kinds of biases that that can be exploited So that's the big picture of what we're doing here The sort of formulation of this problem. We're going to be you we already heard about the hidden number problem invoked once earlier this morning, so The way that you the way that we will formulate this problem is that essentially we have a system of equations with some unknowns in the signature nonces and the secret key D and It looks something like this. These are nice linear equations. We know the coefficients here and so we're just trying to Solve for the secret key D. This is a alternative formulation of the hidden number problem, which was originally described by Boney and Vic had a son a while ago in the context of actually breaking Diffie helman With bits known. I haven't seen that exploited in the wild actually Just sort of interesting Say here. Oh, you know, let me move around. I like moving around They'll deal with it We'll prioritize the people in the room Okay, I've been tied to my podium Tragically It's a room full of attackers would like okay. Anyway, so This is this is where we will briefly get into the scary lattice section So half of you will be happy and half of you will be unhappy But it's only a few slides. So Then then everybody can be happy because we'll start breaking things Okay, so we've already see we've already seen some of these lattice constructions This is all sort of well-known. So I will just go through the lattice construction briefly. So the hidden number problem As I said the way that I'm thinking about it. We want to find solutions to a set of linear a system of linear equations that looks something like this Where we have unknowns K1 through Km and the secret key D and For the for the moment, we're going to say that all of the k i's are small so they're less than some bound capital B In absolute value. So the if you read Boney and McCanneson's paper, they construct a lot of spaces that look something like this So you have your modulus n on the diagonal and then you have your One of your one set of coefficients kind of along the bottom row and then you want to solve the closest vector problem with a target vector that consists of the other set of coefficients and It just so happens that once you find the closest lattice vector Conveniently the distance will consist of a vector of all the nonsense So you expect this to be small since we said the nonsense are all small And so then this is just sort of spat out the solution and we can solve for the nonsense Okay, you can you can work out how well this works. We don't have if you actually try to implement this you know Solving CVP is annoying. We have If you just want to like press a button It's much easier to Find short vectors than closest vectors unless if you're super lazy So what everybody who is doing side channel attacks and stuff does Now is basically sort of embed this lattice into one dimension larger lattice And then you can just find a short vector and it will just spit out the answer for you And so you don't even have to like back solve for anything. So Here we've just sort of added the target vector to the bottom and added some scaling factors And it will just spit out the private key is the shortest vector so That's cool So this is what we are doing There's a lot of papers actually that get these scaling factors. I'm gonna get off the stage. Okay There's a bunch of papers that get these scaling factors wrong actually, which is kind of interesting But the only thing that matter that means is that like you have to look hard a little bit harder for the the secret key okay, so This works how well does this work? Well, we do a little bit of back of the envelope lattice math ignoring all of the Approximation factors because we're only dealing with really small lattices here So the dimension of our lattice is say the number of signatures that we have plus two the determinant is Whatever this is it depends on the bound and the modulus So ignoring the approximation factors because the largest lattice that we look at is like 40 dimensions If we use the LLL or BKZ lattice reduction algorithms We should find some vector that is approximately determinant of the lattice to the one over dimension And we're looking for a vector with length That's basically square root of m times whatever our bound is and if we plug that in and solve Then we get that the log of our bound should be less than that and if you want to put in the approximation factor for lattice reduction and that adds like a little turn here Okay, but generally the thing that we care about is that as we As we increase the number of signatures we expect this to grow towards log n, but never actually reach it So this means that our bound you know, it starts relatively small, so we expect it to start like n over 2 for For two signatures and then grow to approach but never quite reach and the length of n so The original bonnet of a kettison paper they cared about the limiting behavior, so you could reach that limit essentially Or you can't really get past setting m equals square root of log n If we care more a much more about concrete parameters So with two signatures we we get a pretty good success rate with And we specialize for a 256 bit curve Curve so we have a 256 bit and so the length of a Small nonce that we can solve for with two signatures is 128 bits. This has some failure rate With three signatures we can solve for 170 bit nonce with four signatures We can solve for 190 bit nonce and so on and so forth. I got these empirically So yeah and the point at which lattice reduction starts to get sort of too slow to run millions of times is like say 40 dimensional lattices so we stopped there with so we can solve for 248 bit nonces with a 40 dimensional lattice Yeah, sure. Do you want to come to the mic? Okay So in order for this to be solvable though, you need the product you need a property of these nonces that they are You keep saying that they're short. Yes, they're small So this is a little different from the way you normally think of this where the problem is that the nonces have like a few bits That are predictable. Mm-hmm. So if the nonce if the nonces have a few bits that are predictable Then you have you just add the term of like the most significant bits and then you have like the rest of it is this short piece Okay, so it would have to be specific bits It wouldn't just be that there's something about them that's slightly distinguishable or something I'd have to be like some specific bits are biased. Yeah, okay so with the with the lattice attacks basically if you have a side channel attack that's giving you some Predictable bits you can say shift them to the most significant bits and then you have a small piece that is Not predictable or that's not predictable That's what you're solving for and then you just add the term that corresponds to the bits that you do know and you have to know Where they are, okay, so yeah for analysis is a little bit Works a little bit differently, but we are specializing to the lattice attacks This is great. We're like breaking all the rules here Okay a few variants of this so we don't necessarily have to have most significant bits all zeros We can solve for most significant bits known and this or not not known, but the same by adding one more signature, so Say we have two nonces that are have most significant bits that are the same But we don't know what they are. We just know that they're the same We can subtract them and then the difference we can subtract the signatures and subtracting the signatures Gives you a difference of nonces that's going to be all the all zeros and so now we're back in the short nonce case So that that is totally straightforward So we can just add if if for some reason somebody has generated a bunch of signatures with most significant bits all the same We can just subtract one from all the rest of them and solve and then we're done so we've just added one more signature to the number of signatures we need to solve for and If we can also do pretty easily the least significant bits case Or middle bits, but we didn't even bother looking at that it works the same so you can subtract your Signatures which results in subtracting the nonces which gives you say least significant bits That are all zeros and then we can multiply by a power of two to shift those known least significant bits to the most significant bits and then we get the same case as before of a short unknown sequence of bits So it's everybody on board with our lattice technique So we have a magic box we can dump a bunch of signatures in and it will spit out the private key That's the part that we care about so that is the end of the scary lattice section We are done with math for this talk Now now we start breaking stuff. All right So fun times where can we possibly find billions of ecd's a keys and signatures many of them generated by amateur enthusiasts? Cryptocurrencies this is so great So I wore I wore my themed shirt today. This was the shirt is not my fault. I'm just wearing it. So Okay, unfortunately, we do have to worry about some of the details of the way that cryptocurrencies use Cryptography in order to implement this stuff and this caused a huge amount of grief You have no idea how complicated this is unless you've tried to do it in which case like I'm with you in our shared Sort of suffering so Bitcoin Ethereum and ripple all use the same elliptic curve for ecd SA SEC P256 K1 widely known weird choice So the way like sort of the cartoon version of the way that they use it is that the sender is signing some hash of a transaction And this gets recorded on the blockchain Jane luck And sort of published to the internet so Identities are addresses and these addresses are hashes of a public key Which is interesting because the hashes are both like a cryptographic hash and it loses information So in fact, if you sort of parse the blockchain and you see a bunch of hashes And or you see a bunch of addresses you don't actually know the public keys until an address sends Currency somewhere else by and generates a signature Which is which is interesting so there can be lots of Cryptocurrency associated with an address in going but until it generates a signature itself with an outgoing transaction We are cryptographically we have our cryptographic hands tied because we can't do anything with the address itself So we are we can only look at addresses that have already spent money So okay, so these transactions are recorded on each currency's blockchain Which is convenient for the attack or everything is public So if you want to say start analyzing the cryptography You can download a client you can sync the blockchain and you can start parsing and extracting the signatures And there's a star here because this is way more annoying at practice than it sounds. How many of you have tried to do this? Is it like painful and the grief inducing? Like this is I have no idea why it's so complicated like the way that and I should say that my Co-author Joachim was the one who did kind of this last part and I was just like can you please send me signatures like this is Because the way that Bitcoin Like generates hashes of transactions is incredibly complicated and it's like changed And so the only way that like we could figure out to do this was to just like modify the client to have it like print stuff out because Like well, it was validating the signature because it was just impossible to compute otherwise and Let's see. Are there other weirdnesses. I think There's a there's a few more so okay, but the the cartoon version of this is that you can just download the blockchain You get a bunch of signatures and and it's great the non cartoon and the non cartoon version is that if you start looking at all of the like Bitcoin analysis libraries that are that people have published out there for some reason They assume that people don't want to actually examine the signatures So they don't make it easy to get to them and they for some reason they assume that you don't actually want the Concrete value of a hash of like the hash of the transaction. Why would anybody ever want that? So it's hard to get Anyway, okay, so this like much research So like what you know Matt was talking about earlier today where there's like a great little cryptographic component And then there's like months of engineering. This is like the months of engineering for this this work So all right once we have a Convenient way of extracting the signatures here is our crypt analysis program so We will scrape the block chains. So the Bitcoin blockchain when we're looking at it had a billion signatures in it Which is pretty cool We can group them by a public key that generated each signature So this resulted in say 60 million public keys for Bitcoin that had generated more than one Signature Then we can check for the two attacks that we we talked about so the easy attack is checking for Repeated nonces, which is you can just look for a duplicated our value in the signature Or you can also look for lattice attacks on the bias nonces as we described We spent about 50 CPU years running these and at that point either You're rich and you can retire to some island without an extradition treaty or You are not rich in which case you publish a paper and I'm here so You can see what happened So Sort of the details of what we ran We clustered the signatures by the public key We selected random subsets of two three four and forty signatures and optimistically just ran the attacks for the short prefix and suffix nonces so Kind of if the collection of signatures that we chose happened to be vulnerable We would get the private key if not we would get nothing And so there I want to add one little extra weird snag in the way that these Cryptocurrencies generate signatures, which is that they're really worried about having unique signatures. So Fact about you CDSA the signatures R and S and R and negative s both validate And Bitcoin makes the signatures unique by choosing the smaller of S and negative s mod M to make them unique This has the effect of negating K like the the nonce So for the prefix and suffix attacks where we had to do the Subtraction we actually have to brute force us the signs of all the nonces, which is like super annoying Maybe there's a clever way to get around this maybe for analysis gets around this but we did not do that So there's some brute-forcing going on Okay, so what did we find okay, so I'll start with the easy case Which is the repeated nonce K values, so this has been analyzed many times by academics since 2013 So we'll just sort of summarize what you find so here is so the x-axis is Signatures over time with repeated values and then the size of the little circles there is the number of signatures on that date with repeated with a repeated nonce so Bitcoin out of the billion signatures two and a half million of them have a non-unique K Those come from 1300 unique keys Ethereum there's a smaller number of keys and smaller number of signatures and ripple also There is there are multiple attackers who are systematically scanning the Bitcoin blockchain and stealing all the money from anybody who produces a Signature with a non-unique nonce so there was no money in the Bitcoin ones there there actually were funds in the Ethereum and Ripple cases, so people were not looking for this yet in Ethereum and Ripple You may notice that there's a interesting Something interesting going on here with one of the values. I'll talk about that shortly Okay What did we find with a lattice attacks? You might expect that we would find nothing because of course who would be stupid enough to like make a mistake there but in fact we found a number of things so the y-axis is the Sort of format of the nonce that we found prefixes or suffixes in the love length of the random part and so we actually found 6000 signatures from 300 keys in Bitcoin these contain it contained point 008 Bitcoin, which was think 30 something dollars and Ethereum there were five signatures from one key. They contain some ether and we also found some SSH keys That were vulnerable due to this attack So I will now go through a few stories so What is going on with this giant circle here so This value So ninety nine point nine percent of the repeated Bitcoin nonce values are That that number This is n minus one over two where n is the order of the elliptic curve used for Bitcoin and it is weird fact the x-coordinate of One half times the generator point has a hundred and sixty six bits instead of two hundred fifty six So all of these signatures The r-value is shorter by 11 bytes. I'm really enjoying John Kelsey's expression right now For those of you at home, it is amazing. Okay So Why are people doing this well apparently the suggestion to do this in the context of Bitcoin and like well The reason that people are generating these these signature values is that Greg Maxwell suggested this to clear dust transactions So like sort of small amounts of cryptocurrency left in particular addresses And I guess you pay for the length of your transaction And so by having a signature that is shorter by 11 bytes you save a small amount in transaction fees Okay, that's what people are doing this, but the bigger question is why does this value have this property and Somehow the Bitcoin people figured this out and are taking advantage of it, but then like This isn't actually like a documented property of this curve it seems to be an artifact from the way it was generated and Nobody I have talked to know like knows why it has this property, but it is the case that a number of the the other Curves of the type also have this property some of them produce the same value and some of them have Kind of variants of this value It also turns out that the the generation procedure for these curves was not documented So this this is this tells us something perhaps I mean, so I've talked to a number of people about this and is an ongoing mystery, but if you We're discovering more things as we go along So this is this is telling us something about how these curves is generated are generated properly probably because you would never expect this to happen at random and You may notice that a hundred and sixty six bits is intriguingly close to a hundred and sixty bits Which is the length of say a Shawan hash of something, but it's not a hundred and sixty bits. It's a hundred and sixty six bits so they're not just like merely like hashing something and incrementing it's like hashing and then appending and like I Can I can I if people would like to see more I can show you a little bit of what we figured out, but So this is fun things that you find when you look at public key infrastructure so, okay, we will continue on to Further fun things that we found so one of the compromise keys from repeated Nances we traced to dark wallet dot is we were basically just like googling Addresses to figure out what they were because of course there isn't much metadata in Bitcoin itself that would tell us so this was part of a three out of five multi-signature address So that means that you need Signatures like this this address is associated with a number of keys and you need signatures from at least three of those keys in order to Send money out of the address And this was used for donations to dark wallet dot is At the time that we were looking this Address held a large number of funds like pretty pretty significant So we thought that they might care about the fact that one of their keys had been compromised and so I Got in contact with one of the authors of this site Who it's very interesting person both of the people are very interesting? Cryptocurrency people are strange so So I'm chatting with him and I was like so can you like tell me how you generated these Signatures because it would be interesting to know what implementation it was And we could like sort of trace this down and he said it's either me I was calculating the signatures manually or my friend who was working on dark wallet. It might have been an earlier version so Calculating the signatures manually. There's like a lot of money in here and it's just like kind of hand-generating CDSA signatures and oops you forget to see your your on G and and then you've compromised your key so This is the state of cryptographic software So some more human factors So after finding some very small nonces we brute-forced all the 32-bit nonces So this compromised 275 signatures from 52 keys some of the nonce values that we observed were Obviously not randomly generated So people are Having fun Yes, I mean I guess we could like try to get some confidence values like if we had some prior here then I could like Don't know what the what the the confidence interval for this is Anyway, so okay Sort of more like on a slightly more serious note There have been a number of random number generation vulnerabilities that have impacted Bitcoin over several years two of the most prominent ones There was a bad vulnerability in Android secure random They were I think it was not like getting a fresh state on a fork And so there were a number of repeated nonces and a lot of people got large numbers of funds stolen because of repeated nonces generated from Android Bitcoin wallets in 2013. There was also a vulnerability in the blockchain.info Wallet From 25 I think the vulnerability started in 2015 There was an issue where they were seeding from random.org and random.org redirect from HTTP to HTTPS and so the blockchain.info Was pulling the the data from here But then when this redirect happened they were just getting the 403 redirect rather than the actual output that was supposed to be coming from random.org and so This resulted in a constant seed for the random number generator So we can see I mean It's it's hard to tell I mean these were two of the like most highly publicized random number generator vulnerabilities in Bitcoin wallets, but These don't really seem to quite line up with with what's going on here. So there's clearly a lot a lot of other stuff happening Okay, I Would like to talk about Sort of the small nonces what is going on there? So most of the small nonces that we found were in like one cluster of 64 bit nonces almost all of which were multi-signature Addresses and They seem to be confined to a particular set of dates But this was like all of the metadata that we had we like looked for the addresses We cannot figure this out and so actually after we posted our paper online Greg Maxwell wrote to us and he's like based off of the set of characteristics. I think I know what caused this and so it turns out that There was this library written by bit pit this bit pay organization and when they They made an update to the library Update sign function to use elliptic In which they gave the wrong length of buffer for the length of the knots that they were the the lengths of the random knots that they were generating and this Update corresponds exactly with the beginning of the generation of these nonces. This was fixed relatively quickly This was fixed only a few weeks later To have the correct length of nonce. So what is going on here? Well So I've marked The two dates here So this is this is the beginning date and this is the the date in which it was fixed But by this point The data which had been fixed this library had already been forked and was being used in a number of other projects And the bug fix did not make it into these downstream projects and so it continued to be used For for quite a while afterward before being fixed so yes, I Think this has something about the fragility of ECDSA in general Okay, this may also be a familiar story to everybody who's tried to report a vulnerability or fix a vulnerability in a product So, okay more fun we can We tried looking for more 64-bit nonces since our lattice attacks We were just sort of running them on a random subset of signatures We were not guaranteed to find all of the vulnerable keys, but a 64-bit nonce you can actually Compute outright if you want so using Polydoro or baby step giant step you could basically compute a 64-bit nonce in in 32 In two to the 32 work two to the 32 work times a billion signatures is not feasible still so we Altered the parameters a little bit to try to search for this so essentially we did a pre computation we can pre-computed a Hashtable of two to the 39 elements this took up 2.2 terabytes This was sized because the largest Amount of RAM that I had on a single machine was three terabytes. So this was intended to fit into RAM And then we pre-computed a two to 32 lookup table of the logs of these elements So this took a few days on a few hundred nodes of my cluster to pre-compute So then this led us do two to the 25 work to look up signature Unfortunately, the lookup was still two to the 25 should be feasible, but because you're looking up in This huge amount of memory. There is no caching possible. And so it turns out to actually be pretty slow It's about 10 seconds per lookup Our machines to do this. So we ran it for a couple weeks and checked a random subset of 140,000 signatures and The conclude tentative conclusion that we have is that 64 bit nonces are not much more common than the ones that we found So we found most of them probably Okay, so other fun Here is a set of signatures that were generated by SSH servers that had a shared 32-bit suffix so you can see this value in blue is Shared among all of these signatures. So what is this if you Google this value? it turns out to be one of the round constants for sha2 With change byte order, of course, but I Don't know how this happened. I don't know how you like I mean I assume somebody was trying to like use like sha2 to Generate their nonces, which is like a good procedure, but I don't know how you screw up your sha2 Implementation so that you get like a fixed value in the least significant bits of this so Interesting we also have no idea what implementation this is So the final sort of screw up that I want to talk about is Probably memory unsafe code so there were 54 signatures with a shared 128 bit suffix and The shared suffixes you can look So they've been grouped by suffix here and you can see that actually if you compare these to the secret keys that were associated with the nonces the 128 least significant bits of the nonce were the same as the 128 most significant bits of the secret key Which is weird So you might hypothesize that you know a possible explanation is that somebody writes some code where they get the length of the of the secret key wrong and they accidentally like sort of overwrite a buffer and Are sort of cop start copying things into the The Key, I don't know But the thing that's really interesting about this case is that These signatures when we looked at the addresses that were Where the money was being Transferred out of a lot of them had been published on the web somewhere So they were associated with mem like memory wall memory memory wallets that had easy to guess passwords like Android or something or they were contained in like Example code from various implementations That had like just you know here's a sample address and here's how you generate like a transaction to send to that address and people had Like sent money to that address presumably copying the sample code and then someone had like then Taken the money out of that address because the the secret key was there and So our hypothesis is that these transactions were actually generated by an attacker Who is stealing money from these vulnerable addresses that have been revealed somehow already on the web And that the attackers code is the one with the memory safety vulnerabilities So I don't feel that bad about sort of dropping Oday here So There is a simple and well-known counter major to everything that I have been talking about and this has been known for years Which is to use deterministic deterministic ECDSA you can generate your secret non-spy You know hashing or HMAC or whatever your secret key and your message hash and probably like basically any combination of this is essentially secure if and there's an RFC that Does this all of the official libraries for the cryptocurrencies that we looked at Bitcoin Ethereum and Ripple already do this and have been doing it For years, so everything that we have been talking about is not from the official core libraries of these cryptocurrencies at 25519 bills and deterministic non-shed generation from the start ECDSA probably should have but it didn't so Sort of backing up a little bit Sort of what are we doing here? essentially We spent a lot of time thinking about cryptographic assumptions like as cryptographers disease explicit assumptions like discrete log is hard a hash function behaves like a random Oracle you can argue about these maybe they're secure, maybe they're not but you can actually sort of This is what we talk about like at conferences like this But there's a lot of implicit assumptions in cryptography also like the implementation is correct The random number generator is functioning the code implements all the required validation checks. We've seen this be violated multiple times today and So like it seems useful to say is to think more about these implicit assumptions when we're designing cryptographic schemes so I would Sort of hypothesize that essentially fragility under human error should be a cryptographic design consideration We know that developers will make mistakes. How do you minimize the damage? One idea is to tie security to basic functionality like say at 25519 is trying to do that like your scheme is not correctly implemented if you don't do this and We'll see how like this go like goes moving forward and sort of in general There's sort of a tension between diversity of having like a bunch of different primitives and implementations and baseline security So what we would like is to have like one library. That's like really great. It's been like formally verified. It's been vetted But then if that library breaks them like everything breaks all at once So then you might think well, okay, maybe it's good to have diversity like not everything would break at once But then you get kind of this long tail of implementations, which is what I've been exploiting in this talk so Here is my last slide. So we have Other stuff in the paper like tables with numbers and more examples of ad implementations This paper was at financial crypto this year and it is on e-print So, thank you Okay, thank you very much Nadia and there are already some questions. I can imagine that there are other questions after this as well, so Anybody question or everybody wants to go to Enjoy the reception. Okay So maybe I ask about this shot to Overflow or what was it? Can you imagine that it could be some overflow or boundary violation that could be Produced in in the code or something like that? Have you analyzed it? Yeah in the last round Possibly, I mean, I guess if these sort of like but I mean it's unclear like why sort of These values would be sort of allocated next to the value that you're produced yeah Yeah, I mean, I guess if you I guess if you like allocated this whole table and then like the next thing that's allocated is like the Buffier copy and then you and then it's the wrong length and so you accidentally like copy over into the last value. Yeah Maybe So we have we have no idea what what this library is So, I mean you can rerun the calculation and find the same list of hosts and Play with them maybe without violating the CFA and But yeah, we don't know what they are Okay, so I would say Thank you very much for attending this workshop and Enjoy the reception the second workshop day Tomorrow and the rest of the conference. So thank you very much