Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise of Fully Homomorphic Encryption

queue.acm.org

Post reply on HN
Print view View original

61–70 of 132 posts

Re: The Rise of Fully Homomorphic Encryption

#61

Post by v4dok »

swores wrote: post #46
v4dok wrote: post #42

Earlier quoted context omitted.

You are right. It is related to privacy, but its not the whole story. Thats what I am trying to say. Running FHE will not magically solve the "data leakage" problem of your AI models, and I believe that the people/companies who don't make that distinction are misleading.

This isn't an area I know much about so I'll stay out of the main conversation, but would like to point out that considering you wrote "completely unrelated to privacy" in your first comment, following it with "It is related to privacy, but its not the whole story. Thats what I am trying to say." makes me unsure what your point is or if you actually mean or understand it. Sorry for being blunt.

You are right to be blunt. I didn't want to define the separation of input and output privacy in a comment. In retrospect maybe I should have but I can't edit anymore. It is however common HN practice to pick out the words that suit someone and construct an very specific argument based on these words, often missing the spirit of the comment.

Yes, when I wrote the comment I had in mind "output" privacy while FHE is dealing with "input" privacy. It is related to privacy, but not in the way most people think about it.

If you go to a random person and ask them about privacy they will not think about the threat model of a cloud provider leaking their data, but they will think of the thread model of a pharma company knowing exactly what drug they bought and when. That notion of privacy is not covered by FHE(alone). And even the first notion of privacy is covered only if the FHE program has a way to attest itself so you know that what you expect to run is indeed what is running.

Re: The Rise of Fully Homomorphic Encryption

#62

Post by johnbender »

awesomeMilou wrote: post #59

Great write up on the state of the field, but when I checked last, the current problem is performance. I didn't see much on that in the article. A few years ago there were papers on evaluating simple logic circuits in an FHE context and it took 2h hours for what was basicially 5-6 NOR gates.

Fwiw we have at least some reason to hope in this general context that between clever systems work and tightening theoretical bounds via additional assumptions and clever reasoning we might get to practical implementations for some applications.

As (maybe weak) evidence the progress on practical implementations of PCPs/SNARGs

https://dl.acm.org/doi/pdf/10.1145/2641562

Re: The Rise of Fully Homomorphic Encryption

#63

Post by Ar-Curunir »

v4dok wrote: post #23
vesinisa wrote: post #21

Earlier quoted context omitted.

The way I have understood FHE is that any algorithm that would operate on the data would, by definition, be unable to produce any result that was intelligible to anyone except the person holding the original key. At no point during the execution of an FHE algorithm is the data decrypted. The amazing thing is exactly that the code running on the data does not understand the data it is consuming nor the data that it is…

Thats true. But it will still produce some data, and that data will be viewed by someone eventually who owns the key to decrypt it. FHE tells you nothing about what this product should be. It could as well be a full copy of the original data. For example: I run an ML model using FHE on some data I shouldn't have access to in plaintext. The expected outcome of this workflow is a trained ML model on that data. FHE tell…

FHE only reveals information to the person who has the keys for it, not to arbitrary people in the middle. So if you had access to the keys for the input data, then you have access to the keys for the output data.

Re: The Rise of Fully Homomorphic Encryption

#64

Post by Ar-Curunir »

v4dok wrote: post #16
api wrote: post #13

Earlier quoted context omitted.

To make it fast I think we'll need custom silicon. I wonder how many stealth startups exist working on FHE chips?

I wouldn't hold my breath on this. Reducing it by x40 AND making sure that hardware is not leaky.

The hardware is not relevant if it's simply being used as an accelerator. FHE reveals no information about the underlying data, so the privacy leakage is the same, no matter if you're running the FHE code on ENIAC or on a modern supercomputer.

Re: The Rise of Fully Homomorphic Encryption

#65

Post by wazoox »

I've just watched a presentation about Cosmian (https://cosmian.com/) and their solution boasts using FHE, at a significant price though: computations and queries are about 1000 slower than on unencrypted data according to their CTO. I was quite impressed that it even works at all, though :)

Re: The Rise of Fully Homomorphic Encryption

#66

Post by Ar-Curunir »

jgaa wrote: post #48

> FHE (fully homomorphic encryption) provides quantum-secure computing on encrypted data Today, if I understand it correctly, that means the encryption can't be broken on a computer with resources < whatever is required to calculate the square root of 16 ;)

