Live data from Hacker News

Fully homomorphic encryption and the dawn of a private internet

bozmen.io

171–180 of 202 posts

Re: Fully homomorphic encryption and the dawn of a private internet

#171

Earlier quoted context omitted.

Even without bootstrapping FHE will never be as fast as plaintext computation: the ciphertext is about three orders of magnitude much larger than the plaintext data it encrypts, which means you have to have more memory bandwidth and more compute. You can’t bridge this gap.

That actually sounds pretty reasonable and feels almost standard at this point? To pick one out of a dozen possible examples: I regularly read 500 word news articles from 8mb web pages with autoplaying videos, analytics beacons, and JS sludge. That’s about 3 orders of magnitude for data and 4-5 orders of magnitude for compute.

Sure, but downloading a lot of data is not the same as compute on this data. With web you simply download the data, and pass the pointers to this data around. With FHE, you have to compute on extremely large cipher texts, using every byte of them. FHE is roughly 1000x more data to process and it takes about 1000x more time.

Re: Fully homomorphic encryption and the dawn of a private internet

#172

Earlier quoted context omitted.

I am confused: you can implement LLM learning with FHE. It’s a different problem than learning on encrypted data.

I didn't mean to suggest otherwise! That's why I also linked the CryptoNets paper - to show that you're transforming the inference to happen inside an FHE context, not trying to learn encrypted data

Yes, you can do Cryptonets. What I’m saying is that you don’t have to do cryptonets, you can simply use FHE to train the network in fully encrypted manner: both the network and the data are FHE-encrypted, so the training itself is an FHE application. It would be insanely slow and I doubt it can be done today even for “small” LLMs due to high overheads of FHE.

Re: Fully homomorphic encryption and the dawn of a private internet

#173
post #137
post #65

Earlier quoted context omitted.

From what I understand, only the sensitive data needs to be encrypted (e.g. your bank transactions). It is still possible to use public unencryped data in the computation, as the function you want to compute doesn't have to be encrypted.

In a world where Target can figure out a women is pregnant before she knows herself due to her shopping habits, the line that separates sensitive data is pretty ambiguous.

Small correction: according to that story, it's before her father knows, not herself.

Re: Fully homomorphic encryption and the dawn of a private internet

#174
post #166

Earlier quoted context omitted.

Technically, there are rate-1 homomorphic encryption schemes, where ‘rate’ refers to the size ratio between the plaintext and the ciphertext. They’re not super practical, so your general point stands.

Oh, interesting. Can you point to a paper about one?

This is a good one: https://eprint.iacr.org/2019/720.pdf

Re: Fully homomorphic encryption and the dawn of a private internet

#176

Earlier quoted context omitted.

How does FHE help with someone executing a process on the server that affects the latency of your trading algo? eg by sucking up the CPU resources you need to do FHE. How does FHE help with the fact that regulators generally want single-tenant shared-nothing for registered broker/dealers? Have you tried to explain a technical mitigation like FHE to a financial regulator? I have, there are 2 standard responses: 1) (in…

why would latency matter if the trading we're talking about isn't high-speed?

I give a concrete example in the GP post but the reason is that the high-speed people can take advantage of you in certain circumstances if you don’t have extremely accurate timing of things like order placement.

As another example, imagine you are placing an options order on one exchange and a cash hedge on another exchange (eg for a delta hedge). If someone sees one half of your order and has faster execution than you, they can trade ahead of you on the other leg of your trade, which increases your execution cost. This is even more important if you’re doing something like an index options trade on one side and the cash basket (all the stocks in the index) on the hedge side.

The fix for this is to use hi-res exchange timestamps (which the exchange gives you on executed trades) to tune a delay on one leg of your execution so both halves hit at precisely the same time. This ensures that HFTs can’t derive an information advantage from seeing one half of your trade before you place the other half of the order.

Re: Fully homomorphic encryption and the dawn of a private internet

#177
post #120

If I understand correctly companies like OpenAI could run LLMs without having access to the users new inputs. It seems to me new users data are really useful for further training of the models. Can they still train the models over encrypted data? If this new data is not usable, why would the companies still want it? Let's assume they can train the LLMs over encrypted data, what if a large number of users inject some…

> Can they still train the models over encrypted data?

Yes but then the model becomes encrypted.

IMO ML training is not a realistic application for FHE, but things like federated training would be the way to do that privately enough.

Re: Fully homomorphic encryption and the dawn of a private internet

#178
post #136

FHE might allow arbitrary computation, but I use most services because they have some data I want to use: their search index, their knowledge, their database of chemicals, my bank account transactions, whatever. So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it. The other point is incentives: outside of some…

You're right about incentives, but wrong about the first part. Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.

> Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.

So that basically means that if a company has data that my program might want to use, the entirety of that data needs to be loaded into my program. Not quite feasible for something like the Google search index, which (afaik) doesn't even fit onto a single machine.

Also, while Google is fine with us doing searches, making the whole search index available to a homomorphic encrypted program is probably a quite different beast.

Re: Fully homomorphic encryption and the dawn of a private internet

#179
post #136

FHE might allow arbitrary computation, but I use most services because they have some data I want to use: their search index, their knowledge, their database of chemicals, my bank account transactions, whatever. So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it. The other point is incentives: outside of some…

You're right about incentives, but wrong about the first part. Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.

Which ultimately results in gigabytes of per-client-encrypted data needing to be downloaded, and regenerated and redownloaded every time the index is updated.

Re: Fully homomorphic encryption and the dawn of a private internet

#180
post #136

Earlier quoted context omitted.

You're right about incentives, but wrong about the first part. Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database.

> Private lookups of a plaintext database are possible and have been for a while now (5+ years?). The problem is it often requires some nontrivial preprocessing of the plaintext database, or in the worst case a linear scan of the entire database. So that basically means that if a company has data that my program might want to use, the entirety of that data needs to be loaded into my program. Not quite feasible for so…

You can process the data such that only a structured lookup table is shared with the client. That data structure is massive.

The use case isn't really “search Google without them knowing my query”, it’s search my own data without them knowing my data”. Which limits the practically applicable scope considerably.

Post reply on HN