A First Look at Homomorphic Encryption

Welcome to the KuppingerCole analyst chat. I'm your host. My name is . I'm the lead advisor and senior analyst at KuppingerCole analysts. My guest today is Alexei Balaganski. He's lead advisor in cybersecurity with a strong background in math. And this is something we might need today. Hi Alex. Say Hello. Thanks for having me. Yeah. Great to have you again.

And, um, this is really something that I'm looking forward to because we are dipping our toes for the first time in a new topic that we have not yet covered before. We want to talk about encryption in general, and we want to talk about homomorphic encryption. And when you mentioned that this is an interesting topic that we could cover within our podcast.

Um, what I, as moderator would usually do, and I did that to Google that term, and I came to a few introductory articles in publications around the web, and I checked back with you and I said, is this what you mean? And she said, no, exactly not because there's much more about that. But before we start, uh, Alex, let's have a short look at encrypting in general. What are the typical areas where encryption is applied?

Why, where can we see encryption today right now? Well, yes, you're absolutely right. We have to start a little bit from afar. And normally when we are talking about encryption business applications, we are talking about encryption at rest encryption in transit and encryption in use. All the former two are pretty obvious. We have already figured them out for decades. So for example, when you're talking about encryption and trust, you're basically talking about files or my database tables or the whole disks or partitions statically encrypted.

If you will, you have a block of data, you have an encryption key, you apply encryption once and then adjust to remain like that until you actually need to access the data that says encryption at rest. Pretty simple cryption in transit is for transmitting the data security over a network channel. So if you want to move your data from one server to another, you have to encrypt it. And again, this has been fingered out for decades. We have the TLS protocol, the standard for encrypting data on the fly, if you will.

And, uh, it it's usually the last one, the encryption in use where it comes to confuse Lukes and heads crashes. Like how is it even supposed to work? If you have your data encrypted, it's usually means that nobody can do anything with your data. That's the whole point of encryption, right? And yet you are supposed to be able to use it somehow without decryption of, to tell you the truth. Most companies which are promise or encryption use, quote unquote cheat a little bit, they do decrypt the data, but only the necessary part.

And usually only within a secured hardware-based enclave where special hardware like secure chips or specialized processes, ensure that nobody else can peek into your data. I would be decrypted processed and encrypted again, right? That's the traditional approach, which is what we use in a database engines and so on.

And this Is something that we would expect to have happen because if we want to use the data, if we want to filter, if we want to process it, and if we want to derive any information from this, um, formerly encrypted information, we need to have it in a form that we can have a look at it. So I would assume usually that even encrypted data that is stored encrypted, that has transferred in encrypted, um, needs to be made available in the memory of the computer that actually these tasks can be executed. And this is changing right now.

Oh, this is exactly how it, we expect it to work. And this is how most existing data processing solutions are implemented. As I mentioned, like relational databases, for example, because you have to keep the data somewhere in memory for heavy computational process. Unfortunately, there are pretty important use cases where it just doesn't work at all. A typical example would be the so-called secure multi-party computation simple example. Imagine like I have a pot of gold and you have a pot of gold at your home.

And they want to find out who has more girls, but I'm not allowed to tell you how much I have in. So do you, how do we find out who has more money or whatever sensitive resource? The typical approach would be to choose a third party who we trust and show them our gold spots, right? And then they would say, okay, yeah, my Ts have more, but sometimes it just doesn't work for whatever security or compliance students. You are not allowed to show your unprotected data to anyone.

And there are indeed groups, the graphical methods to perform this small multi-party computation in a way that no party would ever reveal their data to the other party. And yet the computation will succeed. I'm not even going to dive into the mathematical details of this approach, but just trust me, algorithms like this exist in the have existed for decades. And they find pretty important use cases in financial industries.

When, for example, you have your salary data and you want to invite or insurance company. If they need to know how much salary your employers have, but you cannot share that data because it's sensitive. And he would set up a special encrypted infrastructure that would generate a lot of cryptographic operations exchange, lots of data, it's pretty computationally heavy, but in the end, we will have your results, computed security, and privately. And the same in a way applies to this homomorphic encryption.

