 Привет. Вы меня хорошо работаете? Да. Окей. Меня зовут Дмитрий Пелевский. Я говорю о истории, о продавании русских криптовых алгоритм в OpenSSL Kit. Хотя это содержит некоторые детали русских, это будет полезно для тех, кто хочет продать новую крипту. Я думаю, не только для OpenSSL, но и для любой функциональной криптовой криптовой. Итак, кто я? Как я сказал, я Митрий Пелевский. Я читаю OpenSSL Code с 2005 года. Иногда я понимаю, что происходит, иногда я не понимаю, особенно в тех, что касается постоянного времени. Моя главная работа currently is Russian Cryptographical Company, Cryptocom Limited. Я директор, и я тоже participated in various OpenSource projects, mostly related either to cryptography or to domain registration stuff. Итак, first of all, what is Russian Ghost itself? It's a set of cryptographical algorithms. The eldest one was approved in 1989 at Soviet Union time. At that time it treated as a bit paranoidal with its very long K, but it's still alive and the concurrence who will have gone. Russian standards include both first class algorithms, full stack of them, such as block ciphers, message authentication, of course digits, of course digital signature. But these algorithms themselves are almost not usable with our supplementary algorithms. We need a pseudo-random function, we need the derivation of the shared K, we need various functions related to K-Rap, and so on and so forth. So the history for me begins in 2005, when the company I worked it was a Cryptocom Limited time too. It was my prepreviews work, not only current decided that we should provide support of Russian Ghost Crypto and various, in this or that worldwide use toolkit because self-designed formats weren't convenient and we wanted to use worldwide ones. At that moment we studied, in fact, three variants, OpenSSL, GNUT LS, which was not major enough at that moment, and NSS. We've chosen OpenSSL, I don't remember the exact reasons, and then we decided to look into the code. So the first we've seen was many, many case switching in the parts of code related to digital signature. It looked like case RSA without this, case DSA without that. Sometimes there were some cases where something was done when we had elliptic curves cryptography. It was very long ago. We thought whether we have to add the case Ghost, decided not to do it, and took a more closer look at the engine subsystem. It was a way to provide plugins that could carry the implementation of ciphers, of message digest, and of custom, for example, hardware of load, implementation of worldwide algorithms or random number of generations. And the last but not least, we've seen that the main body of code contained hard-coded algorithm clearing. Shawan was the king at that moment, and well, okay, you can use any digital signature algorithm if your digest is Shawan. It didn't fit our purposes because our standards required that only Russian Ghost function should be used with Russian Ghost signature. And in the study we decided that the best way will be writing a custom patch that will implement callback structures for digital signature algorithms as it was already done for ciphers and digest. And then we thought when we write it, we provide it to upstream, they will accept our patch and everything will get brilliant. So here is a very brief history of Ghost implementation in OpenSSL. In the branch 098 we implemented a separate patch, which has broken binary compatibility, but we expected that it will be a good starting point to discuss. Then, for some time, Ghost Engine was a part of OpenSSL bundle. Then it moved to a separate project. For now, in the main stable branch 1.1.1, we have a chain of breaks and fixes. It's a normal process for not widely used functions. And there is a branch for walking progress, where I am implementing the current Russian Taylor standards. So when we have finished the first version of patch, for the 098 version, we were happy that we did it. Everything was OK with OpenSSL self-test. And we published our patch at the OpenSSL web mailing list and waited, well, not immediately accepted, but at least we were waiting for this or that reaction. As far as I remember, the only comment we got was that we should switch comments from C++ style to C style. It was rather discouraging at that moment. So then it took us about half a year to implement the patch. And then for about four or five months we did not know what to do with it. Because there was no discussion, there was no public interest. We made some presentation at various developer conference, but it was not our aim, because we had to adopt this patch to the changing versions of OpenSSL itself. And it was rather time consuming. So we needed to push this patch to the main codebase of OpenSSL. At that moment I noted that the signature of one of the OpenSSL team members, Dr. Steven Hansen, contained the line, we need funding and we will discuss the suggestion of work. Our bosses came into contact with OpenSSL team directly with Steven, if I'm not mistaken. And began the process of the integration of the library to upstream. It was finally added to version 1.0. And this version contained a lot of changes, but I will say about those that were the most important for us. There appeared a concept of public key context, pkcpx. There appeared two code structures, one to implement the crypto operations themselves. And the other two with ISM.1 encoding, decoding, and so on and so forth. And the reference implementation of Russian ghost cryptography, which became part of engine subdirectory. Well, and mention two points, which are the lower part of the slide, because they will be repeated again and again and again during the rest of my presentation. There are a lot of fixed internal lists in OpenSSL, enumeration of algorithms, enumeration of aides, enumeration of cypher models, on and on and on. And in fact, every changes in stand-ups requires changing in this list. And OpenSSL team treats it as a breaking compatibility, and I'm afraid they are right. I'm afraid they are more right than I am. And the other problem was, we tried to implement code structures in the LibSSL, which was a TLSSSL stack. But in fact, we didn't succeed because of some support of legacy, Cypher's use, and because of, well, at that moment, more irregular structure of the LibSSL itself. LibCrypto was more regular at that time. So, it was okay till 2014, when the HardLead vulnerability was published. At that moment, the OpenSSL team was significantly underfunded. So, when HardLead occurred, the community understood that, guys, we have a very important product, which is developed without regular procedures, underfunded people. So, it means that such incidents will repeat again and again. So, something should be done. And from OpenSSL team, OpenSSL management team was reformatted. The processes were set up. Now there are strict processes of reviewing the patches. Now there are public roadmaps. So, in fact, it means that, after HardLead occurred, the modern history of OpenSSL began. And now it's significantly much more secure than it was before, both in process and in code. In 2015, I met some people from the OpenSSL team during one of ITF meetings. I met Rich Salz, who is a well-known person in ITF cryptography community. And he was very in agreement. How should we deal with Ghost cryptography in OpenSSL? At first, the problem is that nobody in main OpenSSL team is interested enough in Ghost support. So, nobody was interested either to provide new algorithms or to fix something. And at that moment, we came to agreement that the engine should be moved to a separate project. But patches, which are not algorithm-specific but Russian protocol-specific, will go to the main tree and so it was a process that took three months to make support of Russian Ghost matching the new OpenSSL standards. It made me significantly rewrite the patch, in fact. I was very happy when the patch was accepted to main tree. At last, now I'm sure it compiles every changes. Of course, as new Russian Crypto standards were developed since 2005-2015, there were again changes in internal list. It was a more clear design of the Libre-SSL to that moment, so various support of Russian specific was moved to separate callbacks. And I hope that there will be a day when these callbacks will be fully encapsulated in engine, so it will significantly remove the process of negotiation of what to do with it. So, it was accepted and Russian TLS became first class variations of protocol at 1.1.0 branch. Currently, if you download OpenSSL you get support of standards that were penalized in Russia until approximately 2014. As I mentioned before, there are some work-in-progress branches. Ghost Engine became a separate package and it's available at least in Fedora, in Debian, in Russian widely used distribution as Linux and some other distributions less popular. There is a problem that as Russian crypto-algorithms are not worldwide standardized. We have a lack of packages containing certificates of trusted CAs. It's a really big problem. And last but not least we have a problem with Red Hat specifics, with Cryptopodes. Because I understand why Red Hat people don't want to have anything to do with Ghost. I think sooner or later we'll get an agreement how it can be without breaking the compatibility and system ideology. And maybe Ghost specific crypto policy will become a part of Red Hat package of Ghost Engine. Oh no! There are a lot of problems and interactions because of course customization has separate timeline which has nothing to do with OpenSSL process. So the best solution we have is distribution patches to main code of OpenSSL together with Engine for those who really wants to support brand new variations they will have to rebuild OpenSSL sometimes. But most of these patches are usually accepted to main code base. Of course Ghost has low priority for the world outside of Russia. We understand it. Yes. Of course we still have a problem of extending hard calling lease. And we will have it forever. It's okay. And we have a relatively poor state of international civilization of Ghost Algorithms though a lot of documents are published as informational RFCs so we are working on it. Here is the list of Algorithms which were supported in various versions of the Engine. I don't think it's interesting, it's just for information so you see that deprecator standards are fading out and new standards are implementing. It's okay. We have Russian national standards for X509 profile PXS10 We have national standards for PXS8 and PXS12 Of course we have standards for SMIME CMS Of course we have standards for TLS It's the main purpose for our clients but till the last versions it was impossible to implement DTLS using Ghost because some extra protection was not DTLS friendly it requires fixed order of packets to be delivered New TLS specification allow using DTLS There are walking progress specifications which are partly finalized in Russian partly implemented in code so I hope that sooner or later they will be part of Open Selling at least in TLS part and some additions in CMS and X509 And of course we have standard set of supplementary algorithm HMAC, BRF Many of them The next one Ghost or any in fact any non-standard crypto in OpenSSL Well, you still need to support it in the application that use crypto libraries For the most cases if the application uses the modern API you can just load configuration file ensure that engine providing the algorithms is loaded with the configuration file and everything will be more or less ok There are still now some legacy applications I marked them we know about RSA It means that in most cases you have to rewrite from this or that algorithm specific API to universal API to EVP API And sometimes for example the product of Cryptocom Open VPN Ghost we had to look into the protocol and carefully replace basic primitives to Russian Ghost specific and it's relatively rare case but you should take it into account Well Problem which stays unsolved till now is the support of Russian crypto in Java There are at least three Java implementations of Russian crypto There is a Wildfly OpenSSL Java library which uses OpenSSL and crypto provider I tried to provide to provide the ghost algorithms, ghost cyclers use ads in this library but I did not have any success First of all, because I almost don't know Java Loading the configuration the file did not help me so I hope that somewhere this work will be done and we will have support of in fact any as I told before any national cryptography in this script provider So, ok we took a wildwiple kit We used a lot of did not want write ourselves, such as I send out one library and many many other So, what do we give to community? First of all I think that Russian ghost engine using it is the most comprehensive testing of the engine subsystem in OpenSSL Then I should mention I should mention 2 bugs found during implementation of new standards The first was a very nasty bag that elliptic curves matter was changed in shortly before 1.1.1 version was released we found that it works with sub curves used in ghost because points on elliptic curves people who did this change they agreed that it was a bug and fixed bug I think relatively significant was stacker's exhaustion during TLS can shake though I don't think it was acceptable outside but anyway it's better to have it fixed As Russia is where non-latin base script is used of course we had a lot of problems related to internalization so some patches providing more support of non-latin scripts was fixed and now I have a side project related to support email address international in X509 I hope it will be finalized Yes, many people don't like email address international I don't like them too but as there are people in such countries as China Thailand and many others where alphabet has nothing common with Latin people will need these scripts to deal with it that way then I hope that sooner or later we will move some national specific structures to we will convert some national specific structures to form that will be managed via engine and it will allow to simplify the main code base of crypto library Of course a lot of memory leaks a lot of small bugs were fixed I want to mention a project we made by one of participants of ghost engine development who provided support of Russian hash Stribog in the Linux kernel if I'm not mistaken version 4.21 will continue Here are the relevant links to the presentation link to ghost engine itself then for those who based it and doesn't know where open cell code lives here the link to open cell well this may be the most important link in this presentation it's a brilliant paper describing writing custom engine in open cell and everyone who wants to write hardware acceleration or something else must read this article not should but must then here is the link to Russian crypto standard body enumeration of RFCs covering Russian crypto algorithms here is the document describing new Russian TLS I actively participate in this work and here are two mailing list dedicated first to Russian cryptography in open source products and the second is dedicated to ghost engine itself well the language currently is Russian but if you write in English of course you will be answered last but not least for those who cooperated with us during the well almost 15 years of development of Russian ghost first of all I should mention people from Open cell team Dr. Stevie Henson mentioned before Rich Salz mentioned before Richard Levitt and Matt Caswell they were very cooperative and did a lot to make possible to provide Russian ghost crypto in the main code base then I want to thank people from Red Hat team Thomas Mraz Alexander Bakavoy many thanks without the efforts it was almost impossible to implement ghost engine as a package in Fedora I want to thank some people from Russian cryptography community Vasily Dolmatov Vartan Khacheturov Igor Ustinov, Stanislav Smyshev who actively participate in national standardization of Russian algorithms and protocols and they provide help when it's necessary I want to thank people from Alexey Novodvorsky, Dmitry Levin Gleb Malinovsky, Vitaly Chikunov for the efforts in improving and development of the engine and of course I want to thank to those who contributed in the engine code itself and Artyom Tufrin who worked in Crypto.com and provided a basic version of the engine Alexey Diktyrov who implemented who provided a very fast implementation of modern Russian hash functions Max Tishkov who implemented Kuznetchik Russian modern cypher algorithms and many other people who I don't remember all of them unfortunately but of course they the efforts were significant for providing Russian ghost in PLS Thank you very much if you have questions please I'm here I'm ready to answer them I don't think more things into the comebacks and engine but on the other hand Chinese got their SM Cypher's directly into the open SSL code and I heard that at least it was like some email or some discussion I don't know if it was on GitHub open SSL or something that there is some interest establishment in the standard at least the RSE that they could into the actual the main code Well, it's a very good question and unfortunately I don't know the answer the question is that why these algorithms became a part of the core open SSL and ghost left aside So the Russian regulation in sphere of cryptography requires certification of implementations and it's much more simple to provide certified version crypto as separate engine then then publish it as a core it's impossible to publish certified version as a part of open source project so of course we can deal with code in the main code base replacing just replacing the code base by engine it's allowed by open SSL API but as the ghost algorithms were first set of third party algorithms appeared outside nobody wanted to build it in the main code base and as far as I know from China who became part of open SSL team or at least contributors and they support the algorithms at least part I made mistake about the status but I've got something like this I don't know yes I have a dream to become a part of open SSL team and support case maybe they will agree that ghost algorithm can become a part of open SSL main code base but well it works as part of engine and it's no problem Do you work in SSL 3? Lessonization has begun but not yet There is a draft describing new authenticated encryption mode which differs from Galois counter mode and CCM when it's finalized I think we will sooner or later provide the specification of using Russian ghost to TLS 1.3 What about Oh. It's a pain for OpenSSL There are no browsers except maybe links who use crypto from OpenSSL Most of them use crypto from NSS As far as I know There are browsers which support ghost but they are not widely used Первый — Ямпикс-браузер. Это форк хромиумов, я не ошибаюсь, и он имеет поддержку российских госталгаристов. The other one is a so-called Sputnik-браузер. It's developed in one of government agencies. It supports Ghost Algorithm 2, and, well, it has an Easter egg when you establish a connection, a secure connection using Ghosts. It shows not a lock, but a two-headed eagle indication that it's not just secure, it's Russian secure. It's offensive, it's offensive-efficient, but, well, if a Ямпикс-браузер is more or less in use, the Sputnik-браузер is almost not in use. Do you use Firefox? Yes, there is a commercial implementation of Firefox, implemented by a Russian company named Lissy. You can try to buy it and use it. Sorry? You said about the certificate of politics for one year. Yes, it's a very big problem, because, first of all, it's a political problem. From time to time there appears a project of standardizing, of creating a rather big Russian CE, and standardizing and making it conforming the CA-browser form requirements. And after that, the Ghost certificate can be added to various operation system bundles, and Ghost will start work out of books. But, unfortunately, now this project is not actively developed. You cannot care for Ghost, you cannot care for Ghost out of rush, except very limited cases. Some Russian sites require Ghost to be connected. And, well, I should mention about some projects of people who don't trust to MSA and decided that if they replace IS with Ghost, they get better security. Well, it all depends on the authorit models. Sorry, I don't... Yes, it's more or less used in Russia for, let's say, communication to government agencies, mostly, but there are a lot of projects of more spreading Ghost to... Если нет вопросов, я должен сказать, что национальная гипнотипография нет в России, а в России уже. Конечно, есть национальная гипнотипография в Японии, если я не ошибаюсь в Корее. И в некоторых репабликах, как в США, у Украины есть калина алгоритм, в Беларусе есть все алгоритмы. В США есть алгоритмы. Таким образом, проблема в использовании не очень worldwide standard crypto для больше людей, чем вы можете думать в первые часы. Спасибо большое!