Homomorphic encryption allows a provider to run computations over encrypted data. Thus we do not necessarily have to expose sensitive data to a provider in order to manipulate this data and derive insights from it.
The tradeoff comes in the form of increased time to compute and increased complexity in the storage, retrieval, and manipulation of the data - the provider has some general sense of what type of data is stored where, but cannot simply determine what to do by looking at the plaintext values.
A few companies/research groups are working on bridging the gap between the extremes (unencrypted/fully homomorphic encryption) in order to come up with a good compromise between security and cost.
> Both the CryptDB and Monomi publications cited approximately 20% performance impact and neither offers full, standard SQL functionality.
With increased regulatory standards on the near-horizon - healthcare/insurance in particular - research in this area holds a lot of potential, especially if they can get the overhead closer to 0% and figure out a way of safely tagging data for manipulation in a way that does not expose it to re-identification.
Came here to post a summary but you did a better job than I could.
> A few companies/research groups are working on bridging
> the gap between the extremes (unencrypted/fully
> homomorphic encryption) in order to come up with a good
> compromise between security and cost.
I just wanted to add that plain text vs homomorphic encryption is indeed a security and cost trade-off.
Fully vs partially homomorphic encryption is a trade-off between supported operations and cost. Fully homomorphic systems allow arbitrary computations while partially homomorphic systems do not, hence the lack of support for standard SQL.
I needed this for a DB a while back - patient names. You need to be able to do searches on partial names "Dav" to find "Dave, David, and Davide", as well as sort results. That makes things extra tricky.
Homomorphic encryption allows a provider to run computations over encrypted data. Thus we do not necessarily have to expose sensitive data to a provider in order to manipulate this data and derive insights from it.
The tradeoff comes in the form of increased time to compute and increased complexity in the storage, retrieval, and manipulation of the data - the provider has some general sense of what type of data is stored where, but cannot simply determine what to do by looking at the plaintext values.
A few companies/research groups are working on bridging the gap between the extremes (unencrypted/fully homomorphic encryption) in order to come up with a good compromise between security and cost.
> Both the CryptDB and Monomi publications cited approximately 20% performance impact and neither offers full, standard SQL functionality.
With increased regulatory standards on the near-horizon - healthcare/insurance in particular - research in this area holds a lot of potential, especially if they can get the overhead closer to 0% and figure out a way of safely tagging data for manipulation in a way that does not expose it to re-identification.