 Please welcome our next speaker, Bob Wall and Colt Fedrickson on implementing a library for pairing based transform cryptography. Thanks everyone. Thanks for sticking around till the bitter end. Almost the bitter end. I imagine some of you might have been out partying last night. I'll try not to assault anyone's hangover, but special warning. There is some math in here, so you know, consider yourself warned. So Colt and I both worked together at a company called Ironcore Labs. So we'll talk about this transform cryptography library that we've implemented and some of the background about it. So obviously we've known the answer to this question for quite a while before Facebook got facepalmed. But you can maybe tell by my gray hair that I've actually got to watch the World Wide Web get started. And it took off and then the cloud stuff started and it seemed like, hey, this might be really pretty cool. You know, especially people that were doing IT and setting up data centers. Like, wow, this might be great. And then we started getting some reach notifications. We heard about Yahoo. We heard about Anthem. We heard about the Office of Personnel Management or the OMB. We heard about Facebook. I imagine at least a few of you out there have gotten a breach notification from some company. So started to get a little bit iffy about the cloud. And even if you disregard the breaches and think about the weird things that happen when somebody sends you an email or you send somebody an email and then you go to some social media site or Google and look at the ads that get presented to you. It's like, it's a little creepy. I find it a little creepy anyway. So maybe the cloud has some downsides after all. So what can we do about that? What are some things that we can do to start fighting back against that? And one of the obvious answers is end-to-end encryption. So if I've got a device, a browser, a phone, a tablet, and I want to generate some data and I want to make it available to someone else. Well, if I can use public key cryptography, I get their public key, encrypt it on the device, send it off, and it stays encrypted until it gets to their device and they can decrypt it. So hopefully their private key that unlocks it stays on their device. And in between it doesn't matter. We don't have to trust anyone. We don't have to believe that somebody is going to be upstanding in the middle. So including cloud vendors, if we send that stuff through, we store it on Dropbox or Box, say it doesn't matter if they want to look at it or not, they're not going to be able to. And so we've seen a kind of a takeoff of end-to-end encryption apps. And there are a few of them that are more popular maybe. And you'll notice that most of these end-to-end encrypted applications now have something in common and that is that they're primarily designed for messaging and they're mostly designed for person-to-person channels. So they're not really designed for something where you might want to send something to a group of people and they're especially not designed for something where that group of people might be big and or very dynamic. The membership of the group changing a lot. And there's a reason for that because it's just not that easy. If you think about, say you're a masochist and you want to encrypt some data to a group of people and you want to use GPG to do it, you get all of those people's public keys. You stuff those all into the GPG command line and say, hey, encrypt this document, it does it. And every one of those people can use their private key to decrypt it. Okay, that's pretty good. And just kind of a side note here and this will be kind of important as we talk through this. So what we're talking about what GPG does and what everything that does public key crypto pretty much does is envelope encryption. So they don't actually use public key crypto to encrypt that whole document because it's slow and painful. They generate a random key, probably an AES key, they encrypt a document with that and then they take that random key and they encrypt it with each of those public keys and stuff that on the start of the document or at the end of the document or somewhere in that file. So I've got this file now. I've encrypted it to say three or four people. Everything's good. But now suppose I want to add another person. Well, that means that one of the people that can unlock the document needs to decrypt it, get those list of public keys that were already used, get the list of the extra public key that they want to add and re-encrypt the document and save it back out there. So that's not tremendously convenient and it's really not convenient if the group is changing fast. You wouldn't want to have to do that 20 times a day for sure. Removing the access is pretty much the same thing. You have to go get the document, you have to decrypt it, re-encrypt it with a list of keys that excludes the people you want to remove access from. So obviously that is not scalable. So we want to build a system that has what we call orthogonal access control and that just means that we would like users to decide which groups of people should be able to access their data without knowing who belongs to the group and then independently from that the administrators of those groups should be able to add or remove members without me knowing about it. So this is obviously not a new idea. I mean, UNIX groups are essentially this but we want something that relies on cryptographic access control instead of policy so it's harder to break it, harder to mess it up if somebody makes a programming error. It will matter a lot less because unless you have the keys, you can't unlock it. And we want a system where each change in group membership or an access grant or revocation is basically a very fast, a constant time operation that's independent of the number of users that we're managing or the number of documents, the number of files or the number of groups that we have. So what's a way to do that? There's a field of study in cryptography called proxy re-encryption. It's been around for around 20 years. It hasn't really gotten too widespread of an adoption but it provides a lot of these properties that we need to do this orthogonal access control. So most of the proxy re-encryption algorithms are based on public key cryptography and almost all of them are actually based on pairings which we'll talk about in a little more detail and that's where the math might start to sneak in. Proxy re-encryption was originally designed to allow someone who receives encrypted messages to delegate the ability to decrypt those messages to someone else without having to give them her private key. So you can imagine say we've got a mail server that's running with proxy re-encryption and we've got a group of people that are using it so Alice has a public-private key pair. She's set up on the mail server and she's getting encrypted emails and she decrypts them and then she's going to go on vacation. She wants Bob to take over for her while she's gone but she would really rather not give Bob her public key because he's kind of a doofus and he will probably lose it. So with proxy re-encryption she says okay I'm going to delegate to Bob she calculates this re-encryption token and sends it to the proxy server, the email server and then when the email server sees emails coming in encrypted to Alice it can apply that transform key and do a transformation that makes that data encrypted to Bob without decrypting it. The mail server never saw the plain text it only had this token that allowed it to transform from encrypted to Alice to encrypted to Bob. So that's what proxy re-encryption was designed to do. Proxy re-encryption algorithms usually have five primitives key generation and again almost everyone I've seen is just straight up elliptic curve key generation. Transform key generation which is a little more involved encryption and transformation or re-encryption. We've taken a calling this transform encryption and calling this step transformation instead of re-encryption because typically when I think of re-encryption I think of what I talked about with GPG it's like oh I have to go take the file decrypt it get a new key and encrypt it with a new key and this is not that so we call it transformation instead and then the decryption operation. So transform key generation with proxy re-encryption takes the private key of the person that wants to delegate the access the public key of the person that they want to delegate the access to and run some math and it comes out with this transform key. So this transform key again doesn't allow anyone to decrypt any data it can only be used to take data that's encrypted to the delegator and re-encrypt it or transform it so it's encrypted to the delegated. And then you know once you get that done you can send it to a proxy that's going to keep track of it and it's going to apply it as necessary and the fortunate thing is because it can't decrypt anything you don't really have to trust the proxy when you send that key to it you can't use it to do anything except what you basically told it it could do which is transform messages that are encrypted to you so they're encrypted to someone else and the nice thing is that you are the only one who can do that because it takes your private key to do that so as long as you're not Bob who like leaves his private key on the desk you should be good. So if you want to delegate access it's as simple as taking a file that's encrypted to the delegator applying the key and running the transformation algorithm and sending the transformed file or data to the new recipient they take their private key and they decrypt it pretty much the same way they would have decrypted something that was encrypted directly to them. So how can we use this to build this orthogonal access control system? We just use groups. We create a group and we encrypt documents to the group and then independently of that operation the person who's kind of an administrator or owner of the group can create transform keys from the group to each of the users that's going to be a member once they add a member to the group immediately that member can decrypt anything that's been encrypted to the group in the past anything that will be encrypted to the group in the future and at some point removed from the group that also immediately revokes access and the nice thing is that both of those operations don't require you to go and find all of the documents that were encrypted to the group and mess with them you don't ever have to touch any of the documents you just do these transform keys so creating a group is simple it's just you create a public-private key pair for the group what we do usually is take the group's private key and we encrypt it to the users that created it and that makes that person essentially an administrator for the group so an administrator is just someone who can access the private key of the group which means they can add new people to the group when they want to again adding a member to the group is as simple as computing that transform key and that's why the administrator needs access to the private key granting access if you've got a file and you want to let a group access that file you just encrypt it to that group's public key very simple if a group member wants access they request a file that's been encrypted to the group they give that to this proxy server that's got the transform key it applies the transform to make the file so that it's encrypted to them sends that transform file back and then I've got a private key on my device that unlocks the data and recovers the plain text removing a member from a group is as simple as just forgetting the transform key you just throw it away as soon as it's gone that user can no longer decrypt anything that's encrypted to the group so you know now we've got all of the pieces and parts that we need to put together an orthogonal access control system and using a proxy re-encryption algorithm we notice that really users don't use one device I don't always use the same browser on my laptop to access things I don't always use my cell phone to access things so we can make this better if instead of if we wanted to do that we would basically have to do the thing that you do a lot of times now it's like okay I've got my private key and I want to use three or four different devices I have to figure out a way to get my private key onto all of those devices which is you know you can do that but that's not the greatest experience so if we basically add another level here of delegation we can treat a user as a group of devices and just do another transform from a user to device that means every device gets their own private key you don't have to share them you don't have to copy them around if somebody drops their phone in the toilet they can just basically revoke access to that phone and they don't have to worry about if somebody had somehow hacked their phone and gotten their private key for the phone as soon as that transform key is gone that phone can access their data you know maybe you left it on the conveyor in the airport so the private keys for the devices are always on the device and it gives you this nice revocation property but in order to do this the proxy re-encryption algorithm needs to have a special property that's typically referred to as multi-use or multi-hop so we already talked about if you had a data that's encrypted to a user and there's a transform key to another user you can transform the document and then the other user can unlock it but with multi-hop proxy re-encryption you can take that transformed document and you can apply a second transform to it maybe to another user Carol and produce this doubly transformed document send that to Carol and she takes her private key in the decrypt algorithm and gets the plain text back so this multi-hop proxy re-encryption allows you to build this hierarchical system and in fact you could build a hierarchy deeper if you wanted you could have groups of groups so adding a device to a user is the same as adding a user to a group you just create a transform key so if I'm logged into one of my devices and I want to access a document the proxy, I say here I've got this document and I want to unlock it and the proxy figures out the best way to get the transformation from something that's that documents encrypted to to the device that I'm using to request it so that might be because the document was actually shared with me my user directly and then there's one transform between me and my device and that will work maybe it was shared with a group that I belong to so if there's a path from a group to me to my device the proxy can take those two transforms and apply them in a chain transform it twice and return it to me so I can decrypt it so we now have scalable end-to-end encryption it can handle arbitrarily large groups of users and it can handle dynamic groups of users we can grant and revoke access to documents and to groups in constant time it doesn't matter how many documents doesn't matter how many groups doesn't matter how many users and we got rid of the need to copy private keys around if we're trying to manage multiple devices so just one place that this could be useful is say you want to be able to protect someone's PII personally identifiable information and I imagine there are more than a few of you out here who have been thinking about this a little bit in the last six months or so in the GDPR framework so if you could take a user's private data and just encrypt it to that user and then say that user is going to decide hey I'm going to provide consent for this company to use my private data it's as simple as creating a transform if the company's got a public key and the company is considered to be one of these groups I create a transform key between me and that group that will allow that group to read my data and then maybe a couple months down the road or a year down the road I decide I don't want that company to continue to have access to my data I want to invoke my right to be forgotten so I just tell the proxy service that's holding these transform keys hey throw that one away and that means that that company or people that belong to that company no longer can access that if they haven't already accessed it so that's an example of what we can do with this so we have implemented the primitives in the Scala library we scala JS to generate a client-side JavaScript library it's open source we actually built a JavaScript SDK around it that talks to a service that is the public key repository and then transform proxy we've got it out there that part is an open source but we let people do free sign-ups if you wanted to play around with it the library is open source but it doesn't have some of the things around it to make it easy to manage the keys and stuff so now I wanted to talk a little bit about like under the hood some of the math stuff that makes this work I said is pairing based cryptography and pairings are built on top of elliptic curves so elliptic curves crypto is pretty standard but pairings are less standard although I did I think I heard two or three different talks in here this weekend that we're talking about pairings a little bit so the basic operation that pairing based crypto is based on is called a bilinear pairing or sometimes called a bilinear mapping mapping that pairing is simply a function that takes an element from some group and an element from some other group and combines them together and produces an element in yet another group so the first group spoiler alert might be the set of points on an elliptic curve over a prime field so in order for this thing to be a bilinear pairing it needs to satisfy some constraints it needs to provide some properties I won't read these to you but that last one in particular is important because it allows you to basically swap scalar multiples of points and we'll see why that's useful in a second so how we use pairings that first group that we talk about is exactly the set of points on an elliptic curve over a prime field the second group is related to that it's the same elliptic curve changed a little bit it's called the twisted curve and it's defined over a set of points in the second degree extension of that field and so the math for that gets a little deeper and I won't go into that but when you do the pairing you produce values that are in another group this g sub t group and that group is not a set of points it's actually a set of values that are the r throats of unity and those values are all contained in the degree 12 extension of that prime field so these things are you know basically numbers that consist of 12 different values that are between 0 and prime minus 1 so it's a big number that the pairing produces all of these groups have the same number of elements in the group they all have the same order so the reason pairings work for crypto and there might be other ways to use them but the way that we use them and the way most of the proxy encryption stuff does is it allows you like I said it allows you to swap scalar multiples so if you think of a public key it's just some generator point in your group your elliptic curve group times some randomly chosen private key or secret key right so that's just a scalar multiple of some point that you know so if Alice and Bob have key pairs that are computed that way they both picked a random secret key they compute a public key they send that out there to a key server Alice can encrypt a message to Bob by using a pairing Bob's public key and pairs it with her secret key times this generator point that's predefined in that second group of elements for the pairing and then she takes that pairing value and multiplies it by the message and that gets an encrypted message so Bob can recover that by basically taking Alice's public key pairing it with the negation of his secret key times that second point G2 I won't go into this but basically you can prove that this works by just doing simple math and just simple arithmetic rewrites it's like well okay if I rewrite the public key as the secret key times the generator point and then I remember that because of bilinearity I can swap these two things and then if I get down to the bottom I know the fact that if I pair something times zero it basically returns one that shows you that I do in fact get out my original message when I decrypt it so this is how pairings are used to make encryption work so I'm going to make one more side note and then I'll turn it over to Colt to talk about the library and some cooler little less theoretical ways to use it but a note on the security of this stuff the security of pairing based cryptography relies on two different hard problems the first is the standard elliptic curve Diffy-Hellman problem that protects all elliptic curve crypto and that problem is what keeps you from being able to recover a secret key even though you know the public key and you know the generator point so that's a hard problem that protects the elliptic curve part of this the other hard problem is the straight discrete log problem and that's what protects the pairing part of that because remember the pairing produces a value that's not an elliptic curve group but a field, a big field so it's the just straight discrete log problem that protects that part of the work recent advances in the use of number fields have improved the ability to solve the discrete log problem it's still hard but it's not as hard as we thought it was a while ago so in the past we thought the kind of conventional wisdom was a 256 bit private key the elliptic curve discrete log problem would provide you a roughly 128 bits of security and if you're doing this the discrete log problem in the 12th degree extension of that field that would also provide you roughly 128 bits of security against the straight discrete log problem they've been working on this number field sieve and that improves the ability to solve the discrete log problem and some researchers have been grinding away on this and concluded that the start of this year and the end of last year that if you have a degree 12 extension of a 256 bit prime that really only provides you with right around 100 bits of security instead of 128 so if you want to go and tell everybody hey my crypto is 128 bits secure some people kind of expect that you actually need more bits in your prime number in your field and so getting back up to 128 bit equivalent security you actually need a prime that's 400 these are all estimates and the computations are really complicated and involved and you kind of have to do it for each different case but the estimates are that you would have to have at least 461 bits in your prime to get back to 128 bit security for the discrete log problem so we've been playing around with this a little bit and you know it's probably something that everyone should be aware of in the future that you're probably going to have to start bumping up the size of the prime pretty soon because of these advances so now I want to turn it over to Colton he'll kind of talk about the library sure so firstly like all this code I'm just going to show basically code snippets from the re-crypt library re-crypt I mean the library itself doesn't do all like the story of transform keys and all that stuff so everything on the slide is like well I'm just doing this in like sequence and code but you know some of it would be done by servers some of it would be done by devices so I'll just kind of talk to that as I go so obviously there should be private keys everywhere and pretend that they're on different devices for now so who here has used GPG to try to keep secrets encrypted to different people alright almost everybody you're like this is a very common thing we do IT organizations use complicated expensive key management systems to like have groups and try to like make this slightly less painful but it's really pain in the ass so we have Bob he's in charge and I'm not just saying that because he's sitting behind me and he just hit me on the head but Bob's in charge and he's the IT manager so he's his job is to keep all these secrets encrypted to his IT organization some keys he wants encrypted to the whole organization some keys he wants subgroups whatever he wants so these are one of his groups that he's working with sadly for him the turnover in IT organization is high and he's every day he's re-encrypting things or removing people he's doing all this all this work to try to just just keep the same secrets encrypted to his organization to take up a severe amount of his time so he's using GPG to do that right now so every time you add somebody like Charlie here he has to go through and do what Bob talked about where you decrypt it you re-encrypt it to everybody and you send it back out there okay so Alice brings Alice on board the same thing so hiring is painful unfortunately Alice is also a quitter so she quit and now he has a problem again he has to go through and do it again so both hiring and people quitting it's a major ordeal so we can solve that so let's talk about I'm just gonna show some of the code from re-crypt here this is Scala code so if you've never seen Scala before or you haven't read it types on the right side of colons and values are on the left side so we've got a class API that takes the random byte vector and the thing it does is signing so it's a little weird we had to do this because we wanted to cross compile the JavaScript has anybody tried to do cryptography in JavaScript it's not great so yeah the problem with cryptography in JavaScript is how do you get random numbers cryptographically secure random numbers well that depends on the platform you're on or you're in the browser or you're on node so we wanted to allow this to be more flexible so this thing they pass in this I.O you can just think of it as a function that every time you invoke it it basically could return you a different value so basically anywhere you see I.O you can just replace it with a function in your brain we won't get into I.O's today because that's not the kind of talk we're in so every time you call that you're going to get a different set of cryptographically secure random values and the signing is just a pair of functions sign and verify and we did that with ed25519 because it's fast it's known to be secure and we didn't want to use the same set of keys for both encryption and and signing because that's generally considered not the best practice so we take these things because of platform nonsense so generate key pair it's a pretty simple thing we basically just take the random bytes and we map them over multiple at times generator point to create a public key so that's pretty simple and that parentheses syntax is just a two tuple so generate plain text so when you are doing pairings like Bob was talking about you have to have these elements that are in different groups and they have to be members of the groups they have to be all sorts of unity and all kinds of other math jargon otherwise it doesn't work so we instead of having to push that jargon onto the user of the library we just said well just write a function that generates you a plain text it returns this type that is it says it's a plain text so it is and just trust me that way you don't have to worry about how to generate it so it's using that random byte vector under the hood as well so generate transform key basically this is the thing that delegates so this is the function that delegates from one private key to a public key transform that's the thing that actually it takes a transform key and does that transformation for you so this is the thing that like a server would do or somebody whoever is the proxy in all Bob's terminology the person that has access to these transform keys and the public keys and all that stuff that would be where this runs encrypt pretty straightforward encrypting a plain text to a public key and decrypt so it either returns an error message or the plain text so let's go through like a little sample here so we're basically going to go through the sample that we were talking about earlier we're talking about Charlie and Bob and Alice in this IT type organization so this is basically just generating two different key pairs over here so Bob's key pair and the IT groups key pair the reason I voted out at all because key pair generation is boring is because it's it's really important in the scheme to remember that groups and users are really the same so users can be treated as groups groups can be treated as sub groups like so public private keys and especially with our system you can use these things for many purposes and you can delegate to people you can delegate to groups you can there's all kinds of fancy stuff you can do so don't get stuck in your brain about like oh well this is a user key because you can treat it as a group okay so encrypting a value to IT group I mean we our goal with this library is to make the public API as simple as possible anybody who's used OpenSSL or any other cryptographic library is god awful to try to figure out what's going on you're passing in mutable mutable values that they're going to fill out and pass back like it's just it's just bad we wanted to read exactly like the pseudocode algorithm should read so here we just generate a plain text we encrypt that plain text and yield the encrypted value so it reads like pseudocode and we're encrypting to the public key and so we'll know about signing keys I kind of pointed out earlier but because we did the signing keys separate from keys we use ED25519 that means we pass in these signing keys to detect if somebody's screwed with the encrypted values so it makes the API a little messier but I think it's still pretty straightforward so another thing to note here is that this encrypted value never has to change ever you can put it on the blockchain you can put it in a database you can put it in Kafka, immutable key value stores, whatever you want to do you can do that and you never ever ever have to change the encrypted value so no matter who you who you want to share with or add to the group later with you never have to change that okay so we hire Charlie so we generate Charlie's keeper so that would happen on her device so that piece would happen on her device and then Bob takes her public key and he just generates a transform key from the IT group private key to Charlie's public key and that's it so he generates that transform key and he sends it off to the public key repository that's holding on to all this information so now we have basically this is how Charlie gets added to the group she's now in the group so hiring again just to show that it's the same no matter what Alice is the same thing she generates key pairs she sends it off so this is what you would call adding her to the group it also doesn't matter how many documents are shared with the group this operation is constant time just the one thing doesn't matter how many millions of AWS secrets you have encrypted but what if Alice quits sorry what if Alice wants to decrypt this sorry so Alice comes in and basically she's the transform value so this transform function that's happening at the top that would happen on the proxy server so we'll just pretend that that has happened there and then the transform to data would be sent back to Alice on her request so the important thing here is that the transform data and the original encrypted data have the same shape that's what Bob was talking about when he was talking about multi hop so if you wanted to transform that data again you could take that transform data and transform it again to give it access to a device or give access to a subgroup or whatever so it's important when you look at the like I put all the types on the left side there but that encrypted value is the same thing we got out of the encrypted function so it could be encrypted or it could be already one step transformed and you could do it over and over again so if Alice quits we don't need to do anything special all we need to do is forget her transform key and we just walk away now that's what a lot of people are starting to call this like crypto shredding or cryptography or racing things all these terminology just means well they can't decrypt it anymore so I don't know why this is like a new thing that we're doing as an industry but I guess we are so as you can see like this api is super approachable there's nothing crazy here so if you're all interested in this we have a ton of property based tests in our core api tests on the get hub repo and it goes through like two and three and four level re-encryption steps with different devices and subgroups and all kinds of augmentations of keys and there's some really neat stuff that you can do there if you have any questions at all like feel free to open an issue and say like it's not clear what's happening in this test case or what about this other thing that I'd like to do I'm wide open to like answering any questions on that but I think the property based tests give a pretty good overview of that so what else like Bob mentioned quite a few of these and again multi hop proxy re-encryption is super super super cool because you can treat users as groups and groups as subgroups and there's just really no limit to the things you could do with that kind of stuff every hop makes things slower so that is one thing that happens when you do all these transformations obviously you have to unroll them like math isn't free so that's a struggle there but there's some pretty cool stuff you could do and he mentioned the GDPR which is a big deal so the right to forget and being able to say oh well we crypto shredded this data and we can't unlock it anymore so we forgot who you are being able to do that in a constant time instead of sending your IT guy up to just search through databases for three days like that's a game changer in my opinion key rotation could also be encoded with an extra hop so if you wanted to say like oh I want to get a new key you could make your old key just delegate to your new key and you could not have to re-encrypt all your old data there's some caveats there but we'll leave it at that so it is still out there on github so we just open sourced it pretty recently it's only on the jvm and javascript so it's pretty limiting as far as platforms are concerned but we have some other stuff coming that's pretty exciting but we're not quite ready to talk about it yet it's also not that fast yet we have a benchmarks thing in the repo so feel free to clone it and see the benchmarks but it certainly could use some work there while working on it and are open to any suggestions or anything like that and really managing the groups, managing the public keys, managing the transform keys and identities like that's where the struggle comes in here I showed the code and the code is super simple but like all the identity management is really the harder part of this in terms of getting it right so with that questions actually I have two questions the first one is about the transform key storage as far as I can tell mathematically speaking possession of the transform key and the destination private key is equivalent to holding the original private key because once you have them both you can just transform and decrypt so you clearly need to store these transform keys in some way that's secure you don't want somebody who has a transform key issued breaks into the proxy server takes the transform key and then you can never revoke them so I mean is there any plan to implement this on secure hardware or secure elements, things like that so that a proxy can securely store these transform keys so yeah if you have the private key of the person that has been transformed to and you have the transform key you're right like that's equivalent to having like access to all the data is only is only stored in the proxy but you're right you could break in there we don't have plans to do anything special there at least not in the very near future it is basically the compromising of multiple systems including their device and that could actually be revoked we can use some key augmentation tricks to make sure that values that are encrypted to a certain user can't be unlocked by their private key and can only be by devices and that's something I didn't get into here but I think I guess the short answer to your question is no and yeah that's a problem but not as big a problem as the other question I had was so the issuance of transform keys requires the private key is it possible to use the same trick to delegate that authority so I could use my private key to generate a transform key that I then transform into another transform key I'm sorry if your head explodes I'd have to think about that a little more just thinking of a group of people that are the admins so that might be possible but I think a lot easier approach than that and one that we haven't implemented but we're going to is basically doing a key splitting idea so if I've got a group of admins that have access to the private key for a group and it's an important group like the IT group for my organization I take that private key and I basically split it M ways I've got M employees and then I require some subgroup of them that's more than one have to work together to put the key back together before they can use it I think that's accomplishes maybe not exactly the same things but close to the same things it's a significantly easier thing to think about in your head thank you for the amazing tool and talk I have some questions about the performance of this proxy server as it is applying these transform keys because it can't give out the transform key so when doing this transform that would basically that's a computationally expensive operation correct? would there potentially be any downsides to taking a play out of GNU PG this book the initial encryption with a symmetric key that is very fast and then only doing a transform on the encryption of that symmetric key that's what we're doing this is envelope encryption so the only thing we're encrypting is the AES key the transform is expensive so the performance of the libraries is not what we want it to be but we're focused on making it faster and working on that there's another thing that the proxy server can actually cache those transform values if it wants to because every time it asks for one well not quite the same answer but almost the same answer every time so you could actually cache those if you were worried about performance you could cache the transform value for some period of time if somebody was just asking over and over and over again for that same value that was my next question, thank you any other questions? thank you