Rethink Trust 2018: Michael Egorov, NuCypher KMS--Uncensorable Decentralized Encryption Service
So hi, everyone. And just to briefly describe what NuCypher is, we allow sharing data while it's encrypted. And this is apparently not as simple as it sounds. So to explain why it's needed, I will probably start with some use cases to demonstrate why it's needed. So imagine you have some encrypted files with private data, maybe medical data, and you want to share these files. Well, you uploaded these files to the cloud or maybe to some decentralized storage. And now you want to share this file with multiple recipients. How would you do that? Is it possible to do so while everything is end-to-end encrypted? So hiding the contents from the cloud storage
Even more challenging use case would be end-to-end encrypted group chats. So you probably know that Telegram group chats are not end-to-end encrypted. And that actually has a very specific reason. So imagine that if you made a group chat end-to-end encrypted, and you have, I don't know, let's say 10,000 people in your chat. So then how do you encrypt the message for every person? And at the same time, have it performant. So that's another challenge where it helps. Or imagine something like a video streaming platform, where you want to stream encrypted video only to those who pay for this and continue paying. And without the ability of your CDN, especially if it's a decentralized CDN, to basically steal the video and resell somewhere else
So these are kinds of the use cases possible. And an obvious way to solve this is to have it not end-to-end encrypted. Let's say you have TLS connections between users and the server. And let's say if you upload some files or put some messages in Telegram, the connection is TLS encrypted. But on the server, everything is plain text. And then the server encrypts everything for every user who has access to it. Well, it's a simple approach. That's how it works today
But obviously, it has some problems, like it's vulnerable to some state actors or hackers who can read your private data, or maybe who can apply censorship. And if instead of the cloud, which is somewhat private, you have a totally decentralized platform where you don't know who your data is with, it's actually even more tricky. So is it possible to have it not encrypted in the middle on the server? And basically, what we do is the answer to that. The answer is yes. And we achieve that by combining two things, the decentralization and proxy re-encryption. So what is proxy re-encryption? So you're probably familiar with public key encryption algorithms, where you basically have two functions, encrypt and decrypt. And you can encrypt to somebody's public key. Let's say Alice can encrypt for Bob's public key, and Bob can decrypt with his private key
So if you just use this and apply it to, for example, enter an encrypted group chat, Alice would have to encrypt for 10,000 Bobs, for example. And 10,000 encryptions, especially with public key encryption algorithms, is not necessarily a fast thing. So if you have sufficiently many users, you would have to send in every message to take, let's say, a minute or something. So that's not very scalable. So how do you make it better? And basically, in proxy re-encryption, apart from encryption and decryption function, there is also a re-encryption function. So let's say Alice uploads her encrypted messages somewhere, or encrypted files, encrypts for the public key, for the private key she knows. And later, Bob comes and asks Alice to grant access to him. So what Alice does, she takes Bob's public key
is public, so everybody can know it. Her private key, and calculates something called re-encryption key. She can give this re-encryption key to some untrusted proxy. We call this proxy Ursula. And this proxy can convert any message which Alice encrypted for her public key into message encrypted for Bob, without decrypting this message in the middle. So it's direct encrypted to encrypted transformation. So this kind of removes, at least this allows the proxy, the server, to never see the plain text data. And that's kind of the basis of what we do
So how do we apply that? We basically arrange everything to be interfaced as a key management system. So Alice encrypts file with a symmetric key, and symmetric key encrypted with a public key, with your public key. And then she uploads that to some kind of storage, whether it's a cloud storage or decentralized storage. And later, when she wants to grant access, she takes the public key, creates the re-encryption key, gives it to the proxy, or a network of proxies to be more correct. And then the recipient of the data can fetch the data, and then ask to re-encrypt the encrypted symmetric key, and then decrypt data with this symmetric key. So that's kind of the basis of how it works. We go a little bit beyond our simple one proxy model. We actually found how to make the proxy re-encryption split key, so that you split the trust to even transform the data between multiple proxies
So imagine you have, let's say, 20 proxies, and you can say, if at least 15 out of 20 proxies will re-encrypt the data, only then the data can be decrypted. And so we called this split key threshold proxy re-encryption scheme, Umbrel. And here are some properties of this re-encryption scheme. So Umbrel is actually derived from the Umbrel name is from Spanish word threshold. And this re-encryption scheme is, like, for encryption and decryption, it's basically similar to ECIS. We are doing that on the same curve as Bitcoin and Ethereum uses, SecP856K1. But apart from, like, ECIS and re-encryption for that, we also included the part where you can prove that the proxy indeed correctly re-encrypted the ciphertext instead of, let's say, returning random garbage. And that's actually a very important point
And let me probably explain why is this important. So if I go back to this slide, imagine that some proxy decided to impose censorship. So somebody requested re-encryption. And how can the proxy, let's say the proxy is owned by some malicious party, how can the proxy prevent Bob from decrypting this data? Well, first of all, the proxy can refuse to re-encrypt, right? Of course, if you have multiple proxies, this kind of scenario is kind of mitigated. Or the proxy can return some garbage in return and say, oh, I actually re-encrypted everything, and here is the data, but actually it's random numbers. So to prevent the scenario when the random numbers are returned, instead of real re-encryption, we have the proofs that re-encryption happened correctly. And if the proxy doesn't respond, we actually coordinate everything with blockchain. And every proxy interacts with a smart contract on Ethereum
So when proxy starts cheating, their network figures out that the proxy is not re-encrypting at all, or re-encrypting not correctly. And then the proxy, which is cheating, gets penalized. So if one of two proxies start cheating and not re-encrypting, they still cannot prevent Bob from decrypting the data. But at the same time, if they do that, they get penalized monetarily. So basically, to allow this to split the trust between the proxies properly and to be able to penalize them, we introduce a new Cypher token. So there are two major roles of a new Cypher token. One is to split the trust between the system. So imagine that we didn't have a token
Imagine that we just spin up our network of the proxies who do the re-encryptions and hold your grant permissions and revoke them. So imagine somebody wanted to attack the network. He would just spin up probably, let's say, millions of proxies. These proxies would accept most of their access policies. And then, since they control the same single-party controls most of the policies, they would be able to do censorship in the network. That's not what we want. So we want to make it hard to actually acquire a fraction of trust in the system. And that's why the trust in the system, or how many re-encryption keys the proxy can accept, is proportional to the number of coins their proxy locks
And if the proxy starts misbehaving deliberately, then part of these coins will get seized by the network. So the proxy is incentivized to behave correctly. And also, if the proxy behaves correctly, they get the fees from the users, as well as rewards from inflation of the token to incentivize the network early on. And, well, basically, their rewards are exponentially decreasing. And basically, we plan to have them halving in two years. But that's only if the proxies lock everything for a long time, like, let's say, a year or more. And that's important, because the time for which the proxies lock the tokens is the time, like, how long re-encryption policy can be, like, for how long can you grant that permission. If you lock your tokens for a shorter time, let's say a month, you will get significantly less rewards
And here I just have some, well, just derived some interesting formulas. What kind of rewards can proxies expect if they lock the tokens and are either when they, like, sell whatever they created, the inflation rewards they created immediately, or if they restake them to kind of have even more jobs and produce even more rewards. And apparently, these formulas appear to be pretty simple and beautiful. But we will publish the paper which describes them also. So anyway, and we already have some real world use cases. It's not the complete list. So there are actually some more companies coming in this. But the interesting thing is that most of the use cases so far were in medical data space
So there are a bunch of startups who want to give patients control over their data. They have data encrypted with their key. And then they can grant access to doctors. So that's pretty much, in a nutshell, what these companies do. And also we have companies who do decentralized data marketplaces, like Origin Protocol, for example, who also want to use NewSyPhi and proxy re-encryption. And actually, also a very good use case, I think, is in IoT space, when every device has its own key pair. And the devices can share data with analytics providers, for example, without giving access to everything you have to some large IoT company. So yeah, that was pretty much it
And please come to our website, newcifer.com. And you can read our white paper. And we have development of our network happening in NewSyPhi GitHub. And the split key proxy re-encryption algorithm is actually ready. And it's like finalizing the code audit right now. It's called PyUmbral. So you are free to come and use it. And the network itself is coming close to TestNet
But before it's reached that stage, you can go to NewCyPhi GitHub and play with MockNet, which is kind of, which gets you the feeling of how the network will work before the TestNet is rolled out. And yeah, you can also email to hello at newcifer.com. Thank you.