 Okay. Well, thank you, everyone, for joining today's virtual hyperledger meetup today. We're talking about secure multi-party computation lab. We have our speaker today, Hosein. Apologies if I'm pronouncing this wrong, but Hosein Nabazian, has seen your software engineer at SuperLogic and he will be talking about a new piece of code that will be coming soon to Hyperledger Labs. So with that, why don't you take it away, Hosein? Thank you. Hello, everyone. I'm Hosein, and today I'm going to propose our secure multi-party computation lab. I'm Hosein, a software engineer at SuperLogic, and thank you for attending to this meetup. So let's go to start up. And the agenda of this meeting would be, first, a very quick recap to ECDSA Cryptography, which is basically is required to know a little bit about ECDSA Cryptography. In order that then we can go more in depth through the NPC wallets. Then I can introduce some traditional wallets and their security issues. After that, I will introduce some NPC wallets, some of the most important NPC wallets in the markets. And basically, I'm going to introduce Trio down, which is NPC VSS and Linder and CMP. And finally, I'm going to propose our work at the NPC lab. So first of all, I'm going to verify a little bit about the ECDSA Cryptography. And before that, we need to know about what is ECDSA Cryptography system. So ECDSA Cryptography is based on elliptic curves with this formula. In fact, it is Y2 equal to X3 plus AX plus B and B are the coefficients that would be configured by ECDSA Cryptography system. And here, for example, you can see a very simple elliptic curve. So you see some points on the curve. For example, C here is shown on the curve and it's mirrored D on the other side of the curve. And then you can see the red line passing through C and D, but it doesn't meet the curve on the other point. So we define a point addition, C plus D is equal to infinity. And also we have A and B on the curve. And if we find a line passing through A and B, and we see that the line is passing through C, and then it doesn't meet any other points on the curve. So we say that we define point addition, ECDSA point addition A plus B plus C is equal to infinity. So if we combine these two terms, we see that we can conclude that A plus B is equal to D because C is equal to negative D. So we can conclude that A plus B is D. So to sum it up, we can say that if we're going to find the result of A plus B, we need to find a line passing through A and B, and it will intercept the curve on point C. And if we mirror the C to the other to the other side of the curve, we can find D and D is the result of A plus B. So this is the point addition that we define. And then, consequently, we can define point multiplications. So let's say X is a scalar and G is a point, and we're going to find the multiplication of X to G. So X multiplied by G would be big X, and we can find the results by adding G to itself for X times. So for X times, if we add G to itself, using this point addition that we introduced previously, we can find a new point, which is big X. And I should say that if we're going to find G plus G, and let's say G is here, we know how to add A and B when A and B are distinct points. But what about a point G that is going to add to itself? For this one, we should use the tangent line passing the curve at point G. And then it will, for example, let's say, meet the curve at this point, let's say P. And if we mirror the point at point R, it would be the result of G plus G. And then, again, we repeat this process for X times. So these are the basics of fundamental point addition and point multiplications defined in the ECD as a cryptograph system. So as I mentioned, in the ECD as a cryptograph system, we have an elliptic curve in the form of Y2 equal to registry plus AX plus B. So M, B are the coefficients of the curve. And then we define a base point or generator point G and order N. And these two parameters are chosen in such that N is a scalar. If N multiplied by G, the result would be infinity. So N is a prime number. So we cannot choose any arbitrary number of points and the curve as the base point. So basically, it should be found in a brute force web. And so we have point G and then we can have point 2G and point 3G. And finally, we reach the point NG, which is infinity. So 1, 2, 3, N. After that, N plus 1G would be G. N plus 2G would be 2G. And again, N plus N, which is 2N, G is, again, infinity. So that means that these points are repeated. And we say that G can generate a cyclic group. So this is basically the main feature of G that it can construct a cyclic group. So after all, we say that we say that a private key is a random scalar between 1 and N. And as we said, is the order of the group. And the public key is the multiplication of the private key to the base point. So in order to generate the key pair, we first need to generate a random number between 1 and the group order. And then the public key would be the multiplication of the private key into the base point. So each ECDSA cryptography system, we have different configurations of cryptography system based on the care of coefficients, the base point, and group order. So for example, I have, I put here the configurations of the K1, CS256, K1 ECDSA, which is used in the Bitcoin, EVM, blockchain. Configurations here you see, A parameter is 0, B is 7, and G point is mentioned here, and this is the group order. So the term A, AX is wiped out. So we have, so the care is Y2 equal to X3 plus 7. And we have also different configurations for R1 or any other variation of ECDSA. So till now we know how to create an ECDSA cryptography system. And then we know that how we can generate the key pair, but how can we sign a message? So let's say we have a message and we want to sign it by a private key D and using a private key D and it's related public key, which is shown by Q. So this signature is computed in three steps. The first step is to choose a random number and this K. So first of all we generate a random number K and then we multiply K by the public key Q and we find R. And so we know that a signature is the combination of two parameters, R and S, and the R parameter is the X coordinate of R. So we show it by R of X. And the S parameter of the signature is K inverse multiplied by M and M is the hash of the message plus R that's in the previous step multiplied by the private key. So, and so the combination of R and S would be the signature. And then, in fact, the signature is consisting of two skaters, but in most cases you will see it in a serialized form. So what we have seen as a signature is in fact the serialization of R and S. So what the wallet is? So a wallet in fact is a system that is configured with an ECGSA cryptograph system with pre-configured parameters A, B as the curve coefficients G as base point and N as group order. Again, a wallet is responsible to generate keepers and store the keepers securely and also is responsible to sign messages or transactions. So, yeah, the private key is a random scalar, the private key is calculated by Q equal to G, multiplied by G. Again, it is the base point and we know that we cannot compute the private key from public key. So based on our current technology, it is almost impossible to, it is impossible in a rational time to compute the private key from the public key. And we know that the security of the private key is very crucial because if we lose our private key, in fact, we will lose our assets. So in fact, the privacy of the security of our assets are bound to the security of the private key. So we have different types of wallets, traditional wallets. So we have web wallets and then we know some of them. Most famous web wallets are Metamask and Coinbase. Mobile wallets like Transwallet or Koninomi, desktop wallets like Exodus, hardware wallets like Ledger, Mano and Tresor Multi. Also, we have custodial wallets that are used by exchanges or enterprises or financial organizations such as Binance, Coinbase, BitGo, etc. Also, we have multi-seq wallets like Gnosis and we have a lot of wallets at the moment in the market. And the most important issue with this kind of wallets is that the entire security of the wallets and assets relies on the security of a single key. So that means that if for any reason like a breach or breaching or a wallet compromise or any other reason, if our private key explodes, then our assets will be easily stolen. And on the other hand, recovery of the key is limited to the seed phrases. So if for any reason you lose your seed phrases, you can not recover your key. So it is required that you back up your seed phrases or private keys somewhere properly and securely. So we know that the wallets mentioned till now are some kind of prone to single point of failure and they are not very secure. So the next generation of wallets are introduced as MPC wallets, so multi-party computation. And what do we mean by multi-party computation? And what are internet for? So they are supposed to be a distributed system that they generate key and store the private keys. And also they sign and they run the signing process in a distributed way. So there are several parties that are contributing together in order to generate the key, store them and sign the messages. And it is supposed that none of the parties in an MPC network has the knowledge of the wallet's private key. So that means that if a key is generated mutually by a number of parties, none of them knows any knowledge of the private key. So the entire knowledge of the private key is missing from the parties. And secondly, none of them is able to sign a message without the contribution of others. So that means that each party has a partial information of the key, the wallet key. And none of them can acquire the whole information of the private key. And none of them is able to sign a message without the contribution of others. And so if none of them has the whole information, knowledge of the private key, how do they sign a message or transaction? The answer is that each party is partially signed the message. So in the end, we aggregate all of their parties' partial computation together in order to conform the final result, which is the signature. So this is what we are intended from MPC wallets. Now I want to briefly discuss about three types of well-known MPC wallets. And the first one is based on sacred sharing or very fiber sacred sharing. In this type of MPC wallet, we have a party which is a kind of a dealer party that generates the private key and we call it D. And then the party generates a polynomial of degree k p of x, and it sets the private key as the constant value of the polynomial. So the polynomial of degree k is in the form of D plus a1x plus a2x2 plus akxk. So we have k coefficients plus D as a constant value. So in total we have k plus 1 unknowns. And okay, so the dealer party has generated this polynomial, but it doesn't share the coefficients with other parties. Let's say we have n parties in the MPC network. So, but on the other hand, from the Lagrange theory, we know that if from this polynomial we had k plus 1 points, then we can compute the polynomial. That means that the dealer is now generates n points out of the polynomial. So p1 is the p of x1, p2 is p of x2, and pn is p of xn. And then each share, each point will be shared with one party. So point p1 will be shared with party 1, p2 will be shared with party 2, and pn will be shared with party n. So in the end, each party has only one point. Okay, and so none of the party at the moment, except in the dealer party, cannot compute the private key. And it is not able to sign a message by private key because it only has only a share, only a point from this polynomial. So the question is, how can we sign a message by private key? So let's say a client is a client want to sign a message. So in this case, the client needs to retrieve k plus 1 points from the NPC network, so the parties, and then reconstruct, in fact, the private key inside the system, and then sign a message. So the procedure is that we generate the key, generate the polynomial, and extract points, end points from the polynomial and share them across NPC network, and then the client should get the k plus 1 points from the NPC network. And can compute the private keys, sign the message by private key, and that's it. So this is the process, this is how NPCVSS works. And so as we have seen, none of the parties can acquire the private key by its own share, and the system, as a whole, can tolerate the number of parties are lost or compromised. So we have n parties, if at most n minus k minus 1 of the parties are lost, still we have k plus 1 parties are working, so the NPC can work without those missing parties. So I think as we have seen, the algorithm is very easy to understand and implement, and the performance is very good, so it is very fast. But the problem with the VSS is that the private key is reconstructed by client each time to sign a message. So as you mentioned, whatever a client wants to sign a message, they need to fetch down k plus 1 shares from the network and reconstruct the private key and then sign a message. So it is to some extent good, but in most cases, it is not sufficient. And yeah, we are going to the next algorithm, which is based on Linda's algorithm, which is published by Linda, who is a cryptography scientist. And this algorithm is adopted by Coinbase, one of the series, and the algorithm is based on two-party fast DCDSA signing algorithm. So it is limited to only two parties. And the wallet key is never generated and no constructed. That means that through generation of the private key, the main wallet key is not, itself is not generated. And whenever we are going to sign a message, we don't need to reconstruct the private key. So we have two parties and both parties are required to participate in signing protocol. That means that if one of them lost or went down, the other party cannot sign the message. So it is a kind of two-of-two algorithm in comparison to VSS that it was k out of n. So in VSS we had some kind of flexibility in the number of active parties that can produce the signature. But in the Linda's algorithm, both parties must be contribute in the process to sign a message. By the way, the algorithm, as we will see, is almost easy to understand. And the performance is good, I think. And yeah, we can run it almost very fast. But as I mentioned, the problem with this algorithm is that it is restricted to the number of parties. So we should have only and only two parties. And for signing, we need both of them. So here, I'm going to briefly explain how Linda's algorithm work. First of all, how do we generate the private key? So we have two parties, p1 and p2. In the first step, party 1 generates a random number as the private key, d1 and p2 generates d2, a random number as its share of the private key. And subsequently, they can compute their public key, q1, which is d1 to g, and q2 is the public key of the party 2, which is the multiplication of d2 on the base point g. So we have d1 and d2. And the assumption is that the private key is the summation of d1 plus d2. So, and consequently, the public key is the summation of q1 and d2. So this is the first step. The second step is that each party shares its public key, not the private key. And the private key will be never exposed and shared within other parties. So each party receives the public key, and it is able to construct the wallet public key by adding both public keys q1 and q2. So yeah, this is the entire process. It is very easy. So we generate the key and share it and we construct the public key and we don't need to understand the private key. And yeah, none of the parties share its private key and the wallet key is never constructed. So how do we sign a message? So we remember that we need to generate a random number, k, and multiply it to public key q and r. And the x-coordinate of the r is the signature r parameter and then multiplying the k inverse to m plus rd, which is r multiplied by private key. We can acquire the s parameter of the signature. So here, now we have two parties, p1 and p2. Each party first generates a random k, k1 and k2. And we assume that the real k is the multiplication of k1 and k2. So this is the first step. The second step is that each party computes its r. So r1 would be a1 multiplied by q and r2 is a2 multiplied by public key. And we have the public key from the previous step in the key generation. So consequently, we can acquire the little r as the x-coordinate of each big R. So we have r1 and r2 generated by party 1 and party 2, and then they share their computed r. So both of them has the information, the knowledge of r1 and r2. And then we know that r, the final r is k2g and k is the multiplication of k1 and k2. And k1 to g is r1, so the party 2 can compute r from k2 r1 and party 1 can compute r by k1 r2. So till now each party knows the r parameter of the signature. So what about the s parameter? Before we go further to the next step and computing the s parameter, there is a very important cryptography system that we, so we need to know. It is PayLir cryptosystem. So PayLir cryptography is, in fact, PayLir key is the combination of a secret key and a public key. So each PayLir key pair has a secret and a public key. And the public key, so PayLir has the feature that we can encode the message by public key. And PayLir's secret key can decode the encoded message. That means that if we have message x, we can encode message x by the public key of PayLir. And it would be x encoded. And again, we can decode the x encoded by the secret key. And again, we can retrieve the x. And the most important feature of the PayLir cryptography system is the homographic cryptography. So that means that, for example, let's say we have x and y and relatively we have, we can encode x and y and we have, so x encoded and y encoded. So we encode x and y by public key. Then we can compute the summation of x and y encoded by adding x encoded to the y encoded. So if we need x plus y encoded, we need to compute the x encoded and y encoded and add them together. Or if we're going to compute x multiplied by y encoded, we can encode x and y and multiply both of them together. So this is the most important feature in the PayLir cryptography system. And we are using this feature in the MPC wallets. So with the PayLir cryptography, with the PayLir key, we are using in the next step to compute Esperanto of the signature. So each party has its own PayLir key and they share their PayLir public key to each other, but they never expose their PayLir secret key. So the first step would be one of the parties, let's say party one encode its private key x1 and shares this encoded private key to the other party. So it is good because the other party cannot get any information about party one private key. So party two has encoded x1 and party two is also able to compute x to an encoded by the public key. And finally by adding these two together, we can compute the private key encoded. And we know that the private key is in fact the summation of x1 and x2. And after that, we can compute r, which is computed in the previous step to x, the encoded of rx by multiplying encoded r to encoded x. And then encoded m plus rx is encoded m plus encoded rx and finally encoded k to inverse in m plus rx can be computed easily using the PayLir key. So let's say it is s2. So we have s2 encoded. So this is the partial computation done by party two and it will share this s2 encoded with party one and party one is able to decode this s2 encoded and get the k to inverse to m plus rx. And finally by multiplying k1 inverse to s2, it can compute the signature s parameter. So it is not very hard. I think the key concept in this algorithm is the PayLir cryptograph system. So as I mentioned here, we need two parties to contribute to each other to compute the signature. And we need exactly both of them and none of the party can sign a message without the contribution of the other party. So I mentioned the problem, the limitation with the NPC Lindl algorithm and it is the limitation of the algorithm to the number of parties. So NPC CMP algorithm, which is the most well known algorithm, and it is used by fireblocks at the moment. And it is, in fact, published by some scientists that the first cat of their land has conformed to this CMP. And yeah, the CMP algorithm is inspired from GG20 algorithm, but some years ago, fireblocks announced a severe algorithm level of issue in the GG20. And after that, the authors of GG20 also announced that this algorithm is obsolete and shouldn't be used because of the issue. So CMP has fixed this severe bike. And now it is, but it is when you read the, read the paper, you can understand that it is completely inspired by, inspired from GG20. So, in fact, we can say that CMP or GG20, both of them has combined VSS and Lindl's algorithm to benefit both. And they are able to generate configurable K of N private key, so we can have an MPC network of N parties. And each time that we're going to sign a message, we only need K parties out of M. And again, in, in this algorithm got in control with the VSS, the wallet key is no generated, no constructed, the same as Lindl's. And, yeah, our algorithm is very complex, understand, implement, and also it is not as fast as VSS and Lindl's. Our, the key generation is, is very slow, but they have two kinds of signing algorithm. The regular signing algorithm is very slow, but they have a kind of pre-signed algorithm that you do some computation beforehand, and then you can use those pre-computed information each time to sign a message. And these pre-signing is very fast, so as fast as VSS or Lindl's. And here is some mathematics. So I think they are a little bit complex, but very fast. I am going to recap very quickly. So we have M parties, each party generates a private key and consequently the public key. And then again they generate, each of them will generate a polynomial from their private key share. So we have N polynomials. And again from each polynomial they extract N points. And they will share, each party will share one point with one party. So these points are shared with party one. These shares will be shared with party two and these are shared with party N. And the assumption is that the wallet key is the summation of all private keys, the public key is the summation of all public keys, and the polynomial from these private keys is the summation of all polynomials. And consequently the shares that we extract from the main polynomial is the summation of all these partially computed polynomial shares. So each party is able to only compute its share from the polynomial and also the wallet public key. So none of the party has the knowledge of polynomial or the private key. And that's enough for the party to sign a message. So I think I have explained the algorithm for key generation. And the signing protocol is very complex, so I don't want to explain it in this meeting, but I will post the algorithm in simple words as a blank post in future for sure. Okay, so we have in fact verified different MPC wallets. So what is our MPC lab? So our MPC project is designed based on MPC CMP algorithm and it is developed in GoLang. And our lab is in fact consists of a GoLibrary or Package, which our library is, here is the architecture of our MPC library. So we have MPC GoLibrary of the, so that covers ECDSA, Palier, El-Yamal, Pedersen, some zero-knowledge blocks that are required in MPC protocols. And then we have the key stores. So we have in-memory key store, white system key store, database. So these types of key stores are not recommended for production for sure, but they are good enough for development. And we have white key store, which is intended for production. And also we will have HSM key store, which will be used as the backend of the wall. So in fact, in production we have white key store with the backend with HSM as its backend. And in the next version, we will have wall plugins. So most of these core libraries will be embedded, integrated into the wall plugins. And on top of the cryptographic core libraries and key store, we have crypto suits. And crypto suit is inspired by, inspired from the Hyperledger Fabric SDK crypto suit. So the crypto suit is a piece of package or library that has combined the core library, core cryptographic library and key store together in one place. And then on top of the crypto suit, we have NPC protocols. So NPC key gen, signing, presigning, backup, refresh, etc. So this is our NPC library architecture. And then apart from the library, we have NPC wallet node. And yeah, it is a wallet node that can be, that can in fact create a NPC network. So we have different NPC nodes that working together to conform an NPC network. And finally, we will have NPC wallet SDKs in Golan node and Python that are, that can be used for interacting with NPC nodes. And here is the architecture of NPC wallet node. So we have NPC core. That is in fact the NPC core library or core crypto suit library. And we have wallet driver, database driver, and they are used for connecting to database or actual vaults. And yeah, they are used by NPC core as a plug-in to, for in fact the key store. So we have metrics plug-in that can be used for connecting to metrics server like robot use. We have events that are used for event sourcing or streaming to message brokers, message queues like Kafka, Redis, or some other message brokers. Also we have like management in the system. And at the moment there, the logs are written to rotary files, but in future we will add some log management servers. And then network profile and config management are used by NPC core and other blocks in the system. And this network profile is very, very similar to what we have in Viper Leisure Fabry as connection profile. And it is used by the GRPC server for PL discovery. And on top of GRPC server we have GRPC stops and GRPC stops are used. They are like APIs that are served to other NPC nodes. And also we have a GRPC HDB reverse proxy that is used for interacting with NPC clients. So we have two types of, we have two GRPC servers, one GRPC server is used for connecting to NPC nodes. And the other GRPC server is used by the HDB reverse proxy for interacting with the NPC clients. So the roadmap is that we are gonna release our first version in the April next month. And it will include NPC GoLibrary package and NPC wallet node. And it is supposed to support ECDSA, so 256k1 which is used for EVM and Bitcoin. And it will consist, it will be, it will include in-memory file system database on world's secrets key store. And as I said, these three can be used for development but they are not recommended for production. And this one will be used, is recommended to be used for production. And we will, in the first version we've got to propose the NPC Go SDK as well as some Docker, Docker compos, and chat form scripts for deployments. And for the next steps, you're gonna add ECDSA, EDDSA and ECDSA R1 algorithms to the NPC as well as... So the first version will support NPC Key Gen and NPC Signing. But in the next step, we will release Key Refresh. And also we will support backup and retribal algorithms. And the next reviews will have NPC wallet plugins which is the most, one of the most important part of our lab. So we can move the balance of computation from the NPC server to the wallet plugins and it would be much more secure than the current version. And finally we add Node and Python to NPC SDKs. And it is not very in priority but it will be good to have NPC CLI in future for interacting with NPC for deployment and interacting with NPC nodes using the CLI. And that's it. Thank you very much and questions. Yeah, it looks like there's one question on the Zoom chat. Yeah, so it's just that... Definitely need to listen to recording to better... Yeah, definitely I think this recording will be posted to YouTube. And also I think after the first release, we will post some blights for NPC algorithm. Is it a hypervisor project? One note about that. I just put a link to the recording in the Zoom chat. So if people want to find it, I'll also email it to everybody after this as well. Yeah. And about the GitHub repo, it will be published in April. In MPC VSS, the private key is generated every time a message needs to be signed. Is the private key generated each time different, like mixed with a counter or something? So in fact, in most of these algorithms, not only for VSS, also in Windows and CMP, the key refresh, we have a key refresh algorithm. So for example, in Windows, we have D1 and D2. So after each signing, we add a random number alpha and minus random number to D2. So we generate a random number and add it to the D1 and we subtract it from D2. So it must be, so we must generate a new, we must refresh each private key such that the wallet keys are still the same as before. So we are not going to change the private key, but we definitely changed the share private key. Yeah. In fact, VSS is verifiable secretary and it is, as you know, Shamir's secretary is the most well-known secretary in the algorithm. But I have mentioned the algorithm here in a very simple words. But in production, we have verifiable secretary in order to make sure about the honesty of each party. So we need to know, we need to make sure that each party is honest. And this is the reason that we are using verifiable secretary. So VSS has some more steps for that. But here is Shamir's secretary in the algorithm, in fact. And yeah, we have more steps using some commitments like Pedersen or other kinds of commitments or verifying the honesty of each party. Yeah, definitely. I will suggest references. So the best reference to each of them would be the papers. So for example, for leaders, we have a paper name, I think. A two-party fast, two-party fast is a signing algorithm. And for GG20, we have, if you search GG20, if you Google GG20, you can find the paper. And also if you search NPCCMP algorithm, you can find it. So yeah, I think the best resource would be the papers. But as I said, GG20 and CMP, both of them are almost the same, except that CMP has fixed some problems. Yes, NPCCM Fire Blocks has published C++ code of the CMP. Yeah, and we have used a lot from the open source resources. Are there any other questions? And I'm not seeing any questions on YouTube. Oh, I see a couple more. A couple more questions came in. Justine, would you like to address the channel, the questions that just came in on the chat channel? Yeah, I would like to ask, is this an official project from Linus Foundation of Prius? Yeah, it will be released in future. Any discussion, not yet, but I think after the first version. What I can do is when the project has been, when this has been released as a lab and when there is a discord channel, I can email everybody who signed up to this meetup and share those details. Great. Any other questions? Well, if not, we certainly would look forward to continuing the discussion with you as we were just saying there will be a lab coming. There will be a chat channel where we can bring the discussions. You know, Jose and you're certainly invited to do more meetups in the future. So for now, what I can do is I can send the recording to everybody who signed up. And if you share these sides with me, I can share the sides with everybody as well. And then we'll follow up with people soon when the lab and the channel is available. So those can be the immediate next steps. But if you have any questions in the meantime, certainly I think maybe reaching out to Hussein directly on LinkedIn, maybe a good next step. And then we will follow up with you again soon with more of a community channel when that becomes available. Yeah. And as I was just seeing a question came in about can you share the PowerPoint? Yeah, I was just saying that I will email everybody the presentation Hussein if you're able to share that with me. I will email it out to everybody. And thanks for your time today, Hussein, everybody else. And yeah, again, looking forward to continuing the discussion with you. Thanks, everyone.