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

Google is making private AI practical with homomorphic encryption

blog.google

Post reply on HN
Print view View original

71–80 of 305 posts

Re: Google is making private AI practical with homomorphic encryption

#71

Post by Cider9986 »

bitpush wrote: post #47
Cider9986 wrote: post #22

This is the same Google that doesn't have e2ee on their password manager by default. Like WTF, it's a password manager.

F. Scott Fitzgerald's test of top-tier intelligence - > Holding two opposing views in the mind means accepting two contradictory ideas at the same time without needing to pick one side or rush to a simple answer I continue to use Apple products because they are top class even though everytime I think of Tim Cook in the Oval Office presenting the gold plaque to the current president, it makes me wanna puke. World isnt…

The reason I mentioned it is because Google seems to have a strange aversion to E2EE. Apple has added the option to iCloud but Google only has one consumer facing E2EE product, Google messages. A password manager is the most obviously important place to use it. I can't name another password manager that isn't.

Re: Google is making private AI practical with homomorphic encryption

#73

Post by rpedroso »

Cider9986 wrote: post #71
bitpush wrote: post #47

Earlier quoted context omitted.

F. Scott Fitzgerald's test of top-tier intelligence - > Holding two opposing views in the mind means accepting two contradictory ideas at the same time without needing to pick one side or rush to a simple answer I continue to use Apple products because they are top class even though everytime I think of Tim Cook in the Oval Office presenting the gold plaque to the current president, it makes me wanna puke. World isnt…

The reason I mentioned it is because Google seems to have a strange aversion to E2EE. Apple has added the option to iCloud but Google only has one consumer facing E2EE product, Google messages. A password manager is the most obviously important place to use it. I can't name another password manager that isn't.

How many customers are using Google Password Manager? How much revenue does it generate? What would it cost to add E2EE? How would it affect the UX? How much revenue would it generate? What projects would have to be de-prioritized to fund this work?

I agree, a password manager without E2EE is unusable in my eyes. However, I can also understand the institutional reasons this might be the case. I don't think it reflects an organizational aversion to E2EE.

Re: Google is making private AI practical with homomorphic encryption

#74

Post by mswphd »

bmenrigh wrote: post #31

Has FHE really progressed so far that it's now so efficient that doing computation on an encrypted prompt is feasible? I thought even basic operations like FHE addition were still thousands of times more complex. The only mention in the article I see is: > But while homomorphic encryption has a nontrivial cost overhead, it shifts the capability/privacy trade-off to a question of cost. And the cost of homomorphic encr…

addition is easy/essentially the same cost as standard (not really, because you have to compute mod p addition rather than mod 2^32, but ignoroing that it's roughly the same).

as a general rule multiplication is the difficult part.

it's hard to accurately quantify what "nontrivial" cost overheads are because they're very application dependent. for example, things that require encrypted control flow are very hard under FHE. so an encrypted hashmap sounds roughly unimplemnetable. but things that do not require encrypted control flow (e.g. many ML applications) are less bad. this can still be quite bad though. for example, relu is trivial in plaintext. it is hard homomorphically, because the trivial way to write it uses private control flow.

Re: Google is making private AI practical with homomorphic encryption

#75

Post by nullc »

Private AI is practical by running the model locally, every much more so than any homomorphic encryption scheme.

So essentially the headline sells this as work to keep your data private, but really it's work to keep the AI-- which was trained on your code and your writing-- private.

Re: Google is making private AI practical with homomorphic encryption

#76

Post by mswphd »

LoganDark wrote: post #9

One flaw with FHE is that it guarantees only that you need the key to see the inputs or outputs of the computation, but not necessarily that the computation is the one you want. For example, the computation could be adversarial for certain inputs, or an adversary could insert their own computation first (or last).

note that this is even true for an honest server. Roughly, FHE computations often require certain bounds on the (encrypted) messages for things like tuning polynomial approximation domains etc. If your messages are out of distribution for the tuned polynomial approximations you'll get back garbage as as result.

Re: Google is making private AI practical with homomorphic encryption

#77

Post by ameliaquining »

rpedroso wrote: post #73
Cider9986 wrote: post #71

Earlier quoted context omitted.

The reason I mentioned it is because Google seems to have a strange aversion to E2EE. Apple has added the option to iCloud but Google only has one consumer facing E2EE product, Google messages. A password manager is the most obviously important place to use it. I can't name another password manager that isn't.

How many customers are using Google Password Manager? How much revenue does it generate? What would it cost to add E2EE? How would it affect the UX? How much revenue would it generate? What projects would have to be de-prioritized to fund this work? I agree, a password manager without E2EE is unusable in my eyes. However, I can also understand the institutional reasons this might be the case. I don't think it reflect…

Google Password Manager does in fact have E2EE. It's quite straightforward to enable. Your interlocutor is complaining that it's not the default, which I'm quite sure is a deliberate decision made on the grounds that the typical user, the one for whom the default matters because they won't tweak their settings, needs workable account recovery more than they need defense against the specific kinds of security threats that make E2EE relevant.

Re: Google is making private AI practical with homomorphic encryption

#78

Post by drblast »

I did some amount of research into the feasibility of PHE and FHE about 20 years ago, and my conclusion at the time was that the space overhead of the encrypted output was a massive bottleneck, which meant that while it was potentially useful in a small number of niche cases it wasn't ever going to be practical for general-purpose computations without a major breakthrough.

The gist was I could do an encrypted (int)x + (int)y = (int)z computation, I could encrypt the inputs and then get a result back that was correct, secure, and decryptable, but was like 1MB in size.

So, for someone whose knowledge is 20 years outdated and is about Pallier crypto, has that major breakthrough happened?

Re: Google is making private AI practical with homomorphic encryption

#79

Post by mswphd »

filup wrote: post #66
drdeca wrote: post #61

Earlier quoted context omitted.

Here’s a very simple one-time-pad style construction for homeomorphic (but not fully homeomorphic) encryption. Suppose the plaintext, ciphertext, and key, are each a natural number modulo 5. The key is selected uniformly at random. The ciphertext is obtained by adding the key to the plaintext (and as a result is also uniform random). Then the ciphertext is sent to the server. The server only has the ciphertext, which…

What does that have to do with incpa? I send this server a question encrypted. It stays encrypted yet the server distinguished my ciphertext enough to produce a coherent reply. That means there was enough information in the ciphertext for the server to perform the inference, even if it was obscured to where it looks indistinguishable, it apparently wasn't. This doesn't remove trust from the equation, it puts the trus…

the server doesn't do what you say. Roughly, the server has a fixed circuit C they run on the ciphertext. They run this same circuit on any ciphertext. They give you back the result. the fact that the result, when decrypted, gives the desired answer isn't something the server can verify though.

Think about a very simple setting, say a database lookup. I send an index `i` in a database I want to lookup. The server sends back DB[i] or whatever.

In the clear, the server can immediately fetch the correct row. Under FHE, the server does a full scan of the database, and (roughly) for each row will do something like DB[i] * (encrypted selector variable that is 0 or 1 depending on if it is the row you want).

This is actually a baby version of FHE known as "Private Information Retrieval". For it, you (roughly) can design an encryption scheme that supports linear function evaluation. For example, a ciphertext Enc(m) can be paired with a matrix A to produce Enc(Am). You can then encrypt the ith basis vector m := e_i, and view the database as a matrix DB, to get DB * Enc(e_i) = Enc(DB*e_i) = Enc(DB_i). This works, and can be implemented in ~1k LoC, e.g. it is not particularly complicated to practically instantiate (though this basic sketch has some performance issues).

Post reply on HN