 Okay, thank you very much So threshold cryptography dates back to the late 80s already and a lot of work done in the 90s and the idea was that you would have a number of parties sharing a private key for Decryption or for signing and you would need some authorized subset in order to carry out any of the operation any Assigning operation or any decryption operation and there are many applications for a threshold cryptography You can think of multi-signatory applications. So you want to have some two out of five People in the company signing on a check or or something to that effect More recently there's been a lot of interest in this due to its application to key protection So you want to keep your secret key safe? You can either put it in dedicated hardware, but that can be problematic in many situations So you can split it and put the different key shares on different machines Protect them with the different operating systems in different environments different administrators and make it hard for an attacker To get to all parts of the key and therefore keep it safe And this is actually now being deployed in practice and the number of startups doing this We know already from a couple of decades ago that RSA in El Gamal ECIS which is again, just if you Herman schnore signatures all of these can be done very very efficiently even if you have malicious adversaries who Will run any arbitrary attack strategy to try and break the protocol Can be we can protect against that using very efficient zero-knowledge proofs inside these protocols and and we and these This is really a solved problem. We can do this very very efficiently in Contrast DSA and EC DSA are very expensive by the way I'm going to talk about EC DSA, but it's exactly the same for DSA because everything here is just generic in the group In particular, the best two-party protocol takes Numerous seconds for a single signature and that's a very significant overhead and it also has an extremely expensive key generation Protocol, so it's problematic to actually deploy such a solution The question is why why is EC DSA so much harder than all of these other? all of these other protocols or these other Encryption and and and signing schemes. The reason is that it has this strange or unusual feature that you have to generate this random value K and And it's inverse and these have to be secret and not not known to both parties And it's actually non-trivial in multi-party computation to generate Shares of a random value and its inverse and that makes it actually very very difficult So just to elaborate a little bit on that Let's compare schnoir signing to EC DSA signing or what happened when we try to naturally make a two-party protocol for these for these signing schemes, so in both of these Signing schemes you choose a random K from ZQ or Q is the order of the group and you compute An elliptic curve point R, which is K times G where G is the base or generator points of the curve In schnoir you then hash the message together with that point And in EC DSA you do something different you take the X portion of the point Which anyway has the bulk of the entropy and you reduce it mod Q and you get a small R And now you have something completely different for schnoir You have a linear equation, which is just K minus X times E and in EC DSA You take the inverse of K and you multiply it by the hash of the message plus R times X You do all that mod Q and you output R and S and schnoir you output E So you can see that schnoir the whole way through is just very linear except for the hash function Where the EC DSA has this K inverse which which makes things problematic So let's do a two-party schnoir signing so we have the secret key X and The natural thing to do is to have each party hold an additive share of X So P1 a hold X1 P2 hold X2 and the sum of the these is the actually the secret key And of course, they're random under that constraint. You need to choose a random K Well, that's also pretty easy P1 will choose K1 P2 will choose K2 and And they can even define a local R1 and R2 value by multiplying that by the point by the base point And then they can compute R by simply summing those together Okay, so this is very very easy to do in very efficiently once they know R They can each locally compute E because it's a hash of the message and R and Then they need to compute this final equation this S equation So each one can again locally do this a P1 will compute S1 To equal K1 minus X1 times E P2 likewise and you just sum those together and you get the signature So it's all linear or very nice You have to add some very basic zero-knowledge proofs here But it's very very efficient and everything works very nicely if you try to do this in EC DSA Everything sort of messes up at this at the stage of trying to compute S because of the K inverse if you have additive shares of K It's very hard to compute additive shares of K inverse and you sort of have this choice either we have additive shares and Then getting shares of K inverse is hard or maybe we'll try multiplicative shares But then combining the the different values to get S is going to also be very hard And so everything sort of breaks down now in the the mid 90s. There was work on this for the multi-party setting with an honest majority done by Langford and then done by Genaro, Yareki, Kravchik and and and Rabin But I'm going to focus on the two-party setting and with in that case. Obviously, there's no honest majority So it's just quickly rewrite EC DSA and what I want you to notice is just that there's this S part has two separate Sub-equations the left hand red side and the right hand purple side and we're going to have to deal with these separately Which is why I've colored them differently and I'm going to put that up in the top right hand corner so you can follow the the see see the The basic signing scheme the whole way through so Mackenzie Ryder with the first 16 years ago here at crypto with the first to actually Provide a protocol for the two-party case and their approach was as follows firstly They said additively sharing is going to be difficult. So let's Multiplicative share the values so parties the parties hold x1 and x2 Which are random under the constraint that the product of x1 and x2 equals x. That's not a problem and Since we have to make this consistent throughout instead of additively sharing K. They'll multiplicity Multiplicatively share K as well. So P1 will choose K1 P2 K2 and and K will be K1 times K2 And then our of course will be K times G and this is actually just if you home and key exchange You can see that P1 will send K1 times G P2 will send K2 times G and they can each locally compute K1 times K2 times G so this is actually very easy to do once they have this value are That that lets them go to the next step And also since the K the sharing of K is multiplicative They can each locally compute an inverse of their portion of K and now they have Shares also of K inverse. So we've solved the problem of K inverse and everything is okay And each can also compute this are which is our X mod Q. So what becomes now difficult? What's difficult is computing s because we don't have additive shares and this is An linear linear equation or at least of K inverse But what they do has have is they have our and they have shares of both K and X and Now what McKenzie writers say is let's use pire, which is additively homomorphic in order to finish this computation so P1 generates a pire key pair and Can then encrypt each part of this equation separately using its own values so P1 will encrypt K1 inverse times the hash of the message, which is his portion of the left-hand side and Will also encrypt K1 inverse times X1 times out Which is again his own portion of the right-hand side of the purple side and we'll send that to p2 now p2 can use the Additively homomorphic properties of pire to finish the signature. How can you do that? multiply the left-hand side by Its own portion of K2 inverse and multiply the right-hand side by its portion of K2 inverse times X2 And what you now get is you get two two encryptions One is of K inverse times the hash of the message and the second Second Cypher text is an encryption of K inverse times X times R and all you now need to do is just add them together Luckily to add it to be homomorphic encryption so you can add them together P2 can then send that back to P1 who will decrypt and get the signature So everything is fine Just small caveat you have to have to add noise because inside pire encryption. You're working over a Large ring you're not working mod q so you add noise in order to to distort any difference here So this seems very good. What's the problem? The problem is that in the case of malicious adversaries when you want to force the parties to actually behave honestly and do the Correct thing it becomes Really really hard to prove that you're behaving honestly in particular for one just one example P1 needs to prove that the encryptions that it sends contain K1 inverse now It's true that cake that P2 has some function of K1 Which is our one which is K1 times g but doesn't have anything which is a function of K1 inverse It's very very hard It's very unclear how you can even prove such a relation in an efficient way And actually if you look at the McKenzie writer paper There's zero-knowledge proofs go span about a page and a half of equations of Computations and exponentiation that have to be proven and there's an auxiliary Pire public key and there's a whole lot of other things and it's really really really expensive to do There's been a number of follow-up works to McKenzie writer They've all reduced the cost of these zero-knowledge proofs But they're still very very expensive and there's still a very big bottleneck because proving that you're behaving correctly here Is very very difficult. So what can we do? Our approach is we is to try and remove all of these expensive zero-knowledge proofs We still have some zero-knowledge proofs a very cheap discrete log Like proving you know the discrete log of something which is just actually a local Schnorr signature So that's really really efficient and the way that we do this is we still keep to the McKenzie writer paradigm So they have the parties have multiplicative shares of X But we also assume that P2 has an encryption of X1 under party P1's Pire public key So and we can take care of this during setup So it's assumed now now that P2 has an encryption of X1 and knows that it's a valid encryption of X1 Of course, it doesn't know what's inside because the key belongs the private key belongs to to P1 We can do this in the setup and we'll see now. This actually makes everything really really easy And that's actually the the main observation of that of this entire paper So the first step and you can see the bottom right in yellow I will see we'll show what what I'm talking about there which part of the signing operation we're talking about and As in McKenzie writer the parties will run a Diffie-Helman key exchange to generate this value R I call it a simulatable Diffie-Helman key exchange It has some zero-knowledge proofs inside for a discrete log it has some commitments But it's basically just a key exchange to compute Multipleted shares of K and to get R which is K1 times K2 times times G and then again Both parties can locally compute R to be our X mod Q because they both know now the the relative elliptic curve point R and And this is very efficient and very simple What's interesting now is look at what P2 has P2 has the curve point R Has its shares of of the secret key so you and K so at X2 and K2 Obviously also has K2 inverse because it's it's its own share and also has an encryption of X1 And if you look closely here, what you see is that actually P2 can now work completely by itself to compute what I call an almost signature an almost signature is a signature But instead of having K inverse there it has K2 inverse But everything else is a full signature and it can do this all by itself without interacting at all with P1 how P2 can encrypt K2 inverse times H of M because these are values that it knows it can also encrypt K2 inverse times R times X2 times X1 Why can it do times X1 because it has the encryption of X1 to start with so again This is scalar multiplication inside additively homomorphic encryption if you look at what this is this is actually a The only difference in this and a full signature is that you have to multiply it by K1 inverse That's the only difference between them and in fact not only is that the only difference This is that means that given a real signature You can actually even generate this value yourself P1 could generate this value itself by multiplying But by multiplying it by K1 so this value reveals nothing to P1 So P2 can compute this value by itself, which is an almost signature Inside the encryption and just send the ciphertext to P1 and P1 As in McKenzie, right? You add some noise, but we're ignoring that for now And P1 has the curve point R K1 X1 and the ciphertext of which the encryption of the almost signature just decrypts multiplies the almost signature by K1 inverse and it's finished it now has Has completed the signature and there's almost no interaction and mainly local work done by the parties What then party P1 does is just verify this is a valid signature and we're completely finished so it's no longer pages of Complex zero-knowledge proofs and actually in practice. It's not just efficiency It's also simplicity the protocol which is important if you actually want to deploy this and and this is a diagram Of all you have a simulatable Diffie-Helman key exchange followed by P2 doing local work Sending a ciphertext to P1 P1 decrypts and and you're done and multiplies by K1 inverse and you're done question is why is this secure and how is it suddenly magically solved all the problems of cheating so In order to understand that let's look at the security. Let's argue security for this protocol What happens if P1 is malicious so P1 is malicious wants to cheat The only thing that P1 does is participate in this simulatable Diffie-Helman key exchange And you can't cheat in this all you get to do is send Your part of the key exchange and you have to prove that you know the discrete log But that's again very easy. You can't cheat. There's nothing that P1 can do P1 Just gets a ciphertext from P2 and decrypts and multiplies it by something and outputs it It can multiply by the wrong value just means it eat itself will get an invalid signature Won't make any difference whatsoever So P1 a malicious P1 can't do anything and we've saved all of the zero-knowledge proofs that P1 had to send a P2 because There's nothing that P1 is doing here at all. What about P2 and that's the interesting question The observation here is that we're not computing a general secure Computation function. We're computing a digital signature and what that means is that when P so what's the danger of the Danger that P2 can send an invalid message to P1 because P2 is malicious So instead of doing this correct homomorphic operations P2 could send something some arbitrary garbage or something which is incorrect And and and P1 how can P1 know the answer is very simply P1 can know because the digital signature scheme So when P1 gets the value Decrypts and multiplies it by K1 inverse P1 can just check that the signature is correct and that means that if P2 Tries to cheat it's not going to help because if it's an incorrect value P1 will know it's an incorrect value Simply by verifying that the signature is correct And you don't need any zero-knowledge or a knowledge proof anymore because correctness is valid They just by verifying the signature and that makes it all very simple and very very efficient There is one thing that you might and might be bothering in if it's not it'll bother you now once I say it maybe P2 can generate a Cypher text that just knowing whether the Cypher text actually is a Valid results in a valid signature or not will reduce will reveal information about the secret key First you should know you should notice it can only reveal a single bit because that's the only information that there is and This is indeed a problem So we get around this in two ways and this is all in the paper One is by using a game-based definition and in game-based definition You can just simply guess the first point at which the adversary gives you a bad signature and then and and everything goes through And we can also prove it under a full simulation based definition using a very strange Weird assumption so that's in the paper as well And if you're into weird assumptions, which seems to be very popular these days anyway Then you could take that and and and be happier, but actually the game-based definition I think is very very convincing No zero knowledge proofs just using the fact that it's a signature scheme and you can verify and everything is okay. What about key generation? so the key generation phase like Generating the multiplicative shares of K does a simulated little Diffie-Helman key exchange and that's easy We send x1 times g x2 times g and you can each locally compute the public key Which is x1 times x2 times g that's very very cheap, but remember we needed to have p1 Send an encryption of x1 to p2 under its own public key and and p2 has to be sure this is correct This is a very crucial point if p2 if p1 sends an incorrect value Then when p2 sends back the cypher takes the p1 it may reveal information about p2 secret key to a malicious p1 So we have to be very very careful about that So we construct a very specific zero knowledge proof to prove this this statement So this is actually not a difficult statement to prove because there are no inverses or anything you have p p2 Actually has x1 times g because that's sent in as part of the firm and key exchange And you want to prove that that's actually the value that's inside the pyr encryption So it's an interesting zero knowledge proof because it bridges between two completely different worlds You're given an elliptic curve point x1 times g and you need to prove that x1 is inside this pyr encryption But it turns out to be not not so difficult to do not not not so expensive to do it But that's the most involved part of the entire protocol. That's only done at key generation So what's the performance of our protocol? We implemented or ran it on a juror with standard just very standard instances on single core and this is actually inside a product so it's like a full with a full environment and the parties communicate over TLS and there are no shortcuts here and Key generation takes Between 4.8 and and 7.8 seconds. I'll explain this jump in a second that's done only once so that's actually very reasonable and and Signing actually takes only tens of milliseconds. You can actually sign a few hundred ecd say Signatures a second using just a single core Obviously if you want higher throughput then you can simply increase the number of cores latency is what you have here This is actually 80 to 100 times faster than the previous best protocol So that makes a very very big difference and in terms of key generation It's actually thousands of times faster because the previous best protocol needed Distributed RSA key generation as part of the protocol and that's very very very expensive for in key generation Now why does it jump? Why does suddenly the the cost jump when you go from from the 384 bit curve to the 521 bit curve The reason is that you actually need Because of this noise that I mentioned you added you need the paella key to be at least four times the size of the group order Now we're always taking 2048 bit paella anyway The modules is always going to be that size because that's the mineral size for security So for p256 and p384 it's it's a 2048 bit key But at 521 times four you have to make it a little bit bigger But because paella is the real bottleneck in this entire thing images making it a little bit bigger 80 bits bigger Actually causes this very big jump in in running time, especially for for key generation And and a lot of work is actually we did a lot of work to Reduce the amount of noise you needed to add in previous protocols You had to make it eight times or nine times larger and that would of course kill everything and slow it down by a lot So in conclusion, we have a new security CDSA protocol for two parties It's much simpler than previous protocols because it doesn't have any of these very complex zero-knowledge proof So distributed RSA key generation and so on and so forth has efficient key generation in signing It can run on servers We also it's also runs between a mobile in a server very efficiently without any problem And it's fast enough for many applications. You could think of Bitcoin signing if you wanted but key protection in general And it's fast enough and works very well in all of those settings. Thank you very much