Freely subscribe to our NEWSLETTER

GS Mag: Let’s end the debate: Are hardware-based tools or software-based tools the best way to encrypt and decrypt databases?

Ulf Mattson: I think that might be the wrong question to ask. The right question would be about the topology. What is the right topology to use for database encryption? Remote encryption or local encryption?
The topology is crucial. It will dictate performance, scalability, availability, and other very important factors.
So I think the topic is important but the question is usually not well understood. Usually, hardware-based encryption is remote and software-based encryption is local but it doesn’t have anything to do with the form factor itself. Instead, it is about where the encryption is happening relative to your servers processing the database information.

GS Mag: Why do you think people are asking the wrong question?

Ulf Mattson:It is because they are trying to apply what they’ve learned from other areas of IT. For example, from network encryption they’ve seen that software doesn’t perform as well and that hardware is the best way to accelerate encryption. So they say, “Oh, hardware is the answer, that’s the way to offload processing requirements.” And they jump to the conclusion that this must be true for database encryption as well.

GS Mag: Why don’t these principles apply to database encryption?

Ulf Mattson:When you have, say, credit card data, you have to remember that databases usually operate on the field level. So you cannot send more data than one credit card number at a time. You encrypt it and then you need to give it back to the database immediately because it is sitting there waiting to send the next one. This is particularly a problem with decryption. For example, when someone is searching data and can’t wait for slow response times.
When you compare this process between local and remote encryption, the path length—the number of instructions that the computer needs to satisfy your request—is so much longer when you send the data over some kind of network and then receive it back compared to just doing it locally. It could be up to a thousand times longer of a path length to send it to a remote appliance compared to doing the decryption locally on your data server.
Sometimes it is important; in other cases it doesn’t really matter.

GS Mag: So how do you determine if it is important to your enterprise?

Ulf Mattson:First, you need to determine whether you are doing batch or online processing.
If it is batch processing you’ll need to determine what kind. Are you doing more normal batches where you have a batch job that must run in four hours, or a sequence of batch jobs that need to be finished before morning? Or are you interested in data loading where you can take a chunk of data and go off and process the data and come back and no one is missing it in the meantime?
If you’re doing online transactions then you’ll need to determine if it is online transaction processing with transactions that you’re processing one record at a time while the user is sitting there waiting, or if you are doing online data warehousing where you’re searching large amounts of data at once.

GS Mag: Ok, let’s tackle batch processing first. How will the topology affect encryption activities during this type of processing?

Ulf Mattson:If it is a normal batch, I’m sending it over the wire and my database is sitting there and waiting for every credit card number to be encrypted and come back before sending another one and continuing the cycle. If I send it to a remote platform, the batch will stop and wait maybe a thousand times more than I’d expect. So a batch job that would normally take eight hours might take eighty hours. That’s not overnight—it isn’t even over two nights!
Then we have data loading. Sometimes it can be nice to encrypt the data on a cheaper platform before you load the data into your production database. So you pre-encrypt it, offload it and do it with cheaper equipment. That’s provided you have the time.
But if you are, for example, in a retail environment you might have a time constraint. So you need to load the data from your four thousand stores in a certain window. And at that point you may want to use all of the processing power that you have invested in to get the data loaded. That means that you still want to do the encryption locally in your big database server to take advantage of that high end system.
Data loading is the gray area when it comes to local or remote encryption. It depends on whether you really want to offload the processing or if you want to do the data loading very quickly.

GS Mag: And what about online processing?

Ulf Mattson:Both of the major use cases are detrimentally affected by remote encryption.
If I have a data warehouse and the user is sitting there and needs to search among 100 million records or maybe five billion records, like some of our credit card customers, then it’s crucial how much time is consumed for each decryption. The person is sitting there waiting for hundreds or millions of records to be decrypted before the answer comes back.
If you do it locally, you may have a response time of around five micro-seconds for each record and then you multiply by 100 million if you have 100 million records and so on. Compare that five micro-seconds for local encryption to the case of remote encryption. You may have a thousand times greater processing time, so if you add up that time the user may wait for an hour instead of one second.
In online transaction processing, one user may not see a difference between local and remote encryption. Because if one user is looking for one record in the database, the difference between five microseconds and five thousand microseconds is not noticeable.
But if you have high volume of processing on your computer it will matter. If you add up all of your transactions and each of them takes a thousand times longer than necessary, you will hit the roof and you will overload your computer. It can really cripple you.

GS Mag: But what if I have a fast network? Won’t the speed of the hardware appliances and the speed of the network mitigate the issues you’ve mentioned?

Ulf Mattson: It is interesting also to notice that fast network doesn’t really help you. If you summarize all the steps that need to be processed for the data to go all the way from the database, over to another appliance and back, that path length is so much higher that the network speed doesn’t really help you.
Another thing to think about when you dissect this is, if you want to be secure, you actually need to encrypt the wire between the appliance and your database server. Guess what? It costs you more overhead to encrypt that traffic than to do the encryption in the first place.
Another myth is that the speed and the power of the appliance is going to affect the total speed of the encryption and decryption processing. The marketers will say, “Well, we can stack appliances so that you can harness this enormous power of these boxes. Put it on a fast network and you can really offload the processing.”

GS Mag: Sounds good, right? On the surface it sounds nice but the truth is quite contrary to what they’re saying.

Ulf Mattson: I think it is important that everyone understands that this is not spin; this is what the industry has seen in benchmarks during the last 10 to 15 years. I usually cite figures in my papers and so far no one has come back to dispute them.