Q&A With Cape Privacy Co-Founder and CTO Gavin Uhma: Part One

Cape Privacy's Head of Marketing, Reesha Dedhia recently sat down for a two-part conversation with the company's co-founder and CTO, Gavin Uhma. In Part One, they talk about the meaning behind the Cape Privacy name, the importance of privacy and data security, and the "Aha!" moment when organizations come to understand what Cape Privacy does.

Reesha Dedhia: First, the name: Cape Privacy. Describe the decision on the name in terms of your vision for the company's tech and the growing importance of privacy protection as a business imperative.

Gavin Uhma: The name Cape has a couple meanings that we liked. One is the idea of being something protective that a superhero would wear, or that oftentimes a normal person would put on to become a superhero. A cape can either be protective, or has that superhero connotation that we like. I'm also from a place called Cape Breton. A cape is a headland that juts out into the ocean. There are capes all over the world which are often beautiful places; they have a positive connotation and hold a personal connection for many people.

And, as a word, it's short and can be used as a prefix for different product names.

Reesha: Despite the name, Cape Privacy doesn't tout itself as a tool for privacy protection or compliance. What does the "Privacy" part of Cape Privacy mean to you?

Gavin: We deal just as much with security and particularly cryptography as we do with privacy. But privacy represents why what we're doing is important to the world. Cryptography leads to better privacy for people.

When you have a technology like HTTPs, as an example, which is used in the browser, that's a cryptography protocol. That's a security technology, but it very much leads to better privacy. It means that you can prevent a man-in-the-middle attack when you're browsing a certain website. HTTPS enables online banking, it enables online payments. And now we use it everywhere–on blogs, news sites, social networks. We use it everywhere because it's just better. It's better for the security of the internet. It's better for the privacy of the internet.

A company might view that as a security technology because that means that their user data is not being breached, whereas an end user might see it as a privacy technology because it means that their data is protected from someone that they don't want to see it. The privacy part of what we're doing represents our mission to bring this new technology to the world that we believe can make the end-user experience across the internet and across intelligent products and services better.

Reesha: When most tech vendors discuss privacy protection the focus tends to be on process: understanding certain regulations and addressing a series of prescriptive measures to establish an audit trail, for example. What is the Cape Privacy approach to privacy protection and why do you think it is important?

Gavin: When data is encrypted in a database, for example, that means that someone holds the key to that data. But the key and the data are separate; you can take that encrypted data and you can move it anywhere. You can move it from on-premise to the cloud. You can move it from AWS to Azure; to GCP. You can move it from MongoDB into postgres. The data can move anywhere. The general idea is to keep the key protected somewhere because it unlocks the data.

Regardless of where the data goes, you have to get access to the key. If for some reason you wanted to delete that data–and when we're talking about audit trails and things like that–what if you didn't know all of the places where that data went? You can just delete the key and the data is effectively deleted because the keys are gone, so you can't access the data anymore. Today you see companies becoming more granular with their use of keys, where they're starting to apply them on a per-customer basis, so the identity of an individual customer and any data related to that customer, regardless of where it goes, it's encrypted with the same key.

If you had a request under a privacy regulation like GDPR to delete a user's information, traditionally it would be very hard and very expensive to track where that data goes, through all the systems and all the places it was stored. If you can just delete the key, it doesn't matter where it went. You don't even have to know. As a security organization or as a compliance organization, you know that the key was deleted so you can trust that the data was effectively deleted.

However, today whenever we need to process data, if you're doing customer analytics, for example, you have to decrypt it; it becomes plaintext, so it's no longer protected. And at that point, you lose control over where the data goes. The audit trail becomes unmanageable because maybe it was decrypted so that it could go into Tableau to run a report. But then where did that report go? Maybe somebody printed it out on paper somewhere? Did they move it into some other system, or email it to someone? Did they store it somewhere?

You completely lose sight of your data as soon as it's decrypted. It's a huge, huge weakness that we have to decrypt data in order to use it. So what Cape Privacy does is keep data encrypted, even when you use it. That means you can generate reports, you can run models on the data, you can use the data while it stays encrypted. If you ever had to delete that data, the data still traces back to the key so you can delete the key. You can delete all the data regardless of where it was used or how it was used.