The idea is that you have your data encrypted, you apply some sequence of mathematical operations to the encrypted data directly, and then the result you will have your computer, the result in the encrypted form. So whenever someone comes with an encryption key, they will decrypt your result and it will be the real, proper mathematical result of your computation. And no data will be decrypted at any time until it's actually needed. Sounds like magic, but it does work in a way, Okay. If I get it right, right.

So both the data and the processing remain confidential, but nevertheless, the results that we want to achieve can be achieved without, at any time breaking the security. Right? Exactly. This sounds like totally counter-intuitive, but it does work. And in fact, the fruit developments in this area have started in like 1970s. So like 50 years ago, and I would say, or within the last decades, they have reached the stage where almost any kind of computation can be performed in this homomorphic, August encrypted methods.

The problem in that are in order to implement encryption, that is homomorphic way. You have to first design, basically an entire new class of encryption methods and especially crafted operations on the autocratic data. For example, every type of encryption has this, uh, property, which is called malleability basically again, without going into details. It means that suppose you have a block of encrypted data, which says, for example, I owe my tears pander to Euro and you take my encrypted data and you manipulate it directly without decrypting.

In the end, you will get the result in text, which says, I have materials 200 euros, which is a well-known problem in the loop of quote unquote, do some cryptography because you are supposed to detect and prevent these types of attack, right? You do not want your encrypted data to be manipulated, but within homomorphic encryption, it's actually a desired property and you can design your encryption method a way that it can be malleable into a specific way in order to, to allow us performing a certain type of operation.

For example, you can create an efficient method to two encrypted numbers can be summed in the result of that. Oppression would be actually the sum of all surgical numbers encrypted. So you can add two numbers without actually decrypting them.

First, the same would apply to archetypes of a perishable multiplication, subtraction and so on. And the, to the scientists and mathematicians decades from early seventies to like 2015 to design a set of methods to actually perform nearly any kind of oppression on encrypted data. So nowadays starting from 2015 or something, you have existing open source libraries as the case in projects, which allow you to perform various operations on your encrypted data without decryption, there's only one problem it's hugely computationally expensive.

There is a lot of overhead where you have to encrypt the crypt. Reencrypt different types of data. You have to exchange a lot of data over the network and all probably thousands of cryptographic operations for performance. Just one addition of two numbers, I've read some interesting research papers and they would claim that if the result of a primitive oppression took like several hours, it was a great achievement and the same approaches you would probably do in seconds. If you were dealing with unencrypted data. So it is complicated.

It is extremely performance heavy, but with the power of the cloud, it's actually already usable. Okay. This is understood from my side, but when you say that, okay, the technology is there.

The, the, the mathematical foundations are there, but it has these limitations. As you have described, what are use cases where this can really already make sense for organizations? Where could we see that in the near future actually showing up in our real life?

Well, the most obvious use case probably would be a financial industry where you have to perform relatively light mathematical alterations, because you don't have to integrate your money or just some or subtract or divide or not. When you are dealing with financial records, you have to keep them safe. You have to keep them private at all times, right?

So if you could perform your financial transactions using homomorphic encryption, that will be a huge improvement in compliance and security and until a certain number of separations per second, I guess computing overhead is okay, is that right? Already banks or insurance companies, which are working on such projects, it's probably far from production use, but there are some interesting developments and companies like IBM and Microsoft and other large cloud vendors, they have different libraries.

And if the cases I mentioned and even cloud services, which facilitate this implementations in other interesting potential use case is oddly enough, machine learning because machine loading requires huge amounts of data for training. And the data is usually extremely sensitive. If only a company would be able to encrypt it sensitive data, let's say an automotive company collects usage data from their vehicles, contains lots of sensitive information about the customer's location data, again, financial records and stuff like that.

