Live data from Hacker News

Things to Know about Databases that Leverage Partially Homomorphic Encryption

lab41.org

11–20 of 20 posts

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#11

I've wondered about another system, and perhaps someone here can point me in the right direction. Fully homomorphic encryption (FHE) has total control of two operations. Partially homomorphic encryption (PHE) has one operation. We can do PHE pretty well, and we're currently very very bad at doing FHE in reasonable amounts of time. In Craig Gentry's FHE schemes (and all current ones that I know of) are all based off o…

[deleted]

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#12

Quick summary of a great article: 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 genera…

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.

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#13

I've wondered about another system, and perhaps someone here can point me in the right direction. Fully homomorphic encryption (FHE) has total control of two operations. Partially homomorphic encryption (PHE) has one operation. We can do PHE pretty well, and we're currently very very bad at doing FHE in reasonable amounts of time. In Craig Gentry's FHE schemes (and all current ones that I know of) are all based off o…

I don't see this idea of bootstrapping at all in the Enigma whitepaper: http://enigma.mit.edu/enigma_full.pdf

Enigma uses secure addition and multiplication protocols to construct a fully secure interpreter. A user throws a problem to a bunch of decentralized nodes running this secure interpreter that are incentivized by fees to perform these computations and then post the results to a public blockchain, where the validity of the computations can be verified by an auditor.

It also includes (unlike Bitcoin) a distribution protocol so that the "miners" aren't all solving the same problem in a redundant fashion, although I don't think the "network reduction" protocol is specified in the whitepaper.

This is probably the most relevant part to your question:

Code evaluated in our system is guaranteed not to leak any information unless a dishonest majority colludes (t ≥ n/2). This is true for the inputs, as well as any interim variables computed while the code is evaluated. An observant reader would notice that as a function is evaluated from inputs to outputs, the interim results generally become less descriptive and more aggregative.

For simple functions or functions involving very few inputs, this may not hold true, but since these functions are fast to compute - no additional steps are needed.

However, for computationally expensive functions, involving many lines of code and a large number of inputs, we can dynamically reduce the number computing nodes as we progress, instead of having a fixed n for the entire function evaluation process. Specifically, we design a feed-forward network (Figure 5) that propagates results from inputs to outputs. The original code is reorganized so that we process addition gates on the inputs first, followed by processing multiplication gates. The interim results are then secret-shared with N/c nodes, and the process is repeated recursively.

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#15

Earlier quoted context omitted.

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 i…

Ah thanks for the clarification. I know of IBM and Enigma's efforts in the realm of fully homomorphic encryption - do you know of any others?

Microsoft has a thing for Bioinformatics. The only info I know is "Manual for Using Homomorphic Encryption for Bioinformatics"[1]

[1] http://research.microsoft.com/apps/pubs/?id=258435

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#16
post #15

Earlier quoted context omitted.

Ah thanks for the clarification. I know of IBM and Enigma's efforts in the realm of fully homomorphic encryption - do you know of any others?

Microsoft has a thing for Bioinformatics. The only info I know is "Manual for Using Homomorphic Encryption for Bioinformatics"[1] [1] http://research.microsoft.com/apps/pubs/?id=258435

This is a really good read. Thanks for the heads up.

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#17
post #6

I never understood why homomorphic encryption is too slow to be used reliably today. Does some part of the computation need more power than todays computers can offer?

So here's an analogy that might help: Today, most RSA keys are 2048 bits. You can go up to 4096, but things start to get a little bit too slow for comfort. Double again and they get much slower.

Now imagine doing RSA with a 100k-200k bit key. That's the amount of slowdown FHE incurs.

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#18

I've wondered about another system, and perhaps someone here can point me in the right direction. Fully homomorphic encryption (FHE) has total control of two operations. Partially homomorphic encryption (PHE) has one operation. We can do PHE pretty well, and we're currently very very bad at doing FHE in reasonable amounts of time. In Craig Gentry's FHE schemes (and all current ones that I know of) are all based off o…

This is called Somewhat Homomorphic Encryption (or SHE).

Re: Things to Know about Databases that Leverage Partially Homomorphic Encryption

#20
post #6

I never understood why homomorphic encryption is too slow to be used reliably today. Does some part of the computation need more power than todays computers can offer?

They're not "that slow". They're too slow for big companies to use. But for a small product? Why not.
Post reply on HN