RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
59% Positive
Analyzed from 3823 words in the discussion.
Trending Topics
#google#fhe#encryption#data#private#without#ciphertext#don#more#https
Discussion (101 Comments)Read Original on HackerNews
But yeah, for hot path traffic it's probably going to be swamped by the input data rate. But I expected identity tables and cached lookup data will need to be a core component so duplicate checks is avoided in every way available.
update: also see [2] for some primitive unsigned 64-bit integer operation benchmarks with the TFHE-rs library (winner in the sorting performance comparison of [1]). Equality at 80ms, addition and subtraction at 100ms, division at 8 seconds, etc.
[1] https://eprint.iacr.org/2026/1495.pdf Oblivious Sorting under Fully Homomorphic Encryption: A Comprehensive Survey and Performance Analysis, Omar Ahmed and Rostin Shokri and Nektarios Georgios Tsoutsos, 2026
[2] https://docs.zama.org/tfhe-rs/tfhe-rs/1.0/get-started/benchm...
Project intro talk from 2023: https://www.youtube.com/watch?v=kqDFdKUTNA4
"We evaluate HE-LRM on UCI (health prediction) and Criteo (click prediction), achieving inference latencies of 24 seconds on UCI and 228 to 489 seconds, respectively, on a single-threaded CPU."
There don't seem to be any direct comparisons available, probably because nobody else has any reason to limit themselves to one single-threaded CPU with normal techniques, but for reference the AI seems to expect that normal times for conventional setups are in the milliseconds range, fairly comfortably, even on CPU. I didn't find a clean primary source to link to for this claim, but clicking through various things that don't cleanly state the situation it did seem plausible. So we seem to still be in the range of single-digit orders of magnitude slower, possibly as much as 5 or 6, which is to say, we're still talking the range where we need to take the log of the difference to get sensible numbers, we're not using percentages.
(To run it yourself, I basically just fed the URL from the HN link, mentioned that FHE is known to be slow, and asked if anything linked in the blog post gave concrete times.)
That said, there is a lot of ongoing work on GPU acceleration. Cf. the recent FHE-based CIFAR demo that runs in 200ms: https://sofar.belfortlabs.cloud/
Still maybe 1000x slower than cleartext, but progress!
Then there’s a second tier of things that just make those wheels turn and if they do or don’t make ads revenue is nominally immaterial.
The teams doing this stuff at Google are purely for show, none of this makes it into any real products.
There’s the narrow exception of stuff like gboard, that does use privacy preserving ML/fed learning, but this stuff isn’t in the same zone.
I find it a bit embarrassing when Google publishes this stuff to be honest.
FHE effectively removes the primary regulatory barrier keeping enterprise customers off the cloud.
and now this.
Part of changing the world involves imagining a changed-world.
Edit to clarify my prior point: some of the technology makes it into the product, but the putative data protections do not.
Why?
Because there is always a work around, and ads legal will approve it every time.
It narrows the 10^3 - 10^6 penalty to 10x - 100x.
I'm glad people fund things that are only of interest to nerds but this will never be useful.
Cost-wise the only viable private compute is local compute. It's more expensive than cloud, but true private compute in the cloud is definitely pricier.
The most private AI is the one running on my own hardware, not in some giant data center.
Using regular encryption and secure enclaves, there are already providers that are roughly 2x the cost of normal providers. For example, https://tinfoil.sh/
> Fourth, there is a bandwidth concern. FHE encryption schemes generally increase the size of the data being encrypted, and the user must send the server a special set of encryption keys to enable the computation, which are relatively large as well. The special keys need only be generated and sent once and can be used for all future computations, but they can easily be gigabytes in size. In one example FHE scheme with lightweight keys, a ciphertext encrypting a single integer is on the order of 25 KB, and the special keys are about 0.5 GB. In others, 16,000 or more integers are packed into a single ciphertext of similar size, but the keys can be 10s of GiBs.
Sibling comment estimates lower bounds of current research at minimun 10^6 overhead which sounds more realistic.
> 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 black or white.
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.
You can separate Cook is a garbage person from the fact that he makes good stuff which quite frankly not an accomplishment insofar as it's the same trade-off virtually everyone makes. They aren't even contradictory you are simply weighing a trade off in moral outrage vs personal gain.
Most people who use Google trust them. And if you do not trust them then why are you using their password manager? You see? Hence why they do not bother.
Of course one might read this and say, multi device e2ee is possible! Sure, but can you allow for recovery when people inevitably lose their recovery codes at scale? If you really care about this it is not necessary to go with Google.
I stand by my original comment:
The average user does not want it.
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?
All of the proofs of privacy rely on us getting the math right. All of the privacy from unplugging your internet cable is there by default.
> 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 encryption is rapidly decreasing.
Which doesn't spell out exactly hon "nontrivial" the cost overhead still is.
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.
There are some instances of hand-built cryptographic protocols used in production at Google that use FHE in small doses (e.g., computing a single dot product as part of an interactive protocol), so the big question is whether having a general-purpose tool will expand the feasibility of applying these to other, maybe less critical projects that still want some privacy guarantees but can't afford to hire cryptographers.
Reality: our computers will be used as distributed AI calculators
It's very useful for things like healthcare data for example but also for products like "home assistants", and it's one of the use cases that the team hiring internally was giving in their job req. I tried to apply too but didn't get it unfortunately, this was a very interesting product to work on imho, congrats to whoever got my job :)
I don't understand why we need to bring LGBTQ+ into everything
The basic idea of of the project is to remove the need for trust.
I'd expect this to be something like the Google Ad ID: technically separated from what Google considers personal information, but trivially easy to tie back to an individual person and to other information about that person.
They're continually breaking trust by illegally scraping up the internet to feed to their plagiarism machine, which they are now asking us to trust with more data. It's not a compelling arguement.
I think the most immediately useful is checking if a username/password hash appears in a leaked database without revealing which account or password hash is being checked.
If you don’t agree with this model, I’m afraid modern cryptography doesn’t have anything to offer.
I think GP is trying to say something along those lines. Not that encryption isn't trustworthy, but that even with homomorphic encryption you still give up autonomy.
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.
- Unstarve the GPU and RAM consumer market.
- Let enthusiasts and volunteers quickly ramp up local AI.
- Reap the results that the community will most certainly achieve.
Don't repeat Microsoft's earlier mistakes. It flourished when it embraced the community and open source. If it had made that move earlier, it would have been unstoppable.
Yes, if you can control the entire market that's probably awesome. But it's also full of nonsense risks.
I want to read a whitepaper but all I can find is the tl;dw conference presentation
FHE is traditionally horrifically slow, so it's hard to imagine running anything beyond toy models with it. They list some applications on the original article page, but (presumably) they must be dramatically stripped down in order to run within any reasonable time budget. This is not going to run anything like a Sol/Opus any time soon.
[1]: https://heir.dev/
[0] https://0xparc.org/blog/programmable-cryptography-1
Which is to say, I believe that google is strongly implying the falsehood of "no one at Google can read your stuff."
So I take offense to the term FHE. It's a oxymoron.
The whole thing immidiatly stands out as a sham to build trust where it's gone.
Consider two integers M1 and M2.
Consider RSA with private key (E), public key (D), and public modulus (N).
Encrypt(M, E, N) = mod(pow(M, E), N).
Decrypt(C, D, N) = mod(pow(C, D), N).
mod(Encrypt(M1, E, N) * Encrypt(M2, E, N), N) = mod(Encrypt(M1 * M2, E, N), N).
So, for all RSA encryption, multiplying the ciphertexts results in a ciphertext that is the multiple of the plaintexts. However, unless you can break RSA, you can not determine what numbers you multiplied or what the final multiplied number is.
This is not a fully homomorphic system as it only allows multiplication, but it is a existence proof that you can do operations on ciphertext that apply to the plaintext without being able to recover the plaintext unless you can break the encryption directly.
If you believe the underlying cryptographic hardness assumption of LWE/RLWE/etc, then yes Google cannot see any of the input or output of the model.
It seems like you strongly believe otherwise, but I suspect you don’t have a good reason to, and just find it unbelievable.
Do you think you can distinguish it from noise, if given an implementation and the information an adversary would have access to?
Of course, you not being able to wouldn’t demonstrate that noöne can. But, it seems like if you had a good reason to believe that an adversary can, that would suggest you might have some idea of how they could do so. And, if you do have such an idea, then, if that idea works, it would be important for others to know, and if it doesn’t, it would presumably benefit your understanding to see why it doesn’t.
I don’t see why you conclude that FHE couldn’t be close to as secure as that. (Like, not information theoretically, but with computationally bounded adversaries.)
In the secret sharing multi-party computation schemes, the individual shares of the secret are random and have no information about the plaintext.
I see no reason that FHE can’t have ciphertexts indistinguishable from noise.
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 is uniform random. The server then adds some integer mod 5 to the ciphertext, producing a new ciphertext, and sends it back to the user. The user then subtracts their key from the new ciphertext to obtain the new plaintext, which is their original plaintext plus the number the server added.
At no point in this process did the server learn anything about the user’s plaintext.
This is clearly secure.
It is also useless, because just adding a number isn’t a useful thing for a server to do (they may as well just send the user the number and let them add it themselves), but that’s because it is a toy example.
I suppose if mind uploading were possible, then under FHE it would in principle be possible to take the ciphertext and run the computation of “this mind upload of this person reads the data and provides some output”, and then presumably that uploaded person would have the experience of seeing the plaintext? But it wouldn’t be possible to get any information about the plaintext without the key (or enough brute force to find the key, but that’s why we use big enough keys to make this infeasible).
> user-data can be protected from data breaches, but then the service provider cannot provide features that depend on the data, such as spam or virus detection
I think they forgot "or advertising" at the end.
I don't trust Google. I would much prefer to use on-prem or - at most - one of the secure-enclave providers like Tinfoil[1] or Private Mode[2]
[1] https://tinfoil.sh/ [2] https://www.privatemode.ai/
[1] https://sgx.fail/