If you put all that in a traditionally encrypted data lake or data warehouse in the cloud, you cannot do much. You could probably run some primitive reporting every now and then, but it's nothing even close to real time. But if you implemented on a large scale homomorphic encryption solution, might I feel a lot of interest in real time insights from the data, Right? So this homomorphic encryption would then actually be the key to actually have data privacy being established while being able of processing the data in a meaningful manner and in a compliant manner. Right? Exactly.

Connected to think about every solution for like data privacy enhancements we have until now are basically crutches. They are workaround that compliance check does if you will.

So yeah, we have our data encrypted, but when they do, when we run analysis for our business reports, we have to decrypt it. Or when we train our machine learning model, you have to decrypt it. So here it's like almost private, it's almost secure. It's come a morphic encryption. It can actually stay encrypted all the time. So this is in theory, the only into end hundred percent secure and compliant method of dealing with sensitive data. So companies are, who need these kinds of like hundred percent compliance. They are happy to jump on the bandwagon.

The only question is like, why is it not as popular as let's say, machine learning or blockchain or any other recent disruptive technology. If we look at the use case that you've mentioned, and the question that you just raised regarding the popularity, are we not yet that far or what is actually the reasons you've mentioned IBM and Microsoft and other companies being already some pioneers in this area providing actual current, tangible solutions. Should we expect that to be more popular in the future? Will that be something that we will see much more frequently?

Well, I see several explanations why it has not yet gained the same amount of hype as other clauses. First and foremost, it's really, really complicated from the computation for the mathematical point of view. It's more complicated than machine learning or blockchain and something that requires a lot of investment into network and computing infrastructure, high performance infrastructure. And of course, a lot of understanding how this whole mathematics works. You cannot buy it as a service.

Not yet, at least, for example, if you want to utilize a machine learning method for image recognition, you already have like a cloud-based API, which you just unlock with a credit card and you can utilize it without even knowing how machine learning works. It's coming more for consumption. It's not there yet. You have to understand how it works. You have to build directly into your application business logic, and yes, companies like IBM or Microsoft, or some other vendors do offer some level of obstruction with libraries and empty case. But it's nowhere near that S a S level yet.

So you have shared Today is an insight into your ongoing research, um, from the status that you've just described this as something that is not yet something that shows up immediately in our current research, but we are nevertheless following that topic, right? We are absolutely following that. And I have to confess the idea, like why should we discuss it today? Came to me after I listened to one of the webinars, IBM morphine group, there was a lot of interesting academic level of discussion.

And again, even though I do actually have a degree in mathematics and I try to read through their research papers and lots of fascinating research, it's a little bit over my pay grade to understand how it works. But even then I still have a feeling that while they have this amazing academic achievements, they still haven't figured out yet how to actually properly sell it to customers because customers just don't understand homomorphic encryption. It sounds too complicated. So they would understand if it would be sold as a service solving, a specific use case that we have discussed earlier.

We are not that far, right? I guess the same applies. For example, to quantum computing, you can already start using it today, but it's a little bit complicated. It's a little bit higher, or in complexity than a traditional developer or business user would expect to even understand what it does and what it cannot do. And this is probably where we have analysts can actually help those vendors. If you could explain homomorphic encryption to a person like the five, that alone would help to understand where it can be applied and how much effort is needed for that. Right.

And I think that is actually the value that we can provide as analysts being the translator, translating between the technology and the business use case with the vendors. So for today, um, thank you very much Alexei for giving that brief introduction into homomorphic encryption. We will surely follow up on that quite soon, because there is more to learn about. And the next question that I will ask, or the first question that I will ask in our next episode around that topic is why it is called homomorphic encryption and why homomorphic is the right term here to apply.

But this is something for next time. Thank you very much, Alex, for being my guest.

Well, thank you much and see you soon sometime, right? Absolutely. Thank you very much. And looking forward to learning more about this really incredible, um, yeah. Innovation that we have here right now. Thanks again. And bye. Bye bye-bye.