J3 SAY 07 MacLane Wilkinson, decentralized Key Management

hi everyone my name is mcclain Wilkinson I am one of the cofounders of a new cipher new cipher is a data privacy layer for blockchain and the apps we give developers a way to store share and manage private data on public watch chains are more specifically file systems like IP FS or swarm so for example let's say you're building a healthcare application you want to store a patient medical records on on swarm or ipfs we give you a way to have those be private confidential and encrypted but importantly still have those encrypted records be shareable with a valid recipient say a doctor or a hospital for example so I'll go into a little bit about the architecture and how we built this in a second but just to start I'll give you a few examples of the types of things you could potentially use a new cipher to build a very obvious one would be a sort of decentralized and end encrypted shareable Dropbox so you have files whether they're medical records or photos you're encrypting them client-side uploading them to the storage layer at that point you're the only one obviously you can access these files with your own private key but using new cipher you're able to easily delegate access to those files to your family to your medical records provider some third party service provider without having to share your encryption key and without ever exposing the files in plaintext to the storage layer another very interesting use case would be being able to create a very scalable and performant end and encrypted group chats this is actually a challenging problem even in a centralized context much less you know the blockchain space the reason being it's it's very you know performance hungry to encrypt a message for each participant in a channel when someone new joins a channel you have to encrypt the entire history for them every message that someone sends these get encrypted and times for each participant the channel so this is one of the main reasons why I like these giant 10,000 person telegram group chats or not encrypted it's all in plain text is because it's extremely expensive to to do that encryption folks like signal will use something called double rachet encryption to try to do this but at large group size still gets a little bit clunky and messages will appear out of order and things like that whereas with the new cipher in our underlying proxy encryption technology you can really easily do this just delegate access to as many recipients or participants in a chat as you like and then easily revoke access say let's see if you let's boot someone for example you could also use nap you could also use noose I prefer to create conditional decryption so for example creating data changes or data marketplaces in this case creating a decentralized Netflix where you're streaming encrypted video and you're only giving people access and exchange for payments so by default it's encrypted for the data owner but you can embed in a smart contract some condition that says allow the recipient to decrypt if they pay five ten or however many eath to your address and of course how we solve this sort of data integrity or data confidentiality confidentiality problem and the centralized world with things like TLS or encryption in transit but fundamentally here you're still trusting the service provider so if you're using Dropbox or Gmail I probably don't need to tell any of you guys this is why we're kind of in the space but you're fundamentally trusting that provider and maybe it's fine to trust Dropbox to tow your servers to store your files or to trust Gmail to store your emails perhaps you don't want to trust some of the people that are trying to hack into them and then of course if they extend this to to our space and into centralized context having everything exposed plaintext server-side is a complete non-starter these are not nodes that are sitting in Facebook's data center in Dropbox is data center these are nodes that we have no idea who's operating these nodes they could be an Iran or Russia or wherever what we've done proxy encryption a new cipher to solve this is combine two core technologies one is something called proxy Rhian Krypton and the other of course is decentralization using the etherium blockchain and we basically created a decentralized key management service and I'll sort of build up to how we've constructed this system but piece by piece proc Syrian Krypton is a more scalable form of a public key encryption that allows you to delegate access and revoke access to arbitrarily as many recipients as you like so if you think of traditional public-key encryption as being very good for one-to-one communication so let's say I have some secret message I need to share that message with one of you in the audience I can just encrypt with your public key send it across the network you decrypt with your private key it works perfectly well but let's say now I need to share that message with dozens or hundreds of people everyone in this room everyone in this conference it just starts to scale very poorly I have to encrypt n times for each person send it across the network a whole bunch whereas with proxy encryption I can just encrypt that data one time under my key and then use something called a rien shin key to transform a rekey or re encrypt that data for a recipient so you could imagine just building a traditional centralized key management service using proxy encryption is sort of a primitive where you have some original data owner an intended recipient a storage layer and then some proxy that's going to perform this Rhian krypton so the data owner well of course just encrypt their data client-side upload it to the storage layer let's say at some point in the future they need to grant access to the recipients the data owner can create something called a rien krypton key and this rien Shin Ki is consists of two inputs one is the data owners original private key and the second is the intended recipients public key and creating this read encryption key is a one-way function so you can't you can't extract the private key back out the data owner will give this rien krypton key to some semi trusted or untrusted proxy and then the proxy can use that re-encrypted key to re-encrypt a rekey or transform the data so that it's now encrypted for the recipients at which point the recipient could just use their own private key to decrypt the data and during this entire process you are never exposing the data to the to the proxy you're never exposing the data to the storage layer just the original data owner and the recipient we've taken this kind of a step further for the purposes of blockchain and the apps and created a threshold split key encryption algorithm so instead of one rien Shin key we split that rien krypton key up into a bunch of shares issue those out to the new cypher network and the new cypher network consists of many untrusted proxies which perform this rien Krypton on the data owners behalf and the nice thing about this is you're not having to trust someone single proxy to do this rien Krypton so for proxy goes offline you still have enough - you still have a quorum of proxies to re-encrypt if anyone or however many proxies is malicious it's not a problem because you later will get re encrypted and this threshold is tunable so you can set it to 30 or 50 shares or nodes must come together in order for me encrypt 305 it really depends on your use case and your threat model and the nice thing about this is it's an entirely trust less decentralized nonsense herbal key management service so you're not having to trust Amazon Cloud HSM or Azure key vault or hashing Court vault or even even new cipher for this a little bit more on this split key encryption algorithm that we've created we call it umbral which is Spanish for threshold it was jointly created by our company as well as a proxy encryption researcher at the university of málaga in different proxy encryption algorithms have different characteristics or properties so ours happens to be unidirectional which means you can really so you can grant someone access but it's not reversible so that person can't for example write back to the data if we were to have bi-directional you're potentially opening the system up to certain vulnerabilities it's also a single hop which means I can delegate access to you but you can't then you know for that along to someone else or we encrypted again and finally it's non interactive which means the two keys that are involved are the data owners private key and the recipients public key there are interactive versions which require two private keys but in our case it's just a private a public key we basically use key encapsulation and data encapsulation so we're basically encrypting the bulk of the data with a symmetric key by default it's cha-cha xx but if you have some specific like regulatory requirements for example if your if your need to be HIPAA compliant you can easily swap this out for AES and then we encrypt that symmetric key with our key encapsulation and where we do the actual splitting Andrey encryption piece the system uses to ensure nodes are basically re-encrypt incorrectly and behave incorrectly we can do verification of that through non-interactive as your knowledge proofs this piece is still kind of in development so it's not you know fully built out yet but you can just explore the cryptography library it's on our github or get PI humble we've also got Doc's up as well finally we have an IRC 20 token and the purpose of that is if you want to be a node in the new cypher network and basically provide rien Krypton work to the network into users you have to stake that token as a kind of collateral or security deposit so we use this for a couple things one to allocate work so if you're staking 10% of the tokens you're getting 10% of the rien Krypton keys you're providing 10% of the work you're getting 10 percent of the remaining rewards and we also use it as an economic incentive to ensure that nodes are behaving correctly so if you are a node and you're going offline for extended periods of time or instead of properly Rhian crypting you're just spinning back garbage someone can challenge you provide a proof in your stake will get slashed and if you are running a no the incentive for that is sort of twofold one users will pay to use the network in eath so you'll have that income stream and then also you'll participate in our inflation schedule depending on on how long proportional to the amount that you've staked basically a few examples of some of the early users of the new cipher one vertical frost is decentralized data changes in data marketplaces so projects like datum which are aggregating a bunch of different kinds of data could be browsing history social media data genomics data they're encrypting it putting on IP FS or swarm or some decentralized file system and then conditionally decrypting it in exchange for payment so selling you know giving regular people away to monetize their browsing history by oxygen it off to advertisers selling genomics data to researchers for example several the decentralized databases they've been cropping up like blues L or fluence are using us as the access control layer I said control who can and can't query their database and then another very popular use case is a lot of these health care portable medical records projects like Medi block or medicine or wholesome to i/o which are giving users control over their medical records and then the ability to easily move between providers if you'd like to learn more obviously we have all of our development open on github we also do all of our development discussions on discord so we're happy to have you join that we have a more technical and scientific white paper available on archive or on our website that goes into obviously much more detail than I can cover the relatively short amount of time we've got here obviously very interested in speaking to any of you if you're interested in potentially doing peer review or contributing as well as if you have a project that contentious or has a data privacy data company out confidentiality problem hopefully we could potentially solve that for you in my email is just McClane in decipher comm thanks very much and happy to answer any questions if there are any thanks for the talk I was really interesting just curious if you had explored ways in which you can use your network to help people kind of regain access to funds one of the biggest problems we have is people losing access to their keys and it strikes me that you're building stuff that could really help with that it's really interesting yeah there I could imagine using proxy encryption is kind of a primitive to construct some sort of more sophisticated passphrase recovery system or something like that we have a few projects that I think looking at early stages kind of exploring that there's also this interesting property that we're not actively working on at the moment but this for the inverse of proxy encryption which is proxy resigning so you can delegate authority to assign potentially a transaction or something on your behalf to some third party so you can imagine potentially it's like custodial service being built using that or people delegate access temporarily to an exchange in order to transact without having to give the master to that exchange for example another question you talked about that you can share access you can give access to people can you revoke it to from a couple of them I have to do you have to we work from everybody yep so one rien krypton key targets some specific recipient so you don't create a rien krypton key in that rien krypton key can rien crypt for everyone in this room I would create a rien krypton key that targets you know one person in this room and then if I needed to give more people access I create additional rien krypton keys so I can basically issue a revocation command of any cipher Network and say hey tell the nodes that have a key share of that to delete their share so you can revoke to a certain extent once the recipient has like downloaded the data decrypt it has it in plaintext we don't solve that problem but if they haven't done that yet you can you can revoke hello thank you for your attack I have a question about delegation access for for other for other people for example when you have data storage on ipfs or on swarm why not well why not to use just like the few Hellman like key exchange and then have like some session key and then they they have access to that key and then at some point to advocate the key yeah why doing this and also a question well if they have access at some point well even if you replicate the access later on since they they have the history they they could download it so why by advocating it they only don't have access to new data but the one that was already downloaded it's even if you replicate access it's meaningless yep so if to take the last part first if the recipient has downloaded the data decrypted it and saved it we we don't that's not part of the piece we're solving we're just the initial access control piece so you can revoke if they haven't already access the data or if they have access to data but haven't saved it but if they saved it obviously that's sort of out of our control I was playing texting it at that point and then the first piece the advantages of this system or there's a couple things one once you've delegated access to someone the data owner could just go offline so it's not requiring them to be online to sort of establish it establish a session and secondly you can use smart contracts to embed conditions into sort of the access so you can say only grant access for this person if they pay 5/8 to my address or only give them access between x and y time or potentially you know if we have working Oracle's at some point you could make it contingent on unreal world world events thank you [Applause]