 So, hello ladies and gentlemen. I'm here today to share my, our experience on creating the pluggable crypto, crypto provider for Ethereum nodes and which we used in a master chain project. So who we are, I am Dmitry Boschko, I am the crypto core developer at master chain project and the one man who I want to introduce who unfortunately couldn't come here to this great conference, it's Alexei Troshchev and he is master chain architect. So what is master chain? Master chain is a Russian national platform for storing and exchanging financial data based on blockchain technology. So the two key words in this definition is national and blockchain. So we've chosen the public Ethereum protocol for, as a basis for master chain project. Why we do that? Because the first Ethereum protocol have a large experience with work in the wild. Of course it has supports, it has smart contracts and it has a big community, it had a big community and has big community and this community is gross and solves many, many new issues. So this platform wouldn't be abandoned. So what is master chain? It's a fork, it's a fork of public Ethereum protocol. It also supports of course smart contracts and the main difference is it based on ghost crypto. Ghost crypto stands for government standards crypto. It is the main standard in Russian Federation for all cryptography. If you're interested you could just read the white paper for master chain project. This link is for this white paper. So why we have to use the custom cryptography? The second and the first and the main, it is because only government standards crypto algorithms have legal power. So if you want to build any system which involves any kind of cryptography, your cryptography in Russian Federation should be the ghost. But not just only your own implementation of ghost, it has to be certified by Russian Federal Security Services. Not only your only step or your solution has to be certified by FSB yet. But cryptography is definitely that kind of what you need to certified in Russian Federation. So there are only a few certified crypto service providers have to be used. And you can say, I can implement the ghost myself and get certified it, no. You could probably do that but it's extremely, extremely difficult. That's why only a few vendors of CSPs are presented in the market, in the Russian market. So we used for our project is CryptoProt CSP440. And what's the main difference? What does ghost crypto algorithms family consists? The first one is the hash function. The hash function is ghost R3411212. It calls Stribak, calls for Slavic God. And it has two modes, 256 bits and 512 bits. But in our project master chain we used only 256 bits. So the second is the ICDSA algorithms for digital signature. It calls ghost R34102012 and it doesn't have the specific nickname. It supports 256 bit curves and 512 bit curves with different parameters for each curve. We used 256 bit curve with the paramset A. Also it has a symmetric K block cipher, still running ghost 24147 developed in 1989, it calls Magma. There is a new modern algorithm, which were built in 215, it calls Kuznetchik. But he still doesn't have the certified implementation, so we couldn't use it. And the last operation, it's several operations for transport security, the Diffie-Hellman Scheme, and it works with ICDSA ghost algorithm and with symmetric K block cipher with Magma. And in Cryptoprote CSP there is a certified implementation of TLS protocols. So we've decided to choose this one for our project. So what was Ethereum Crypto undercover before we started? We started at version 1.5 and it looks like it was a big mess because there were Crypto module which had a wrapper for crypto hashes, for ICDSA, ACs implementation, and for implementation of curve secp256k1 built for Bitcoin. And it wraps all those functions in one Crypto module. But suddenly there were redundant calls from P2P communication system, from mining system, from EVM, directly calls to those functions. So we decided to redesign it. We've built a single Crypto adapter which were transparent for all business logic, nodes business logic calls. This Crypto adapter have unified calls to a wrapper interface. And each library, like CSP wrapper, like GhostR wrapper, or any other wrapper you can write by your own. So each of this wrapper implements this wrapper interface and wraps the exactly library. So first we've choose the open source GhostR so we can just test that all functions that were present in the original Ethereum are switchable to the new Cryptography. And then after that we've built that CSP wrapper for third party library CryptoProt CSP which is a black box for us. And this scheme is kind of work very good. So and it builds like that so you can implement your own Crypto wrapper which would wrap your own Crypto library. In fact you can do the mixed mode, use the NIST Cryptography or Ghost Cryptography in the same way. So what have exactly we switched from Ethereum to master chain? The three types of hashes, SHA-256, SHA-3 in two modes, 256 bits and 512 bits. We switched it to Streebug. It's CDSAE and SecP256K1, we've switched to GhostR CDSAE with 256-bit curve with Paramsat A. And we've redeveloped the ecrecover function. I will tell you a bit more later on the next slide about this. But we've implemented the compressed signature for Ghost Algorithm family. So ecrecover works now very good. It recovers the pop key from compressed signature. But then you have to verify it with the certified verification function from the CSP. So it also works with 256-bit curves with Paramsat A on master chain. The symmetric cryptography, which were used in RLPX encryption between the communication of two nodes, it was ACE, it switched to magma, symmetric ciphers with 256-bit key and block size of 64-bits for magma, switched from 124-bits from ACE. And of course we've read out of RLPX encryption. Why that? Because I thought, as I said, if you have certified implementation of one part of any cryptographic function, it doesn't mean that the whole solution are certified by itself. So that's why we have two ways. The first way is trying to certify in FSB the whole RLPX encryption protocol. Or just switched it to certified TLS. So we've chose the second one. And the Ethereum protocol in communication, RLP, is... So we just switched the encryption. Everything which is going through are stents like in the original Ethereum. So about compressed signature. Because of the different algebra when you're working with curves in Ghost Standard, we have to reproduce compressed signature which was used in NIST curves in Bitcoin and in Ethereum. So we did find a way. But it was something interesting because a recover function was created without modification of original certified CSP. That's why we have to call the verification function on this. So first of all, you're going to restore the POP key from the compressed signature. And then you have to give the verification function the original signature and the restored POP key. That solution would be certified. And the last one, we've implemented Node's wide list as a smart contract for authorized communication and for authorized mining. It was a requirement for FinTech association. So crypto-algorithms complained with these requirements can be used with our crypto-adapter transparently for the rest of Ethereum logic. And again, the hash function in 256-bit modes at CDSA with 256-bit curves, your compressed signature support with 256-bit curves, and symmetric block cipher with 256-bits and block size 128 or 64-bits. And if you implement your own TLS protocol, you should do it because you cannot communicate with Node's in master chain without disimplementation. So I was glad to talk about some cryptography so you can ask some questions for me right right after this presentation. Have a nice day.