Reesha: Encryption-in-use is a straightforward solution to a longstanding security problem. Why has it taken this long for a commercially viable product that accomplishes that simple paradigm to come to market?

Gavin: Encryption—whether we're talking about HTTPS or AES, makes things slower because when you encrypt information, you make it a lot larger, and there are keys involved.

With AES, if you encrypt a piece of data for storage, as an example, you have plaintext data and that produces your ciphertext, which is the encrypted version of it. But it also produces a key. So right there, one thing became two things. It's already much bigger, and the ciphertext is a lot bigger than the original plaintext was. Plus, you had to run through an algorithm to get there. The AES algorithm had to process the data in a bunch of ways to securely produce the ciphertext and the key. So it's larger and it's heavier to process.

With HTTPS you have to do a handshake with the website that you're communicating with to exchange keys. Then you're going to use those keys to encrypt the data so that when you send it to the website, the website can decrypt the information. And so the data that you're now sending over the network is much larger. You need to process the encryption and decryption. Plus you have these extra communication steps that you have to take during the handshake.

With secure multi-party computation (MPC), where you're looking at computing encrypted data, there's a similar problem. The data has to be encrypted, so it's much larger than it was before. But we have to go through all these extra steps when we're processing the data. It's much more computation than what you would have to do on plaintext data. There's this whole cryptography protocol that we have to go through. It's more bandwidth and memory to have larger data and you have more processing to do.

Whether you're looking at AES, HTTPS, or MPC, they were initially really slow.  But with investment and innovation, they've become easier to deal with, more efficient, and generally lower cost.

HTTPs has been around since the 90s. It's had more than twenty years of development. AES has also had more than twenty years to become more efficient. MPC is only just now starting to gain traction and attract heavy investment, and we're starting to see the performance gains. Cryptocurrency has been really good for MPC because you see it being used in production at scale for a lot of cryptocurrency related projects. Coinbase recently acquired Unbound, for example. We're also seeing the shift to cloud becoming a good reason for companies to invest more heavily in MPC.

Secure MPC is just now starting to hit that curve of becoming lower cost and more efficient. So in, let's say, 15 years, we'll start to see MPC used as a default, the way you see secure storage and secure networking. Once you get the costs low enough, you might as well just use it because it offers much better security.

Reesha: How difficult is it for organizations to grasp what the Cape Privacy platform does? What is the typical response when the "Aha!" moment arrives?

Gavin: We're getting a lot better at explaining it, so that helps. Every organization has this problem, but they're not aware that there's a solution out there, so it's a problem that has been accepted, like gravity. We just accept that there's gravity in our life. Organizations have come to accept that they can only process data in plaintext. They're not thinking, "Let's keep everything always encrypted."

We've got to be really good at explaining things so that organizations think about it, see that they have this problem everywhere, and then it's, "Aha! We should use this everywhere."

The other, "Aha! moment comes after people ask, "How is it possible to process encrypted data?" That's a really good question to hear from customers, because if they don't do a second take on that, then we worry that maybe they're not understanding how important this is. So, when a customer is like, "Wait, the data is encrypted. So how can you process it? Isn't the point of encryption to protect something in such a way that it can't be read?"

When we hear that question we can explain how it's possible, and then they have an "Aha!" moment of, "Okay. I get it now." And that makes it easier for them to not only see the problem, but adopt a solution.

To explain it, we don't read the encrypted data, but we move the bits around in such a way that we change the underlying data that was encrypted. For example, you can say in plaintext 10 + 5 = 15. You can also say encrypted 10 + encrypted 5 = encrypted 15. You didn't read the ten, you didn't read the five, and you didn't read the 15. You just mashed the encrypted bits together in such a way that when you eventually decrypt the result, you get a 15. The result is the same as if you had added the plaintext numbers together.

Stay tuned for Part Two: In Part Two, Gavin describes what happens when an organization grasps the idea that they can keep data encrypted and still put it to work–in the cloud. Then he explains why Cape Privacy's partnership with Snowflake is the ideal combination for financial services organizations. Finally, Gavin offers an inspiring vision of what's possible when data–and individual privacy–is protected by default.

To learn more about Cape Privacy and our platform, visit our website. Or contact Cape Privacy for more information.