Rendered at 21:01:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sabretooth1405 4 hours ago [-]
My master's thesis is on a topic in this field (Privacy Preserving ML) and from my understanding HE and other techniques have very high overheads(~10^3) on inference tasks and thus aren't very commercially viable.
dhx 3 hours ago [-]
To throw out some real and up-to-date numbers from [1] for FHE at "128-bit security level", to sort 8x 8-bit unsigned integers on the most ordinary of desktop PCs, wait 3 seconds for the result. Want to sort 32x 8-bit unsigned integers instead? Come back 34 seconds later for the result.
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
The article conspicuously fails to go into much detail about that. I poked around with an AI a bit (to rapidly cover all the linked pages) and it seems the best numbers we can get are from this arxiv paper: https://arxiv.org/html/2506.18150v4 Which says:
"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.)
j2kun 2 hours ago [-]
The linked repository has demos you can run (though you have to install bazel), and some of the smaller models run inference in about a second, while the larger ones take minutes.
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!
Fordec 53 minutes ago [-]
The primary path to speed ups appear to be in custom ASICs by startups like Niobium. Combined with the recent Taalas acquisition by AMD, I think I see where this is going.
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.
bevekspldnw 3 hours ago [-]
Commercially viable for Google boils down to can they attribute ads behaviors to it or not.
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.
asdfman123 44 minutes ago [-]
GCP exists, friend. Right now industries are locked out of AI tools due to privacy laws.
If Google Cloud can offer FHE-powered tools, a hospital can run Google’s AI diagnostic models on encrypted brain scans without violating privacy laws.
FHE effectively removes the primary regulatory barrier keeping enterprise customers off the cloud.
PunchyHamster 15 minutes ago [-]
At that kind of amount of waste putting 2U server with some GPUs in hospital would be cheaper
asdfman123 6 minutes ago [-]
Making things 10x more expensive to reduce legal liability is what hospitals are all about
bitpush 50 minutes ago [-]
Autonomous driving was all show until Waymo happened
AI research was all show until transformers happened.
Quantum research is all show until ..
and now this.
Part of changing the world involves imagining a changed-world.
luckydata 3 hours ago [-]
You are very wrong about all of this btw.
bevekspldnw 2 hours ago [-]
You literally don’t know who I am or the roles I had. So unless you can tell me how many steps you were from Kent Walker and what you worked on I’m gonna bet a hell of a lot I know more than you.
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.
bitpush 49 minutes ago [-]
> You literally don’t know who I am or the roles I had.
I'm now curious. Who are you?
luckydata 35 minutes ago [-]
and you don't know who I am. I might have been closer to that work than you would know.
3 hours ago [-]
abetusk 3 hours ago [-]
1000x slowdown is bad but not a complete deal breaker. Do you have a sense of what a reasonable achievable factor is? Do you have sense for how long before we get to that achievable factor?
jacquesm 51 minutes ago [-]
It's a ridiculous waste of energy, just use local compute.
u1hcw9nx 3 hours ago [-]
That's the reason for HEIR like optimization and parameter selection.
It narrows the 10^3 - 10^6 penalty to 10x - 100x.
michaelmrose 1 hours ago [-]
Which seems massively worse than a real local device in fact 2x is probably untenable to the point of uselessness because actually privacy sensitive matters need actual privacy that can't be defeated by your government telling Google to serve you compromised js and spy on you anyway and most people don't give 2 shits about privacy so they won't pay 10% more let alone 2x.
I'm glad people fund things that are only of interest to nerds but this will never be useful.
dietr1ch 3 hours ago [-]
Exactly my concern, and worse overhead that what I recalled.
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.
clayhacks 3 hours ago [-]
Do you think that’s like a fundamental limit or something that will improve with time and new algorithms?
bhu8 30 minutes ago [-]
I wouldn't be very bullish.
Homomorphic encryption got significantly efficient with the first few iterations, but I don't really see the necessary orders of magnitude savings coming soon. You could reduce this by some partial encryption schemes (e.g., for LLMs you need a handful of basic operations) but a better alternative already exists: multi-party computation.
Source: I did research in this area in the past.
meindnoch 2 hours ago [-]
Great, private AI, at the cost of >1000x the resource usage. Because apparently AI companies weren't already using quite enough energy to cook the planet.
The most private AI is the one running on my own hardware, not in some giant data center.
Eueudhsbsj32 1 hours ago [-]
Aren't there already much more efficient ways to make inference private?
Using regular encryption and secure enclaves, there are already providers that are roughly 2x the cost of normal providers. For example, https://tinfoil.sh/
siddthesquid 41 minutes ago [-]
If I used regular encryption to send my credit card information to an AI with fraud detection, the provider still needs to decrypt that data on their side at some point before it goes into the AI.
Using this other encryption, the provider has neither need nor capability to decrypt it on their end, so the user gets extra security.
llleeeoooh 56 seconds ago [-]
this is not entirely true, I think. secure enclaves can provide guarantee such that even the host machine cannot inspect the contents within the VM. so even though the AI model itself needs to see plaintext, all is happening in the enclave which the provider cannot see.
the main difference is where the guarantee comes from. for FHE, it comes from math, which we trust. for secure enclave, the guarantee comes from Intel/AMD's promise that their hardware is bugless/backdoorless, and that your adversary cannot directly inspect bits in the hardware
froh 1 hours ago [-]
where does this factor "1000x" come from? I have doubts.
> 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.
pamcake 52 minutes ago [-]
I'm still a bit skeptic - 1000x sounds overly optimistic and only looking at encryption transformation without any operation is already at least 10000x with scheme mentioned in that quote.
Sibling comment estimates lower bounds of current research at minimun 10^6 overhead which sounds more realistic.
pamcake 41 minutes ago [-]
Most likely from above in thread.
There is no reason to believe it should be lower than that - or even that low. Or do you have access to research claiming such achievements?
sarjann 8 minutes ago [-]
I think at 1000x it's probably way cheaper to do an "AWS outpost" style thing. Although not sure if it's a fundamental constraint or something that could be optimised.
Cider9986 4 hours ago [-]
This is the same Google that doesn't have e2ee on their password manager by default. Like WTF, it's a password manager.
bitpush 3 hours ago [-]
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 black or white.
Cider9986 2 hours ago [-]
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.
rpedroso 2 hours ago [-]
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.
ameliaquining 2 hours ago [-]
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.
Cider9986 1 hours ago [-]
LastPass, designed for regular users and one of the most popular password managers, had a breach of user vaults. If they hadn't implemented E2EE then it would have been more devastating than it was (crypto wallets were found from vaults with weak master passwords).
michaelmrose 58 minutes ago [-]
[flagged]
cantalopes 20 minutes ago [-]
That doesn't protect their ad targeting in the eyes of regulators, so no point in turning that on by default
aeturnum 1 hours ago [-]
I think that, if you are under the impression that having an administrative back door is an unpopular feature, then you should speak to more of your non-technical friends about their experience of technology. I think you'll find that the people who could most benefit from a password manager often don't have good credential management and would be worse off if they lost all their passwords when they forgot or lost their master password.
Cider9986 1 hours ago [-]
You can have recovery in Bitwarden with the email feature.
amazingamazing 4 hours ago [-]
If you think about it for a moment you will realize the average user does not want that.
kingleopold 2 hours ago [-]
yes, lastpass get $ tens millions because its weak and gets hacked not because its realiable, secure and great.
rexpop 4 hours ago [-]
I suspect that your one moment of thought follows many years of contemplation. Maybe you can fill us in on some of that background.
giovannibonetti 3 hours ago [-]
E2E encryption means that if the user loses the keys, there is no way to recover that even if they contact support and prove the data belongs to them.
fg137 38 minutes ago [-]
> there is no way to recover that even if they contact support and prove the data belongs to them.
Eh, since Google's support doesn't exist in the first place, none of this really matters, and nothing is lost.
amazingamazing 4 hours ago [-]
How do you make e2e password management work on multiple devices as convenient as not? You cannot.
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.
cantalopes 16 minutes ago [-]
It's a step to provide targeted advertising with mathematically provable "no sensitive info stored" approach. The google must fight really hard because this is the only source of income that makes sense for their position. And it /is/ quite evil tbh
lsb 4 hours ago [-]
Google is making private AI practical with Gemma4 something that you can run without an Internet connection.
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.
drblast 2 hours ago [-]
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?
bmenrigh 4 hours ago [-]
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 encryption is rapidly decreasing.
Which doesn't spell out exactly hon "nontrivial" the cost overhead still is.
mswphd 2 hours ago [-]
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.
sean_pedersen 2 hours ago [-]
There are LLM models which compute only using addition no?
sheesdev 4 hours ago [-]
I've published two papers on using HE for ML and it's nice, but also alarming, to see big players like Google and Microsoft making decent tools for performing HE. Although the technology is still much farther out from being commercially viable, it does pose an interesting problem about how these data aggregation companies will utilise a tech that is inherently private.
j2kun 2 hours ago [-]
One potentially simple answer is: to make things that are otherwise illegal (for regulatory reasons) possible.
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.
tolugenius 3 hours ago [-]
I guess I'm curious from your perspective what and why makes the tech from being commercially viable, and the concerns of big players adopting this (which was always going to happen I imagine, but when shapes a lot of the future of the field).
p0w3n3d 2 hours ago [-]
Ideally: we will have private AI
Reality: our computers will be used as distributed AI calculators
hamper653 31 minutes ago [-]
Freenet, but for AI inference.
NyxWulf 4 hours ago [-]
Maybe I'm not understanding this, but how is it that you can know enough about the data to process it without undermining the fundamental concept of encryption? Isn't encrypted data supposed to be just random noise without the key? The more you know about the underlying data the easier it gets to decrypt? Does this mean someone can just steal your encrypted data and use that to steal your identity without even needing to decrypt it anymore?
luckydata 3 hours ago [-]
you can produce a correct result without knowing what that result means as long as the person you then provide that result to can decrypt it. So the way it works is the server does the job on data it can't read, sends an answer to the device, the device decrypts it.
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 :)
hellohello2 1 hours ago [-]
Have all the skeptics in this thread somehow forgot about Moore's law?
pinkmuffinere 56 minutes ago [-]
What, how is that relevant? the transistors on a microchip double about every two years. That’s descriptive, not prescriptive, so whatever you’re trying to imply about the future is kindof a toss up — there’s no promise the parents hold. And, it doesn’t really have to do with tfa, as far as I can tell? Do you perhaps mean Murphy’s law, “whatever can go wrong will go wrong”?
hellohello2 47 minutes ago [-]
The top comment mentions a ~10^3 overhead. Am I crazy (or already old?) for thinking this is not a very large constant?
pinkmuffinere 38 minutes ago [-]
Oh I see, you’re arguing that computer growth will make this more attractive. I think it’s a decent argument, although personally I find it unconvincing. More compute will be allocated between all the existing options, and I suspect it will go towards faster/better inference, instead of encryption. For most use cases people just don’t care much about encryption, and when feature prioritization comes around it always gets a back seat
hellohello2 32 minutes ago [-]
Yes, I think it really depends on the task. Clearly we won't be willing to spend 1000x on tokens for our everyday needs. But what about for the police monitoring conversations? I'd very much like my chats to stay encrypted, but there have been laws pushing against this. Technology like this provides a real solution i.e. you can scan chats for keywords without actually reading them, and get a warrant if you find something.
nazgulsenpai 3 hours ago [-]
Why is the bold letter n lighter than the rest in this page's font?
FloatArtifact 5 hours ago [-]
Encryption or not, if it's on somebody else's server, it isn't yours. I don't believe Google has my best interest.
u1hcw9nx 5 hours ago [-]
With Fully Homomorphic Encryption it's nobody elses.
The basic idea of of the project is to remove the need for trust.
unsungNovelty 5 hours ago [-]
It's google. They are good at engineering. Not at creating trust. After the bizillionth time they have broken trust, there is no need for benefit of the doubt.
Plont 4 hours ago [-]
Yeah. Google is an ad business. Their entire motive for getting invested in AI is ad revenue. We're supposed to believe they just... won't turn on the money fountain? After going into the red for their data center investments? Hell nah.
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.
ameliaquining 2 hours ago [-]
This blog post is about an open source project that you can look at for yourself and decide whether it's suitable for your use case.
throwaway27448 4 hours ago [-]
There's more to life than branding.
tonyhart7 4 hours ago [-]
so what's the option ??? Meta ?? xAi ?? or OpenAI ???
unsungNovelty 4 hours ago [-]
Why should there by any reason to look at the above ones? We are talking about this B2C company which effects a lot of our lives. The discussion isn't about that or this. The discussion is about JUST this specific company.
4 hours ago [-]
thih9 4 hours ago [-]
To what end?
u1hcw9nx 3 hours ago [-]
Biometric authentication, credential checking, blind auctions, threat matching (search zero-day signatures without revealing the vectors), private dna matching or running queries of medical symptoms and health records against databases.
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.
kccqzy 4 hours ago [-]
This kind of attitude is really disrespectful of decades of progress in cryptography. Without even considering homomorphic encryption, classic encryption is specifically designed to make intermediate nodes such as ISP dumb pipes that do not know the contents of communication. The ISP can store your communications on their server however they want.
If you don’t agree with this model, I’m afraid modern cryptography doesn’t have anything to offer.
jewel 4 hours ago [-]
Even if your files are properly encrypted, if you keep them on, say, Google Drive, then you might lose access to them if your account gets inadvertently blocked.
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.
bitpush 47 minutes ago [-]
Unless all of your money is under your mattress, you're already making such decisions with a far more valuable asset.
krunck 5 hours ago [-]
It's FHE for "cryptographically-secure private AI inference" not for every other service where they snoop into your behavioral information.
yjftsjthsd-h 3 hours ago [-]
It can give you confidentiality without availability. Not sure about integrity? Anyways, still useful.
Deukhoofd 4 hours ago [-]
It sounds neat, but I do wonder how viable this is commercially. How high do we rate the chances that governments around the world will step in before another kind of E2E is rolled out.
4 hours ago [-]
noident 5 hours ago [-]
Does this rely on the Trust Me Bro model, or is there some way for the client to verify that the provider actually isn't able to see your inputs?
I want to read a whitepaper but all I can find is the tl;dw conference presentation
eslaught 4 hours ago [-]
The linked project page [1] claims to be fully homomorphic. Assuming the claim holds (I haven't verified it), then there is provably no way for Google or anyone else to obtain any information from the encrypted data or computation performed on them.
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.
Related, I'd seen this blog [0] posted on HN a few years back that gave a nice run down on the "programmable cryptography" space which introduce FHE and a few other neat concepts. Really enjoyed the read and learned some new terms.
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.
shevy-java 46 minutes ago [-]
I do not want to make Google more powerful than it already is.
oulipo 4 hours ago [-]
Zama.ai is also a player in this space
LoganDark 4 hours ago [-]
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).
noman-land 4 hours ago [-]
100% not an expert but my understanding was that part of what you are proving by signing the computation is that the computation itself was performed specifically as agreed to. I may be mixing this up with zero knowledge proofs.
LoganDark 4 hours ago [-]
If this were the case it would be necessary to send the entire model weights in response to every request which would be a bit inconvenient.
drdeca 4 hours ago [-]
Hmm, could one instead of sending the model weights, send like, a merkle tree root for them, not exactly specifying the model, but at least demonstrating that the same model is used each time?
mswphd 2 hours ago [-]
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.
gaigalas 53 minutes ago [-]
I have an idea for AI companies for tremendous scale, with privacy and all nice things accounted for:
- 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.
jrm4 4 hours ago [-]
Correct. I appreciate the theoretical technology here, but I believe a great deal of harm is done by the fact that people are not likely to understand exactly what this means.
Which is to say, I believe that google is strongly implying the falsehood of "no one at Google can read your stuff."
mohamedkoubaa 3 hours ago [-]
Anything to keep people from running local models
weatherlite 1 hours ago [-]
> Google is making private AI practical with homomorphic encryption
I don't understand why we need to bring LGBTQ+ into everything
traceroute66 3 hours ago [-]
Quoted from the blog post:
> 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]
Secure Enclaves are broken all the time though [1]. They’re also not secure against attacks from a quantum computer (including store now decrypt later attacks). At least with symmetric FHE, anything that happens after encryption requires zero trust.
Indeed, Google itself has a large research group that repeatedly breaks TEEs with side-channels and such.
filup 4 hours ago [-]
Proper encryption means the ciphertext is indistinguishable from noise. So...in order to be able to process on it, you have to make it not indistinguishable from noise.
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.
Veserv 1 hours ago [-]
You are objectively wrong. The math is straightforward to show that you can operate on a ciphertext securely in some cryptosystems.
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.
flambo 4 hours ago [-]
This is actually the magic of FHE. The ciphertext is indistinguishable from noise AND can be computed on, it just looks like different noise.
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.
filup 3 hours ago [-]
If it only appears indistinguishable from noise, but it's actually not, then it's just deception.
drdeca 3 hours ago [-]
They didn’t say that it “appears” indistinguishable from noise, but that it is indistinguishable.
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.
filup 3 hours ago [-]
>They didn’t say that it “appears” indistinguishable from noise, but that it is indistinguishable.
That's the oxymoron. If it was indistinguishable nothing could be gained.
It's not about me being able to distinguish it. It's the model provider saying they cant, when they can.
pluto_modadic 4 hours ago [-]
they could have gone with an oblivious transfer approach (where it's working on what looks like multiple problems at once, you don't know which)
drdeca 4 hours ago [-]
Eh? With secret sharing one can do computation on a shared secret where it is provable that no individual party can recover any information about the data with their share alone.
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.)
filup 4 hours ago [-]
I'm not saying that you can't design a system for secure cloud computing.
drdeca 4 hours ago [-]
You said that FHE is an oxymoron, seemingly on the basis that in proper encryption the ciphertext is indistinguishable from noise, and you think this can’t be true of FHE. I am arguing to the contrary.
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.
Ar-Curunir 4 hours ago [-]
No, that’s not what proper encryption means. Security for encryption means that cipher texts encrypting distinct messages are indistinguishable. This is called IND-CPA, and FHE satisfies this.
filup 3 hours ago [-]
How can it possibly pass indcpa. If the model can give me any valuable information about the cipher. Apparently the middle man would know precisely what is contained in the payload.
drdeca 3 hours ago [-]
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 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).
filup 2 hours ago [-]
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 trust directly on the algorithm. Probably one no one can explain to me like I'm 5. But because it's encrypted I am no longer breaking the law by processing on protected data. I imagine very large contracts await on the other side. Lots of money to be made.
mswphd 2 hours ago [-]
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).
hamper653 12 minutes ago [-]
> That means there was enough information in the ciphertext for the server to perform the inference
The server doesn’t need any information to perform inference.
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!
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.
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.
If Google Cloud can offer FHE-powered tools, a hospital can run Google’s AI diagnostic models on encrypted brain scans without violating privacy laws.
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.
I'm now curious. Who are you?
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.
Homomorphic encryption got significantly efficient with the first few iterations, but I don't really see the necessary orders of magnitude savings coming soon. You could reduce this by some partial encryption schemes (e.g., for LLMs you need a handful of basic operations) but a better alternative already exists: multi-party computation.
Source: I did research in this area in the past.
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/
Using this other encryption, the provider has neither need nor capability to decrypt it on their end, so the user gets extra security.
the main difference is where the guarantee comes from. for FHE, it comes from math, which we trust. for secure enclave, the guarantee comes from Intel/AMD's promise that their hardware is bugless/backdoorless, and that your adversary cannot directly inspect bits in the hardware
> 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.
There is no reason to believe it should be lower than that - or even that low. Or do you have access to research claiming such achievements?
> 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.
Eh, since Google's support doesn't exist in the first place, none of this really matters, and nothing is lost.
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.
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.
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?
> 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 :)
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.
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
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.
Which is to say, I believe that google is strongly implying the falsehood of "no one at Google can read your stuff."
I don't understand why we need to bring LGBTQ+ into everything
> 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/
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.
That's the oxymoron. If it was indistinguishable nothing could be gained.
It's not about me being able to distinguish it. It's the model provider saying they cant, when they can.
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).
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 trust directly on the algorithm. Probably one no one can explain to me like I'm 5. But because it's encrypted I am no longer breaking the law by processing on protected data. I imagine very large contracts await on the other side. Lots of money to be made.
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).
The server doesn’t need any information to perform inference.