 So, hi. I'm Leah Kisner, and I'm here to talk about building privacy and respect into products and systems and how cryptography factors into that. But first, a little bit of context. So my PhD is in crypto, but in the 11 years that I've spent at Google, I've gotten to touch almost everything that Google does in some way. Once time, I managed and maintained the RPC service that all of our bits of production used to talk to all of the other bits of production. I've designed and in some cases built many of the privacy and security systems that sit on top of that. And I've been doing a lot of security and privacy review over those 11 years, so I've gotten to see a lot more things than I could have possibly designed myself. These days, I'm the lead engineer for privacy at Google, and that means I get to put my fingers in everything from some of the trickiest product privacy problems to how we build privacy and respect into our products and infrastructure to thinking about what we even mean by privacy and what we even mean by respect. And along the way, I built a team to help us achieve this, and we do things like working with product teams like Cloud and X and Gmail and Maps to help them understand respect and how they can build it into their systems. And we build privacy products of our own. So, for example, if you go to Google Takeout, you can download the information from your account. Or if you go to the privacy and security checkup, you can see and change your security settings. We also build privacy infrastructure like we have infrastructure to help with data deletion because it turns out that deleting data from a globally distributed system reliably and knowing that you've done that turns out to be pretty hard. And we have anonymization infrastructure because just like I do not want people rolling their own crypto, I do not want them rolling their own anonymization. So my goal in this talk is to talk about things that I didn't learn at crypto, but things that have been really helpful to me in getting respect and getting cryptography into products and systems and helping people in the real world. So I want to start off with some of the philosophy behind this stuff. There are three things I really care deeply about here. Number one, we need to build products that respect users. We need to understand what that means, and then we need to make it easy. So let's take these in turn. Building products that respect users. That means we need to build things that respect users and make them feel safe. And I realize that this is sometimes a slightly controversial statement, but feelings matter. So consider an election. You can have all of the technical aspects of an election locked down. You can have privacy. You can have confidentiality. You can have integrity. You can have all of this done. But if the voters don't believe that the election is free and fair, then they are not going to act like the election is free and fair. And your election effectively won't be free and fair. Feelings really matter. We have to treat this as a full stack problem, starting with humans and the societies they can create and treating it all the way down to the hardware. And you can't evaluate the success of any one component in a vacuum. You have to look at how it fits into the global system and you have to evaluate it in the global system, including all of the humans. That means we need to build products that respect the diversity of users. People are different. People have different living situations. So, for example, people who live in India or Indonesia or Brazil have very high cost, low bandwidth network connections. Or they might not be connected all the time. They might just be connected when they happen to be at their employer's house. And this really affects how they interact with technology. If you design something that assumes that people are online all the time, it's just not going to work in a large segment of the world. People have different social norms. For example, people in different areas of the world have very different expectations. Germans are known for being very careful and very caring about their privacy. But what might be a little less well known is something we found out because we do a lot of this user research, is that people in India also care very deeply about their privacy. But what's a little different is they also tend to believe and be much more optimistic about the ability of technology to help them achieve those goals. And people speak about privacy and respect differently. For example, a colleague of mine told me that in his native language of St. Helise, there's no one word for privacy. Among other things, this means that it's been really a lot more complicated for him to explain to his parents what his job is. Sometimes the social norms of people don't match those who they live alongside or people who have power over them. Historically, the LGBT plus community and religious minorities, among others, have had real problems with this. And you need to consider this when you're building technology. People have different living situations. A disturbingly large number of people are subject to intimate partner abuse at some point in their lives. People may live with roommates who are untrustworthy. And people in this room, my guess is you're going to think of this as a college situation, as a schooling situation. But this is true for many people throughout their lives. Or when they go to work, their mobile devices may be confiscated. In the US, this is most often because somebody's engaged in low wage hourly work, but not exclusively. So building respectful products means understanding that your users have different needs and different desires and building for that. So I want to go into a little more depth on one class of problems. People use computer systems sometimes to act really badly towards one another. A particular problem that our team has run into a number of times is what we call pants problems. And in case you have not run into these, there are a bunch of men on the internet who are looking for technical assistance with their pants. And I can tell this because first they take a picture and then they send it to somebody who doesn't want it. And clearly the message they are trying to send is, help, help, I don't know how to operate pants. I mean, I can't think of anything else they could be trying to convey. And this is only one kind of intrusive behavior. Sadly, there is a whole rainbow of terrible things that people do to each other. And the internet unsurprisingly operates at very large scale. And that means that bad behavior also operates at very large scale. If you've been lucky enough not to see this, check out Daniel Setrin's book, Hate Crimes in Cyberspace, or maybe John Ronson's book, so you've been publicly shamed. I think of mass harassment like a distributed denial of service attack, where people use speech to suppress the speech of other people where they don't like that speech or they don't like people in that group. They essentially flood the target with terrible, terrible speech to the point where they can't, they not only can't respond to that speech, but they can't use the platform at all. And I've seen quite a few systems, especially surprisingly, those often marketed as being for security or privacy, that make design choices that allow some of these forms of behavior to flourish. So they might make the assumption that every user should be able to contact a very other user. Or they might make the assumption that if Alice can talk to Bob once, that she should be able to keep talking to Bob. Not recognizing that relationships change. Or they might, or they might assume that a user needs to personally handle all of the terrible things that are pointed at them. When my server is subject to a denial of service attack, we can bring in more servers to help, right? But we can also make design choices to allow humans to do this. We might be able to let a person bring in some friends to help them. Or we might let the platform help, right? So if a platform can't take down things which are against the terms of service or things which are considered across the board unacceptable, then you end up with each person having to construct effectively a filter. And that means that every single person on the network has to receive, for example, a terrible, terrible picture before that picture is effectively banned from the network. And that's a lot of terrible to be going around. Maybe there are other ways to do that. The terms of service or that takedown alone is not always sufficient to create a comfortable atmosphere for everyone. So to take the least offensive example that I could come up with, sports fans. Different sports fans have very, very strong feelings about different teams. And so if you put them in the same space, it may get extremely noisy. And that's not always something that's going to create a comfortable environment for everyone. So having boundaries and having subspaces can really help. And I don't expect that everyone in the world is an expert in these things. That's actually why our team exists. We can work with product teams and talk about how these failures on a human and a technical level exist and try and design around them. And not only do we help review the product teams' creations, but we can also step in in some particularly complex cases and help them build code. So here's an example is YouTube face blurring. Back during the Arab Spring, YouTube creators were they were activists and they were taking all these really amazing videos and they were uploading them to YouTube. And these videos were getting huge exposure. And so were the activists' faces. And that wasn't necessarily what they wanted. So we worked with the YouTube team and we built something so that you can choose which faces and which objects to blur even as they move around the video. Or in Android, we wanted to help developers, application developers, build applications which are respectful of their users. And in some cases application developers build disrespectful products because they're malicious in which case we should take strong action and just not allow it. But in some cases, frankly, they just aren't experts in this or maybe they copied some unfortunate code off the internet. So we wanted to give them nudges. So in the IDE, when you're writing your code, it will say, hey, maybe you don't want to do that. Here are better ways to achieve these goals. When you upload your application, the Play Store will scan it. And one of the things we do with that scan is give reports back to people and say, hey, why are you writing a flashlight application that's asking for the context permission? That's weird. And maybe you shouldn't do that. The second thing we need to do is understand what respect means. This is a rapidly changing field and one where we frankly don't know all the answers. And we need to tackle a lot of different questions. There's everything from technical problems like how distributed systems break, especially if, for example, you have a hunter who's wandering around and they see this beautiful orange box in the pole and then they decide to shoot it. And then your fiber line goes down, right? And then how do you delete data when you start, when you know that different parts of your system can go down at any time? Or you have purely user focused problems. Like I said, people both need to be safe and feel safe when interacting with a product. And so even if the technical aspects are locked down, if there, people feel there's a problem, even if there isn't a real problem, that is a very real challenge for a product. Then there are problems that change the landscape entirely. New technologies pose fundamentally new issues. Something that works on a desktop may not work on a mobile device and probably isn't going to work in the Internet of Things. Machine learning makes us grapple with data and its use in new ways. What happens when society changes and changes the rules under systems that have operated for decades? How do you build that flexibility into a system? What happens when regulators change those rules? Regulators have a lot of feelings about privacy. As those of you who've been spending a lot of time on GDPR might know. So that means we do research. We do technical research into topics like anonymization and cryptography, privacy engineering and systems engineering. And user research into topics like the different needs of different types of users and how to help them engage with technology. It means we come up with new patterns, new ways to build products and systems, and then we have to test them out through user research or trying them out in production. Because frankly, you're not going to know how well something works until you try it. So for example, my first project at Google was rolling out the internal authentication system that we built for our production systems. And it turned out that it came in two modes. Crash the entire distributed file system. Make web search serve errors to users. And both of those are terrible modes for an authentication system, right? That was not the goal. And we had to go back and rebuild a bunch and try again. The cryptography itself was fine. But how it interacted with the system was something that we had to learn a lot about, especially me because I was fresh out of my PhD and I had never touched a system larger than a robot. And so this is how I learned C++ multi-threaded programming, networking and distributed systems. But there's a lot to learn about how these disciplines interact. Lastly, we need to make it easy. My first choice is always to make respectful systems happen automatically. Because you know what? People make terrible, terrible robots. People have an attention budget. You can't have them keep on doing manual things over and over again. For one, people being people, they just can't do that many of them. But another thing is that they're not very good at doing complex things accurately. So if you've ever watched, for example, non-cryptographers try to do a PGP key signing, you know that when you build and design a system that relies on people being really accurate at complex things, this is going to fail a lot more than you want. So you want to build robustness into that system. And now this doesn't work for everything I'd like to do. I don't have a magic computer where I can take a sentence and put it into there and say, is this comprehensible to humans? Is it reflects the reality of the system? Does it tell you the important things about a system? So we definitely need still humans in there. Humans who understand how respect can fail and patterns to make it succeed. Humans who can teach those patterns to other humans. So let's talk about some of the places where our work intersects with cryptography as I figure it's a fairly safe bet that everybody here finds that interesting. So first up, rolling one's own crypto. Now when I went into industry, I didn't think anybody was going to do that. And everybody in this room is exempted from this. I mean people who are not qualified to roll their own crypto. And I probably should have known better because I got a lot of emails when I was grad school from people wanting me to break their snake oil crypto. And they were so cheap they wouldn't even pay my consulting rate of a pizza. Anyways, in the process of doing security and privacy reviews, I ran into people rolling their own crypto a number of times. And first I tell them, no, no, just no. And then I asked them why. And I thought the reasons why they were doing this were really interesting. Number one, they think they're really smart. And here's the thing. The people who I'm working with here are really smart. However, in this case, what probably happened was that they put the fact that they know they're smart together with the fact that they read Schneier's applied cryptography and they know just enough to be really dangerous. Number two, they think it's cool. And I agree cryptography is extremely cool, even if none of us really dress like it says in the movies. But when people know enough to make it dangerous, then they tend to get into trouble. And when people will also do the same thing in other areas of computer science, like people will say, well, I can write a better database. I can build a better search system. But when people do this in infrastructure, they can tell when it breaks. It is so much more obvious, as opposed to when they mess up in cryptography and they don't realize that they've made data accessible to attackers. Number three, it is not obvious how to do this right. People will say something to me like, well, I have this information over here and I needed to get over here and people need to not see it or not mess with it or something. And then they'll look at OpenSSL or another cryptography library and then they will look at it and they'll say, well, look at this low-level constructor, heaven for fend, a primitive, and things go entertainingly sideways from there because they don't understand what a nonsense or they don't understand, really, the difference between authentication and encryption. Unless you think that is a hypothetical example, I am very sad to say that it is not. That comes directly from a conversation that I had with one of the smartest people I know. And if he's messing this up, it's going to be common. So this is actually why our security team has built some libraries like Tink, which has one of my favorite quotes on its GitHub page. Using crypto in your application shouldn't have to feel like juggling chainsaws in the dark. Because this is what it feels like for most people when they have to look at crypto. And they're going to juggle the chainsaws and they're going to drop them and it's going to hurt. And most organizations don't have a small army of cryptographers running around who can catch the chainsaws. And even places that do, I mean, we have other things we could be doing. So we try and build in robustness. Lastly, the generic protocols are sometimes too expensive still. And one of the things is that expensive, when we're building the protocols, we tend to think about it in things like network cost, right? Number of round trips, number of bytes, amount of computational cost. But there are other things that make a cryptographic protocol expensive. So for example, availability, right? If there's something like you require people to be online all the time, that is really, really expensive for some people. And remember how that's just not uniformly available around the world. So when people run into that, they'll say, well, this cryptographic protocol will almost work for me, but not quite, so I'm going to tweak it. Or I'm going to only protect some of my data or something else. And that doesn't always go so well. Now, there are cases very much in which people need custom-rolled cryptography. But a lot of times I do see people, they should just be using SSL and being done with it. Or they're trying to roll their own authentication system, which has a plethora of pitfalls far beyond the crypto. So moral of the story, do me a solid. Don't give people excuses to roll their own cryptography, okay? The closer what you can design fits what people recognize as a use case. And that recognizes really important here. If they don't understand, they're not going to do it right. The more likely it is that people are going to use what you build correctly. And not everybody has a cryptographer hanging around to politely but thoroughly break their home row crypto. So next up, privacy preserving computation. So a number of years back, I was working with a product team and they wanted to build a feature that let some users on the platform send messages to their other friends who were on the platform. So they said, okay, well, there are people have phone numbers and their contacts and let's set them up so that they can they can send messages to the people who own those phone numbers. Great. That product didn't want to do anything else with that data. They didn't want to do ML magic on it. They didn't want to retain it. Nothing. This is about the cleanest design for a privacy error. Cleanest design for a product feature that you can imagine. So what we needed to build was this. We needed to take phone numbers for people's contacts and send them up and get back user IDs. And the reason why you need to have a user ID in the mix here is this. Phone numbers do not have permanent mappings to humans. Over the course of my life, I am likely to have more than one phone number. And a phone number that I have today may be yours tomorrow. And if I'm talking to Alice for a while and then her phone number migrates to Bob, I don't want to suddenly start talking to Bob. I want to keep talking to Alice. Or at least I want a warning before it starts sending my messages over to Bob. Now the the product semantics can change user expectation here, but this is how I prefer to set up a product. What you would virtually never want is for Bob to show up with a phone number and say, hey, can I have those messages from Alice that were sent a month ago? So by separating the user ID and the phone number, that lets us handle this much better, both at a protocol level and an infrastructure level. To see this on an infrastructure level, I mean just think about what happens when Alice shows up and says, hey, please delete all those old messages and Bob shows up and says, hey, I have the phone number now. Like if both of those things are going on in your system at the same time, you're probably having a very exciting day. So, okay, in this situation we have a relatively small number of phone numbers on the user's device. We have a very large number of phone numbers up on the server side. So this looks perfect for private information retrieval, right? We can also use some of the privacy preserving set intersection protocols, but it turns out that in this case the efficiency isn't quite as good. I'm also going to put another restriction into here, which is that we can't just take the big database of phone numbers on the server side and download it to everybody's device. Partially because, like I said, bits are expensive, but also because I don't really want to offer a big database of all the phone numbers and user IDs of people who are using my service to the entire world. Nothing else that is a juicy juicy juicy spam target. So I went and explained this to the product team and they were super super excited. They said, okay, this is going to make our product better. We don't have to upload these contacts to the server. The feature still works. They were so so excited. Then, then we calculated exactly how expensive this was going to be. With a lot of trade-offs and tweaking and efficient implementation it was going to take us nearly a minute to get the answer back to the user. Okay, okay, the product team was so excited about this that they went and totally redesigned how their feature worked. They said, okay, we can handle that and we can handle all the brittleness that comes as a result of having crazy long latency like that. Okay, here's the real problem. Using private information retrieval for that feature would have taken more than the available amount of computational power in all of Google's data centers combined. Now, we do have a lot of other things in the data centers that are taking up capacity like search and Gmail, but let me tell you this was not a small amount of compute power we're talking about here. It is a lot. So in so far as we literally did not have enough computers to use privacy preserving computation for this one feature alone, we didn't get to do it and I was very disappointed. I'm still hoping for a cryptographic solution and I think signal is too actually I noticed a few years after this signal grappled with the same problem, although at a somewhat smaller scale and they came to the same conclusion. There are happily some places in which we've managed to deploy encrypted computation. So for example we compute the size of set intersection with some thresholds to avoid reporting small numbers between Google's data and an advertisers data so that the advertiser can say oh yeah our ads did something without be exposing anybody's data to each other. And structured analysis applications like these I've noticed are really nice places to look because a user isn't sitting there waiting for the result and because we can sometimes have places where we don't need to handle the huge number of records that we have in user facing applications. And notice I'm saying structured analysis. There are other places where we're fighting abuse or people who are trying to break into our networks and that's much more difficult because when we're handling an adversary they're very inventive and we don't know every technique that they're going to come up with an advance and so we don't know every sort of computation that we're going to need to do in advance. So moral the story here even with a ton of computers and a ton of cryptographers and a very very motivated product team. Cryptographic tools for privacy preserving computation aren't as fast as I would like and I would really like to deploy some more of this so please keep working on it. Okay so computation on encrypted data is really hard right? So let's talk about something which should be easier encryption at rest. A very large system is going to tend to have a lot of hard drives and a lot of computers and then because it's a lot of hard drives and a lot of computers it's going to tend to break. This right here is your enemy. I'm not kidding. Level 3 and yahoo have both blamed hungry squirrels for major major outages. Google has had to deploy anti-shark technology on our undersea's cables. Never underestimate the ability of an animal to seriously wreck both your day and its own. So because we end up in a situation where things break that means people need to go and fix them and that means that they have to put their hands on the hard drives and while we track the hard drives we shred them and so forth I'm professionally paranoid and I want defense in depth here right? I don't want the data on that drive going for a little walk. I don't need the nightmare. Software also breaks. A large software system has this unfortunate habit of breaking in unexpected ways and unexpected means that site reliability engineers and software engineers have to go in and debug it on ad hoc basis and fix it on an ad hoc basis and we control access and log actions and so forth carefully but like I said paranoid I want defense in depth as much as possible. So hey encryption yay! Encryption is an excellent tool for making sure that the data in your system only flows to the places you think it can go and it doesn't flow anywhere else. Okay actually let me amend that. Encryption plus testing. A colleague of mine was doing a security review recently and he looked at a piece of software and it encrypted some data and it sent the ciphertext across the wire and it sent the plaintext across the wire which kind of defeats the whole purpose of the thing. So actually the first code I wrote at Google was fixing very much the same problem in another system so TLDR software is hard and testing is good. So we built the system to make encryption of data easy and to plug into all of our products. So here's the way it worked. For every data object that you wanted to read and write your system would say key management server key management server please give me the key so that that I may decrypt this document and return it to its owner and the key management server would go and think about it and it's gonna there's a whole bunch of security technology built in here that would take me way too long to explain so I'm just gonna wave my hands and it would decide okay should I send the key back in which case great you're good to go or you have you know like you are totally out of luck I refuse to let you decrypt that object. So I want to start by talking about the keys in the system and I know this seems obvious but I'm going to specify anyways the keys for all the different objects are different so you don't say oh I pulled up this encryption key for for my photo and for some reason it's the same key as we use for all the emails that doesn't make any sense but I'm just getting that one out of the way. Another thing about how we design this is the key management server knows about the objects and who should have access to them under what conditions like what systems should be touching them but it doesn't know where you put the objects and this is by design because when your data centers are going to break you may need to migrate your data around and so the data objects remain the data objects even if you move them around you don't have to tell the key management server every time that happens. Note that we as a result of this essentially have to have two layers of access control one of the storage layer because you don't for example want somebody coming in and accidentally overwriting all your data even if they can't see it and one that's this whole cryptographic layer. Another thing that we have going on with the keys is the keys have to be accessible globally and very very quickly otherwise we have people sitting there going where's my email I'm sitting here where's my email. Speaking of email Google has a lot of objects people a lot of people have us handle access to their email and hold on to it for them the same for their photos and the same for their documents like that we just have a lot of stuff that we're holding on to because people asked us to and so attempting to store all the keys corresponding to all those objects in the key management server would be somewhere between really really hard and really really expensive and probably impossible because the keys need to be accessible quickly and globally which means you have to replicate them all over the place and information theory tells us that shared state isn't is going to be expensive that you have to shuffle all of those bits all over the place the more places you have it the more expensive it is but you can also assume that this is going to be even more problematic in a world that includes our friend the squirrel so the people who did this did the clever thing instead they took each of those each of those object keys and they wrapped them and encrypted them under a key held by the key management server and so now all the product teams have all these little wrapped keys that they have to keep track of which is annoying but we can make the key management server scale right so that's excellent we have crypto we can plug it right in no one has to roll the ron okay now i'm gonna get to the bad part there are multiple places where this system does not work in practice for one encrypted data really doesn't compress well and if your encrypted data does compress well we need to have a chat because that that's a problem and there's this thing that users do where they just as an example why you care about compression where users will send the same cat picture to each other so many times like i don't even know how many times but it's it's a lot and so when you have seventeen bazillion pictures of Santa cat in your system and you want your system to keep working you might want to care about the compression so effectively you end up with two options one of them is you just put all copies of Santa cat in the storage system in the storage system can say okay well i can see better how to encrypt uh compress all these pictures of Santa cat and it gets much smaller or if you have the product handling this encryption in this way it says oh a picture of Santa cat can i can i compress this a little okay i'm going to encrypt it and stick it in storage the storage can't do anything after that and then it does it again and again and again and again and again and again so the storage now has a whole bunch of encrypted copies of Santa cat and it can't do anything to make them easier to handle another thing in here is that it turns out that one of the things that people really want in a storage system is indexing so being able to look up particular pieces of data by different keys and they also want indices that do fancy things like ranges and this is at best extremely expensive when we're indexing a very large amount of encrypted data the best case is where we're looking for exact matches like hey give me all the comments that go with this youtube video and it gets a lot worse right when you start saying things like please give me all my youtube comments from three weeks ago let alone please give me all of the indian restaurants in this geographic area which are open right now and i probably shouldn't be talking about food since it's just before lunch but please forgive me for three bits of encrypted data are going to look uniformly distributed or if they don't we're going to have a chat but access patterns are not they tend to be very different depending on what people are interested in like if you watch a video go viral it has a little bit of access and then it has a lot of access so that means that how your access patterns are changing art is going to have a lot to do with how well your storage system is working and remember all of those site reliability engineers and software engineers who are touching these systems there this is a lot of what they're doing is tuning it making sure that it stays up and doesn't just fall over when it gets a lot of load and when that load changes unexpectedly now one of the things that's really tricky about this is when we encrypt the data it means that a lot of the techniques that they use go right out the window so for example sharding where you want to go and take related data and you want to store it together so that the access pattern doesn't cause your server to fall over well if i can't see what's in the data i don't know how to sort it or predictive caching where you say okay i can see this pattern where people are picking this stuff up now i know that now i i'm pretty sure that this this particular piece of data is going to get hit a lot next i'm going to just preemptively pull that up and stick it in the cache getting systems to run at this scale let alone fast is really really hard and so and it's a lot harder when we take techniques away from these people but here's the reason it should be most basic to us as cryptographers key rotation actually more generally we should be worried about crypto agility where we don't just change the keys but we change all the algorithms but for the sake of this talk i'm just going to stick with the simplest case we can have let's let's just change the keys because if we can't change the keys then what we built is an obfuscation system rather than an encryption system and that wasn't the goal at all so let's take a look at what it takes to do that key rotation okay for every single object i need to be know what it is so i can pull down the correct key and decrypt it and then pull down the new key and re-encrypt it and store it back in our storage system okay well first thing is you have to know what the objects are and that gets really tricky this is the most simple example i could make up and you'll notice that the names of the objects are dependent on semantics of that of that system right that that not there's no uniform naming scheme now it gets way way more complicated because you can end up with one logical object being stored in different pieces of a storage object or you can end up with different logical objects being stored in the same storage object like i put two different comments in a file so that gets super tricky so in quarter to do this we in order to do this re-encryption we have to know the the all the object names and and be able to figure that out in storage okay but the trickier thing here is that the show must go on the product isn't going to stop doing product things just because we decided it was time to rotate the keys software maintenance windows just aren't a really a thing these days and if the product's trying to read and write from storage at the same time we're trying to do this key rotation and read and write from storage it's likely to get extremely messy so i'm going to leave consistency issues aside because that's like a whole other barrel of squirrels but most storage using use for serving users doesn't have an access pattern of read and write everything exactly once and performance just isn't of the storage systems just isn't tuned for that so in practical terms you may want to take that storage table offline while you're doing the re-encryption you may want to slow down your re-encryption you may want to do the re-encryption in a certain pattern but you the problem is you don't know which of these things you want to do unless you understand the traffic pattern and how this is going to interact with the traffic pattern so as a result in practice we found that you couldn't actually do re-keying in a setup like this without talking to every single team who has storage and at google at least there's like a lot of these people a lot and that's a lot of coordination that's a lot of manual work and that's a lot of opportunities for things to go wrong and then you have to roll it back or go wrong and then you have to pull the data back out of a backup and try again it's a lot of risk that's a lot of overhead for a procedure like key rotation which you should be doing regularly as a matter of hygiene and be very reasonable to perform on an emergency basis so we built this entire thing we tried it out and we just decided it wasn't practical so instead we decided to look a little further down the stack and move encryption into the storage system so instead of every single application doing this then we made this made it possible to fix all those problems I was talking about the storage system can now do the indices the storage system can now handle compression the storage system can avoid causing hot spots when it does the re-encryption actually it turns out that if you put this in the storage system there are all sorts of other little interesting tricky techniques that you can use to avoid causing hot spots in the first place because they they tend to do a lot of self-maintenance anyways and you can roll that in and it has this other really awesome benefit which is that if you don't have all of these products needing to plug in a crypto library then they can't forget to plug in the crypto library and that means I don't have to check if they forgot to plug in the crypto library because like I said terrible terrible robots for access control we can go back to leaning on the access control that was already built into the storage system in the first place and that's especially nice because when you have two orthogonal security systems that are handling the same thing I have I don't have particular data to back this up but my experience has been that it is way more likely that somebody's going to misconfigure at least one of those things because you're gonna they're going to interact in interesting ways that are not obvious when you're doing configuration so there's of course a trade-off here we've made it so that the storage systems now see the plain text but in a world where I can do the encryption but I have more systems who can see the plain text or I can't do the encryption because my system falls over but I have more systems that can but you know like I just don't have options there I will usually choose the form there are definitely situations in which you don't do it at all is the correct answer but in this situation we decided to move it into the storage system and in fact we built some more security technology and we did some more hardening on the storage system so that we were so we were presenting less on a risk surface so moral of the story cryptography in a lot of ways is a tool for turning lots and lots of different kinds of problems into key management problems so when you're designing keep in mind that key management is hard at least it's a lot of harder than I knew before I actually started having to deal with it and keep in mind there are a lot of humans in the world there are a lot of squirrels in the world so do me a favor and plan for key management at the time you're doing design so to sum up here do me a solid don't give people excuses to roll their own crypto please make privacy preserving computation faster I would like to deploy a lot more of it key management it's hard it really is but most importantly evaluate the success of your designs in terms of the full stack all the way from humans in their societies all the way down to the hardware you can't win in a vacuum and that means you need to think about humans and the messy messy ways they interact with each other and the messy messy ways in which they're going to interact with your pretty pretty pretty math it has helped me a ton to pull more perspectives and more skills in because I'm not a UX person but when I've been able to work with UX people or when I've been able to work with systems people when I've been able to talk with and run user studies for groups of people where I just don't know their experiences it has helped a ton in building really successful effective privacy and security systems diversity is a huge huge huge help if you want to do this and never forget the squirrels are out there the world is really really messy thank you so much