Live data from Hacker News

The Rise of Fully Homomorphic Encryption

queue.acm.org

31–40 of 132 posts

Re: The Rise of Fully Homomorphic Encryption

#31
post #13
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.

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

Are the used operations that exotic that special hardware can achieve massive speedups?

Re: The Rise of Fully Homomorphic Encryption

#32
post #8

I am still amazed by the amount of people that still mix security and encryption in-use with privacy. And truth is the whole privacy/security industry is doing nothing to change that. Take this for example "Valuable insights through AI (artificial intelligence), big data, and analytics can be extracted from data—even from multiple and different sources—all without exposing the data, secret decryption keys, or, if nee…

> FHE gives you NO guarantee about the code that is running on the encrypted data.

You mean in order to validate the data is authentic? Otherwise the code running on the data is irrelevant, as it can't access the data itself (and thus preserves the before-mentioned privacy).

Re: The Rise of Fully Homomorphic Encryption

#33
post #23

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…

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 "fully" part of FHE.

Edit: Okay so I might now understand you refer to a scenario where the user submits their data in homomorphic form to the cloud, where an AI model is trained on it. The AI model parameters are later returned to the user's device, which then decrypts them with the user's key and executes a classical model with those parameters, and then resubmits the user's data after processing with the said ML model (unencrypted) back to the cloud. It's true the user usually has no way of auditing the code / model that runs on their device, but isn't that rather easily alleviated by opening up the APIs for communicating with the cloud part of the service?

Re: The Rise of Fully Homomorphic Encryption

#34
post #28
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…

Wouldn't doing the same thing without FHE also result in the same problem?

Yeah, and many more. But I've seen multiple people argue that using FHE will magically solve all their privacy problems and its far from true. FHE (and similar technologies) solve a piece of that "puzzle" and most providers somehow gloss it over.

Re: The Rise of Fully Homomorphic Encryption

#35
post #28
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…

Wouldn't doing the same thing without FHE also result in the same problem?

[deleted]

Re: The Rise of Fully Homomorphic Encryption

#36
post #9
post #6

Earlier quoted context omitted.

I don't think it was just a press release, the linked PDF had a nice overview of how we got here and some advances in the last decade. Decent little review type article with some hyperbole! I think the title maybe a little too optimistic / vague by saying it's "near" without indicating what else is needed to get there / when it might happen ;).

The byline is "Mache Creeger, Cornami Inc.". Cornami is a company that sells FHE accelerator chips. Many of the talking points seem to be very similar to the Cornami website, such as the over-emphasis on post quantum crypto despite being very irrelavent in context.

Somehow missed it, read before caffeine, good call

Re: The Rise of Fully Homomorphic Encryption

#37
post #16
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.

Wait, how would hardware be possibly leaky? The encryption/decryption can leak data, sure, but that's unrelated to FHE. If your hardware can leak info about the plaintext on the side processing the encrypted data, then you could do the same in software anyway, and the FHE scheme itself is clearly broken...

Re: The Rise of Fully Homomorphic Encryption

#38

> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at commercially viable speeds. At the moment, Cornami is the only commercial chip company to announce a forthcoming product that can meet and exceed that performance level. Is there any comparison performance benchmark for these Cornami chips on real world algorit…

If no one answers here, might try on the FHE.org discord, loads of researchers there who probably wrote a paper on exactly that.

Re: The Rise of Fully Homomorphic Encryption

#39
post #24

If you want to see a practical use case of Fully Homomorphic Encryption (FHE) with Machine Learning. > https://www.zama.ai/post/titanic-competition-with-privacy-pr... Its main ambition is to show that FHE can be used for protecting data when using a Machine Learning model to predict outcomes without degrading its performance. Disclaimer: I'm working at Zama (cited in the article posted).

Or this! https://pubmed.ncbi.nlm.nih.gov/30641309/

There is also use cases listed here:

> https://fhe.org/fhe-use-cases

Also anyone can contribute and add resources as it lives on an open source github repo.

Re: The Rise of Fully Homomorphic Encryption

#40
post #8

I am still amazed by the amount of people that still mix security and encryption in-use with privacy. And truth is the whole privacy/security industry is doing nothing to change that. Take this for example "Valuable insights through AI (artificial intelligence), big data, and analytics can be extracted from data—even from multiple and different sources—all without exposing the data, secret decryption keys, or, if nee…

> FHE gives you NO guarantee about the code that is running on the encrypted data. You mean in order to validate the data is authentic? Otherwise the code running on the data is irrelevant, as it can't access the data itself (and thus preserves the before-mentioned privacy).

The code decrypts the data at some point (for use, presentation, etc). If the code is crappy, insecure, etc. then the data will be exposed, and the data being encrypted wont help at all...
Post reply on HN