Something is obviously not quantum-secure if it's broken on a classical computer. FHE schemes in particular are instantiated with schemes that are believed to offer both classical security and post-quantum security.

Re: The Rise of Fully Homomorphic Encryption

#68

Post by spiralprivacy »

gumby wrote: post #7

This article skips over the elephant in the room, via a couple of casual references to “performance”. You did some experiments with HE in 2019 and it involves orders of magnitude slowdown — thousands of times slower than regular computation. I don’t see this speeding up either.

General purpose FHE is indeed quite slow. But by focusing on specific subproblems, like private information retrieval (get rows from a database without revealing anything about your queries), it is possible to achieve acceptable performance. There's been lots of recent improvement here: see papers [0] and [1] from this year, which both achieve GB/s throughput for private database lookups.

And for a more tangible demo of FHE, we built open-source webapps that let you privately browse Wikipedia [2] or look up live Bitcoin address balances [3]. This is FHE running in the browser today, returning results in seconds.

[0] https://eprint.iacr.org/2022/368 (disclaimer: this is our paper)

[1] https://eprint.iacr.org/2022/949

[2] https://spiralwiki.com

[3] https://btc.usespiral.com

Re: The Rise of Fully Homomorphic Encryption

#69

Post by krastanov »

bsaul wrote: post #43

Wait, has any quantum computers performed a real computation faster than a normal computer one yet ?

No "useful" computation yet, but "yes", quantum hardware has been able to sample from some programmable convoluted contrived probability distributions from which classical computer can not sample efficiently. But that is irrelevant here because:

More importantly, FHE and post-quantum crypto are two completely orthogonal topics.

Homomorphic is the property that (classical or quantum) computation can be performed on the encrypted (classical or quantum) data without decrypting it. Homomorphic encryption with classical data on classical computers is rather difficult and fascinating. Homomorphic encryption on quantum computers is trivially easy (if you already have a standard scalable quantum computer, which do not exist yet).

"Post-quantum" is the property that a classical computer can efficiently perform encryption that can not be broken even by a quantum computer.

Re: The Rise of Fully Homomorphic Encryption

#70

Post by v4dok »

vesinisa wrote: post #33
v4dok wrote: post #23

Earlier quoted context omitted.

Thats true. But it will still produce some data, and that data will be viewed by someone eventually who owns the key to decrypt it. FHE tells you nothing about what this product should be. It could as well be a full copy of the original data. For example: I run an ML model using FHE on some data I shouldn't have access to in plaintext. The expected outcome of this workflow is a trained ML model on that data. FHE tell…

Sorry but I still fail to see how that would be a problem, since the output of the program (e.g. the ML model parameters) would themselves not be intelligible to you. To make _any_ (non-cryptanalytical) inference on the plaintext of the homomorphically encrypted data _necessarily_ requires that the attacker at some points can access or execute some classical code on the plaintext. This would obviously violate the "fu…

Close. The first part is fair.

A more real-life example.

I am a pharma company and I want to execute a query on some hospital data. The hospital doesn't want to give me the data in plaintext but they are fine with me getting some aggregate insights from their data that are not PII.

Now lets assume I decide to do that using FHE. I can now compute my query on the encrypted hospital data and I never see the plaintext data.

What do we "win" in this scenario? We can do this computation wherever we want because no matter where the computation is done, the data will be encrypted, so no risk for the infra provider to see that data.

What we don't "automatically win" in this scenario? 1. Guarantees that indeed I am running an SQL query on that data and not something else along with it -> That is only possible to guarantee if the FHE software is properly audited (same with any software tbh, but easier with FHE and similar techs because of the integrity guarantees due to encryption). 2. Guarantees that the SQL query I made will not leak patient data in the end (through linking additional data, or diff attacks) (same with any other SQL query)

People who are deep into these technologies will say "yes of course" thats not an FHE problem. And that is true. But every FHE vendor I've seen blur that difference by not specifying what kind of attacks they protect against when they talk about "protecting privacy".

Heck, most of them they don't even talk about the attestation process and how their clients can make sure that they can trust the software running in encrypted form. Yes, these hold true for all software, but the point (for me) of encryption in-use is to make sure we hold software to a higher trust standard than today, not just replace a trusted party with another one.

Post reply on HN