Rendered at 16:25:51 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sabretooth1405 24 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 22 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
It’s slightly better for LLMs because FHE is really bad at branches (it ends up essentially having to try both branches), making sorts nearly the worst possible thing to try since it’s all branches. In the case of AI most things are just addition and multiplication which can make some things faster since there aren’t as many branches. But we’re still nowhere near viability.
adastra22 14 hours ago [-]
The flip is also true: LLM inference is very nearly maximally optimal for FHE. Thee costly bit, multiplication of a bunch of compressed floating point numbers, translates 1:1. The only bit I’m not sure about is the softmax sampling at the end, but that’s just once per token.
On the other hand, each FHE step is a LOT more costly (e.g. elliptic curve exponentiation) than a vectorized BF8 multiply on GPU.
Unlike the sorting number case, it is probably same complexity. But no hardware support AND a massive slow down constant even if you were comparing apples to apples on hardware.
Disclaimer: I spent a decade working on crypto systems but I am not familiar with TFA’s research.
skew-aberration 10 hours ago [-]
Softmax is once per token per a layer, and growing linearly with context window size (therefore quadratic over full input).
yorwba 7 hours ago [-]
That's softmax dot-product attention. It's quadratic even without fully-homomorphic encryption, but at least it's not inherently branchy, so won't necessarily slow down much more than other floating point operations under encryption.
But softmax sampling, where you pick a single output token at the end and feed it back in to generate the next one, is branchy, so you need to do some extra encrypted computation to avoid leaking which token was sampled.
covoeus 2 hours ago [-]
Assuming the client is online, you could offload the costly FHE sampling by handing them the raw logits.
dhx 12 hours ago [-]
I found [1] which appears to offer state-of-the-art performance of ~1000s latency for a FHE GPT-2 transformer block, equating I think to 3.33h inter-token latency (0.00008 token/s) for GPT-2(small) which has 12 transformer blocks. This result is using optimised packed arithmetic operations on a GPU as well--so seemingly is unlikely to have much performance upside from further optimisation.
I'm not sure I've interpreted [1] correctly though, and would appreciate correction if necessary.
[1] https://arxiv.org/pdf/2604.04783 -- GPU Acceleration of TFHE-Based High-Precision Nonlinear Layers for Encrypted LLM Inference -- Guoci Chen, Xiurui Pan, Qiao Li, Bo Mao, Congming Gao, Chengying Huan, Mingzhe Zhang, Jie Zhang -- Apr 2026
Dylan16807 7 hours ago [-]
Sorting doesn't need any branches. For FHE you need to think like a circuit designer without indexing operations. In that situation your default sort is a sorting network, made out of nlogn conditional swaps.
justincormack 6 hours ago [-]
can you build a conditional swap in FHE in a small size though? FHE is always circuit like, ie no dynamic control flow anyway I think?
Dylan16807 6 hours ago [-]
Once you calculate which value is smaller, the conditional swap itself is trivial. Let's say inputs A and B, comparison result is a boolean C. Outputs X and Y.
Bitwise: X = A&C | B&¬C, Y = A&¬C | B&C
Arithmetic: X = A*C + B*(1-C), Y = A*(1-C) + B*C
Edit: Or to put it another way, one of the most basic things you can make in a circuit is a multiplexer, and a conditional swap is two minimum size multiplexers next to each other.
matthewdgreen 15 hours ago [-]
I’m genuinely not an expert, but isn’t the beauty of MoE models the fact that we explicitly don’t evaluate every parameter on inference? We evaluate exactly the subset that are needed to evaluate a prompt. Seems like this will bring back data-dependent branches again.
odo1242 1 hours ago [-]
Pretty much, and this does a good job of illustrating the fundamental issue with branching. You could use an encryption scheme that allows the server to determine what MoE expert to load (the simplest would be to have the client decode the value and send it back to the server, though this can sometimes be possible to do without the round trip), but then it’s not fully homeomorphic because the server has some info about the computation that could be used to recover stuff about the original text.
Taking the above point to the extreme, a very simple yet mildly effective “homeomorphic encryption” scheme would be to run the first layer(s) of the ML model on-device, run the majority of the model in cloud, then run the remainder of the model on the device. But then you leak a lot of information that can essentially be used to get back the original text. (Usually in this type of scheme, to defend against this, the provider of cloud services doesn’t have access to the full model, it’s been used before on vision applications involving medical data)
charcircuit 15 hours ago [-]
It would also kill speculative decoding. You would have to run a full inference pass for every token instead of being able to generate multiple tokens with a single pass.
tbenst 19 hours ago [-]
That is sobering for sure, I wonder what the theoretical bounds are on what is possible if known. Would be such a dream to use a Frontier LLM one day with homomorphic encryption, but this sounds wildly implausible based on where things are today.
redeeman 17 hours ago [-]
they would never allow it, atleast not for regular plebs such as you or I, consider if you made it say something politically incorrect? cant have that
joshspankit 18 hours ago [-]
We’re not even close to the limits of AI optimization so finding the theoretical bounds is going to have to wait
randomImmigrant 17 hours ago [-]
This seems a fine tradeoff to me, depending on the context. There are datasets and operations on them where speed being sacrificed for privacy/security seems appropriate.
Ideally, give me a dial, to ask for encrypted intelligence when I need it. Kind of like a private chat, but with deeper privacy protections.
XorNot 17 hours ago [-]
Except that's for pathetically small datasets.
What real datasets exist where this would be a worthwhile trade off versus simply owning the hardware?
The numbers are so bad that underpowered local hardware would still beat it.
inigyou 7 hours ago [-]
yep I can beat 0.0008 tokens/s on GLM-5.2 on my CPU
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 22 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!
monster_truck 5 hours ago [-]
One of the biggest problems IMHO is that they aren't trying to usefully accelerate it on anything other than specialty hardware or 64+ core EYPCs so nobody gets to play with it at home.
ex: A 7900XTX barely gets 0.5 TOPS of u/i64 naively w/ hip-direct, 5-10s just to bootstrap!
I needed more throughput for non-crypto i64 diff eqs so I slopped up a lib that uses RNS & CRT w/ Int8 GEMM... it's good for ~3.9 TOPS (~90% theoretical peak of the RDNA3) at prod relevant FHE sizes (2048/4096). This lowers bootstrap time to 200-500ms. It was basically free real estate lol
It isn't done yet (not worth the heat in the summer), going to finish it in the fall. Have been accumulating cloud credits to do CDNA3/4 validation in the meantime (If anyone has some to offer do let me know!)
It's neat but very dry, uses semantic contracts so you tell it what kind of mult you need and it chooses the validated best backend. If you're doing lots of smaller ops (512, 1024) it will use custom WMMA/MFMA kernels, dual issue, and grouped dispatch to land >70x over hip-direct.
Only 1000x overhead would make some image classification tasks go from 1ms to 1s. That’s viable for some applications!
furkanturan 7 hours ago [-]
Exactly. That is what we have today at Belfort; not enough for making all AI work privacy preserving, but fast enough for many applications, where otherwise unencrypted compute is not acceptable.
elgertam 17 hours ago [-]
I saw a paper about this in early 2020 (pre-COVID shutdowns) at the ScaledML conference. I looked into it and had the same conclusions. At some point, running your own models in the clear is just more practical.
abetusk 23 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 20 hours ago [-]
It's a ridiculous waste of energy, just use local compute.
furkanturan 7 hours ago [-]
Local compute is preferable where possible. There are cases where computation needs to be performed remotely. For example, when collecting data from remote entities while preserving privacy by allowing each entity to retain ownership of the encryption keys used to protect its data. At Belfort, we are exploring such applications, such as
For me it is the simplest reasons of all: privacy / confidentiality. There is absolutely no way any of this data leaves my systems.
joquarky 12 hours ago [-]
Good point, but if we can advance research on this via the AI bubble, it could improve privacy in other areas.
u1hcw9nx 23 hours ago [-]
That's the reason for HEIR like optimization and parameter selection.
It narrows the 10^3 - 10^6 penalty to 10x - 100x.
glaslong 18 hours ago [-]
Thoughts on whether HE could be further hardware accelerated?
michaelmrose 21 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.
u1hcw9nx 19 hours ago [-]
I think you have completely wrong use cases in mind. You will not use this for normal compute workloads.
Typical use cases are for doing biometric authentication without giving your biometric information, or sensitive queries using medical information.
Apple has homomorphic encryption in image search. You can use your own photos encrypted into the cloud to search for landmarks in the image without revealing photos.
People can also coordinate and compare information without sharing sensitive data.
lupire 17 hours ago [-]
Is that (LLM) AI, though?
Fordec 20 hours 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.
furkanturan 7 hours ago [-]
Count Belfort too. In addition to our GPU acceleration efforts, we have ongoing ASIC initiatives to further accelerate encrypted compute.
therealmarv 4 hours ago [-]
Do you mind sharing your master's thesis? oO
Would be interesting to read it (and no judgement!)
clayhacks 23 hours ago [-]
Do you think that’s like a fundamental limit or something that will improve with time and new algorithms?
bhu8 20 hours 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.
dietr1ch 23 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.
Jabrov 10 hours ago [-]
It might still be useful for classification usecases
bevekspldnw 22 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 20 hours 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 20 hours ago [-]
At that kind of amount of waste putting 2U server with some GPUs in hospital would be cheaper
asdfman123 20 hours ago [-]
Making things 10x more expensive to reduce legal liability is what hospitals are all about
bitpush 20 hours 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.
joquarky 12 hours ago [-]
Cold fusion and room temperature superconductors (remember LK-99?) were also all show.
avmich 2 hours ago [-]
You can't prove the theory by providing an agreeing example though.
That for some cases they are still all show doesn't prove everything is all show.
alpaca9 7 hours ago [-]
Sometimes I feel like 75% of their engineers are working on stuff that is purely for show. If their product doesn't generate enough profit very short term they stop it immediately. They have hunderds of cancelled projects, and those are only the ones which have existed. I wonder how many things they made internally and killed before ever showing it publicly.
luckydata 22 hours ago [-]
You are very wrong about all of this btw.
bevekspldnw 22 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.
WarmWash 18 hours ago [-]
Google is too internally split up to have a single cohesive "maximize ad revenue" mission, especially now that cloud is the new golden goose and the future of search/advertising is hazy.
If cloud can sell compute to enterprise that can only use FHE, then they will not give a fuck if the ad goons are disgruntled about it.
bevekspldnw 14 hours ago [-]
You have the CEO and the VPs who have final call when there are disputes below.
Ads doesn’t care until something affects them, GCP doesn’t.
luckydata 17 hours ago [-]
you are 100% correct, this product is to enable things like healthcare and generally AI subscription stuff that otherwise people wouldn't touch because of sensitivity to disclosing sensitive data.
sumeno 3 hours ago [-]
Ads does not have access to GCP data and there is no way legal would approve one
bitpush 20 hours ago [-]
> You literally don’t know who I am or the roles I had.
I'm now curious. Who are you?
bevekspldnw 14 hours ago [-]
Saying that would make it unable for me to use HN as certain companies monitor my social media comments.
trucks-refinish 19 hours ago [-]
yeah and I'm a Navy seal with over 300 confirmed kills etc.
fragmede 6 hours ago [-]
The distance between Kent Walker and Thomas Kurian is what you should be asking.
antonvs 16 hours ago [-]
Given that Google has a single unit that does $76 billion in annual revenue, $100 billion projected, without ads, raises questions about how relevant your knowledge is.
bevekspldnw 14 hours ago [-]
I should have bracketed out GCP as a theoretical application for this. I was referring to the Google consumer extended universe.
surajrmal 14 hours ago [-]
Which is also learning how to monetize their offering via cloud instead of ads. So again your expertise here is questionable.
luckydata 20 hours ago [-]
and you don't know who I am. I might have been closer to that work than you would know.
Chris2048 5 hours ago [-]
Why don't you say what they are wrong about then?
Melatonic 15 hours ago [-]
I'm Ron Burgundy ?
22 hours ago [-]
fragmede 19 hours ago [-]
The one that I'm waiting for is a women's period tracking app that uses FHE on the backend to be fully private.
lupire 17 hours ago [-]
Why on earth do you need a backend for this? The backend only exists because it leaks the data.
fragmede 9 hours ago [-]
because you lose your phone and don't have access to the account anymore.
xg15 8 hours ago [-]
Then the app can make a bog-standard encrypted-at-rest backup to somewhere and make all the computations on the device on the cleartext data.
I don't see the need to do computations on the encrypted data here, which is what FHE would provide in addition to traditional encryption.
> and don't have access to the account anymore.
This would be trouble with or without FHE. Even if the backend wouldn't need to decrypt the data, the user will - so as soon as you actually want to show something in the app, you have the same key management problems as without FHE.
fragmede 6 hours ago [-]
Okay, so the platform becomes valuable to its users when it's able to suggest things like "based on millions of users, people with cycles like yours typically ovulate around day 16."
In order to do the data mining in order to make those kinds of claims, traditionally you'd need to have access to the data.
As you point out, encrypted-at-rest is solved. But what about when it's not at rest?
In-use and in-transit is when FHE kicks in. Sure, you could just do it locally, but then you miss out on the aggregate data mining. Not for advertisers, but because it helps women with their bodies. The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
xg15 4 hours ago [-]
> Okay, so the platform becomes valuable to its users when it's able to suggest things like "based on millions of users, people with cycles like yours typically ovulate around day 16."
I don't know much about period tracking apps, but is this really the main reason people install those apps? Wouldn't you be able to get similar results by simply monitoring (on-device) the cycle of the person who uses the app for a few months?
How do those apps work before they have millions of users?
All the warnings I've seen about period tracking apps were about unexpected data collection of the entered data. This would be pretty silly if the data collection was integral to what the user expects the app to do.
> Sure, you could just do it locally, but then you miss out on the aggregate data mining.
Ok, a bit of a technical question about FHE here: My understanding of FHE was that you have input data encrypted with some key (plus auxiliary inputs, if needed, that are not encrypted), then you do operations on that data and get a result that is (still) encrypted by that same key.
No questions there as long as you're dealing with a single key.
But the whole point of aggregation and data mining is to combine data from many different users, i.e. inputs that are encrypted by many different keys. Does that work with FHE at all? And if yes, by which key is the aggregation result encrypted?
I don't see how that would work without either "moving" data from one key to another - which would be practically equivalent to decryption - or getting a result that is simultaneously encrypted by all user keys, i.e. practically useless because no one could individually decrypt it.
> The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
You could obviously read the data enough to do aggregations on it.
If you can do that for "good" purposes, what stops you to use the same aggregation algorithm for advertisers - except pinky promises again?
Chris2048 5 hours ago [-]
If you can trust the app/platform developers to send encrypted anonymised personal data, then how can you trust them to properly use FHE personal data?
> "we literally cannot read your period data."
If the purpose is aggregated data for statistic, then surely the only per-user data they need centrally can already be aggregated (to some degree) on the device, e.g. send back only statistical-distribution variables of the personal data, for distributions over the 3-4 months? And at some point, does the service need to keep collecting data, once the model is good enough (at predicting ovulation etc)?
Another concern would be: If they are building a model, using user data, why should they own the model and thus monetise it (i.e. sell it back to its users) when users get no compensation for supplying that data in the first place.
A flow-tracking app should just stick to that, and purchase the model (for a fee) from a third party.
The third party should concern itself with how to get the data without being able to leverage its position as a flow-app maintainer to trick or mislead the majority of its users into giving them free data.
glaslong 18 hours ago [-]
Saving your comment for the Weekend Project idea backlog, if you don't mind :)
mrcwinn 18 hours ago [-]
Sounds like the start of every journey. With all respect to your thesis, I probably put my chips on Google's research and security teams.
snovv_crash 8 hours ago [-]
So much inefficiency just to run it on someone else's untrusted hardware. Private AI is already possible today with local open-weight models running on hardware you control.
Homomorphic encryption is cool technology, but I'm really not sure what problem it solves.
neya 3 hours ago [-]
I bet this would've been ground breaking if this was an announcement from Apple though.
The advertising case seems to be solved by local models as well, then the data doesn't even need to be sent to the server.
The Swift one is interesting, but I don't understand why the transaction needs to be encrypted, or more specifically why the model can only run in the encrypted part of the pipeline.
Super cool tech, but I guess I just don't see the application yet.
And wow, I worked with Marc a decade ago, small world.
firtoz 7 hours ago [-]
It's so that they can sell more things to enterprise customers
never_inline 13 hours ago [-]
I think you folks are reading too much into it. I think the people working on FHE need to publish an AI-oriented pitch to retain funding from AI-pilled execs. Must be the same case with the golang post few days ago.
fedpost 12 hours ago [-]
Yeah I don't think they actually want this. There's far too much deeply personal and useful data being freely feed to the companies running these models.
People are giving them everything. Their thoughts, feelings, intentions, company IP... It's a fucking gold mine.
There's just too much value in retraining on that data and even if there wasn't, the feds lean so heavily on Google search histories to get convictions I am certain there will be pressure to prevent any mass market services from adopting this.
xg15 8 hours ago [-]
Well, wait until there is the first training algorithm that supports FDE. We promise we won't ever decrypt your data, we'll just train our models with it...
akoboldfrying 8 hours ago [-]
When McDonalds introduced salads to their menu, purchases shot up -- but ~no one actually bought the salads. They just felt better about buying the same old unhealthy food from McDonalds when they knew that healthier options were available that they could potentially buy.
This is the same kind of thing. The crazy overhead of FHE means it's not practical for almost any kind of real world computational work. But having it available at all is undeniably technically impressive, and some of that sense of technical refinement bleeds over into your opinion of Google as a whole.
Incidentally, being a business client of Google's who actually uses this (or, say, quantum computing) for $BUSINESS_FEATURE would garner the same kind of positive attention, independently of whether it's technically a good idea.
Finally, if the overheads come down to the level where they are still significant but not insane, GCP is in a great position.
Aozora7 7 hours ago [-]
I'll have you know I started picking salads instead of fries in combo meals the moment they became available.
Not that I'm a frequent customer, either before or after.
akoboldfrying 6 hours ago [-]
Good on you and the other four or five people who do this! ;)
oofbey 11 hours ago [-]
All true. HE will never be used for anything real because it’s way to slow and inefficient, meaning you can only run the stupidest models on it. And there’s no commercial incentive to make it work because collecting data is too valuable.
But at the same time HE is classic Google promotion fodder. Really difficult technical problem! That’s what gets people promoted at Google. Nobody actually cares about it or will use it? That also is what gets people promoted at Google. Because Google only employs “the smartest people on earth” which means people who solve difficult problems. Difficult problems - not problems that need solving.
meindnoch 21 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.
amelius 18 hours ago [-]
> The most private AI is the one running on my own hardware, not in some giant data center.
I want that too, but you gotta ask yourself the question how efficient that is compared to running it in a datacenter shared with everybody else.
adgjlsfhk1 7 hours ago [-]
it's more efficient than paying 1000x for fhe
Chris2048 4 hours ago [-]
Energy efficient, yes, but when you want to keep a query/data private it's maybe worth the extra $ KW. Chicken pie recipes and google AI-search can still go though the datacentres.
As an aside: The computation might also not be the same e.g. ever-changing hidden pre-prompts, security/safety checks blocking or degrading responses, unavoidable verbosity to simple questions, watermarking, collection of prompt data to build user profiles for the purpose of advertising - and we haven't even seen in-response adverts, or sponsor-biased responses yet, but no doubt it's coming.
lupire 17 hours ago [-]
It doesn't matter how efficient it is because the user base for that workflow is microscopic
Eueudhsbsj32 21 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/
catlifeonmars 12 hours ago [-]
> aren’t there more efficient ways
Heh yes absolutely, but there is some nuance.
Secure Enclave still requires you to trust the operator and also trust that it’s configured properly, supply chain is secure, etc.
The beauty of FHE is that it doesn’t rely on the compute being secure. All you need to secure are things you already have control over as a client.
I agree with you it’s still way too slow to be generally useful. (By general, I mean practical for arbitrary computation — you can relax the requirement and have fast homomorphic encryption if you only do specific kinds of operations).
siddthesquid 20 hours 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 19 hours 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
siddthesquid 19 hours ago [-]
- If an AI provider has control over the AI algorithm running in the secure enclave, they can easily have functions that provide them the plaintext through a separate channel. secure enclave does not prevent that
- The output can reveal information to the provider, which homomorphic encryption would have protected
- Inference is running on GPUs - so its moreso nvidia than amd/intel, but this is just a nit
So homomorphic encryption exists so the user doesn't need to do work to figure out if the provider could be adversarial.
Eueudhsbsj32 13 hours ago [-]
> they can easily have functions that provide them the plaintext through a separate channel
That's why they provide cryptographic attestation that the open model they're running is exactly what they advertise without any modifications.
That combined with GPU confidential compute should protect your LLM prompt and output.
catlifeonmars 12 hours ago [-]
They’re not equivalent. One provides a best effort guarantee and is not trivial to implement correctly (it’s the Secure Enclave). I agree that you _could_ do all those things and do them correctly. However there are a lot more points of failure.
E2E encryption (including homomorphic encryption) have the nice property that there are much fewer ways for things to fail.
(Tangentially, attestation is basically trying to ensure that faults are obvious, but that doesn’t reduce the probability of the faults in the first place).
llleeeoooh 17 hours ago [-]
yes I agree. although just to nitpick, there are ways to prevent side channel attacks within the enclave using software tricks. and output can remain in ciphertext via diffie hellman with client, etc. etc. but you're right that FHE provides a much more concrete guanrantee.
rahkiin 10 hours ago [-]
Yes, by running models locally
whyage 14 hours ago [-]
Check out opaque.co
delusional 19 hours ago [-]
There's a much more simple and much more efficient way to do it: Policy and Legal contract.
Eueudhsbsj32 18 hours ago [-]
A contract doesn't protect your data from government searchs, with or without warrant.
epwr 13 hours ago [-]
Wouldn’t a zero data retention agreement be pretty close to this?
traceroute66 1 hours ago [-]
> Wouldn’t a zero data retention agreement be pretty close to this?
1. A ZDR clause is "trust me bro". You have zero way of verifying their pinky-promise.
2. A ZDR clause is still subject to the old-classic "government, court or administrative order" catch-all clause. :)
3. "Even with ZDR enabled, Anthropic may retain data where required by law or to address Usage Policy violations. If a session is flagged for a policy violation, Anthropic may retain the associated inputs and outputs for up to 2 years, consistent with Anthropic’s standard ZDR policy." (I quoted Anthropic, I'm sure all the others have similar).
froh 21 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 20 hours 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 20 hours 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?
froh 11 hours ago [-]
maybe I simply don't know how this works ;-)
I was very much surprised and asked. give me demerits for the way of asking.
but the question stays: how come an encryption scheme inflates data by this order of magnitude and needs GB sized keys?
where can I learn about this? not the nutty gritty details proofs and all but an overview. assume I did my CS masters in the 1990s and worked as SW eng ever since.
Yeah, I have doubts too. It's much higher than that.
14 hours ago [-]
Cider9986 23 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 23 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.
eventualcomp 3 hours ago [-]
Why are we citing novelists for appeals to authority on something like intelligence. I thought this might be a figure on developmental psychology to give value to your comment, but it's not even that. Should I be citing George Orwell's doublethink to counter you?
Cider9986 22 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.
skybrian 18 hours ago [-]
I'm pretty sure I've seen it sometimes in video calls. But it might only be two-way conversations?
Cider9986 18 hours ago [-]
That was my bad on the complete statement. If I could still edit I would say "that I know of".
rpedroso 21 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.
18 hours ago [-]
ameliaquining 21 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 21 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).
ameliaquining 15 hours ago [-]
Google's security record at avoiding that kind of breach is just about the best in the industry, and their system that handles custody of password manager secrets is designed to withstand even a compromise of their production infrastructure (https://security.googleblog.com/2022/10/SecurityofPasskeysin...). I would advise almost all users to worry more about getting locked out of their password database than about that. Of course, I would also advise almost all users not to self-custody cryptocurrency.
phyzome 3 hours ago [-]
Ah, Google must be very intelligent indeed, then.
michaelmrose 20 hours ago [-]
[flagged]
tomhow 19 hours ago [-]
> This is generally the test of extreme stupidity because those so adept rarely realize there is even a contradiction because they lack in critical thinking.
> You can separate Cook is a garbage person
We've banned this account.
We've asked you politely, several times over the years to observe the guidelines. In recent times you've been acting more than ever like they don't apply to you. They do apply to you just as they apply to everyone and it's time we made that clear.
In this case, someone has raised the notion that sometimes someone can hold two legitimate positions that are contradictory, which, as the original commenter mentioned, is attributable to F. Scott Fitzgerald but has been noted in different ways by many reputable philosophers and scholars through history. In your reply, you've effectively sneered at anyone who wrestles with such contradictions, including the parent commenter, then gone on to use the term “garbage person” for another human.
Other terms you've used in past months include:
most humans are dumber than a box of rocks
literally not figuratively the 1930s Nazis
fools
idiots
morons
cretins
It's always a challenge for us to fairly moderate political discussions on HN. We want people to be able to discuss important, difficult topics and ideally to work together to develop ways of making the world better. HN is a place for builders, and that can and should include building solutions for the difficult problems the world faces, or at least talking about how we could. Identifying and critiquing flaws in the ideas and actions of one's political or intellectual opponents is fine and healthy.
Continually demeaning individuals or groups with dehumanizing or contemptuous epithets and caricatured characterizations makes this place toxic and drives away people who come here with the expectation of having intellectually gratifying discussions with reasonable people.
When people continue to break the guidelines, even after several appeals from moderators, we have to assume they have no intention to use the site as intended and in fact want to be banned. If that's not the case, you can email us at hn@ycombinator.com to discuss how you can demonstrate that.
not_a_bot_4sho 12 hours ago [-]
I wholeheartedly support moderation to keep a healthy community but this is asinine.
My takeaway is that you were personally offended by the (mild) attack on Cook and Apple products, likely because you use them and associate them with your self worth, and responded in defense of ego.
I say this based on observing casual usage of 'fool' and 'idiot' and other terms a myriad of times in other threads with no action or response.
I'm glad to see a moderator in the wild but JFC not attacking a windmill.
tomhow 11 hours ago [-]
Please don’t imagine my “true” motivation or inner psychological state and attack me for it. You have no idea what devices I use or what I think of Tim Cook. Even if I had any personal affection for him, if I banned accounts just for criticizing a product or individual I personally liked, I would not have lasted more than a few days before being hounded out by top users of the site.
It’s true that this comment alone was not sufficient for a ban; as I explained in my comment, it’s the pattern of comments, particularly in recent days, continuing a pattern over years that we’ve posted several warnings about. And it's the fact that other users who have a solid track record of contributing positively to HN are being driven away by that style of rhetoric from this user, or at least signaling that these comments were beyond the pale.
Our role here is to make HN a place where reasonable people feel they can have intellectually gratifying discussions that are of higher quality than elsewhere online. When we see signs that good contributors are being driven away by an escalating pattern of toxic comments from a user who has been warned many times over a decade, it would be negligent of us not to act.
As we say all the time, we don’t see every guidelines breach, or reply every time we do; there are over 10,000 comments posted each day and only two of us. But when we see an ongoing pattern of abuse, we always issue warnings, then ban the account if it continues. You’re always welcome to email us (hn@ycombinator.com) when you see anything egregious, or at least just flag the comment. That's what people do when they wholeheartedly support moderation.
garbagewoman 18 hours ago [-]
Ehh, “dumber than a box of rocks” or similar is more hyperbole than dehumanising speech. Dehumanising speech is calling someone something like a cockroach or a rat. Bit of an overreaction here mate
tomhow 18 hours ago [-]
Sure, in isolation, you can dismiss that kind of language as hyperbole and let it pass. But we're talking about a pattern of rhetorical style and substance over several years that they have been warned about several times, but with no evidence of any intent to reform. HN is not intended for this style of discussion, and people who continue to engage it are driving away people who do want to use HN as intended.
garbagewoman 17 hours ago [-]
Its a pattern of rhetorical style that isn't what a reasonable person would call dehumanising language. Their comments might not be something you think is acceptable for HN, but using that word to describe their comments is a real stretch and devalues the word
aeturnum 21 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 21 hours ago [-]
You can have recovery in Bitwarden with the email feature.
amazingamazing 23 hours ago [-]
If you think about it for a moment you will realize the average user does not want that.
kingleopold 22 hours ago [-]
yes, lastpass get $ tens millions because its weak and gets hacked not because its realiable, secure and great.
rexpop 23 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 23 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 20 hours 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 23 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 20 hours ago [-]
That doesn't protect their ad targeting in the eyes of regulators, so no point in turning that on by default
oofbey 11 hours ago [-]
Former Googler here. E2EE is easy. Nobody gets promoted at Google for solving easy problems. In fact if you set out to solve an easy problem, it looks bad at performance review time.
3 hours ago [-]
Cider9986 2 hours ago [-]
How is E2EE easy?
HlessClaudesman 9 hours ago [-]
"hotword" detection, is this basically sniffing encrypted data for words the authorities don't want you to speak?
Seems counterproductive to their stated aim of privacy.
xg15 8 hours ago [-]
Not even just by the authorities. This sounds like the wet dream of Google itself or any other data mining companies. You can just ship the most sensitive data around and extract signals to your hearts content - and even if it would be protected by law, you're good because hey, it's always encrypted, and the signals, ad assignments and profile markers are encrypted too!
This is what I don't like about all this "I'm not touching you" privacy tech, also including the new trend of nonvoluntary on-device processing.
They pretend "privacy" was a primary goal of it's own, completely detached from any reasons why you would want to have it.
Then they go on gloriously holding up the flag of privacy, while at the same time enabling all the things that you wanted to have privacy against in the first place.
HlessClaudesman 7 hours ago [-]
And if they can detect "words", surely a determined attacker can reconstruct the whole thing.
hyusap 6 hours ago [-]
from what I understand, only the holder of the private key would be able to see if a hotword was detected or not. even if Google ran hotword detection over your data, they’d only get a encrypted output on if the hotword was detected or not
lsb 23 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.
childintime 4 hours ago [-]
It seems to me this tech still presumes the data sits in data warehouses, which i don't like to start with. The tech succeeds in packing the data in identical black boxes, so they all seem equal to the map-reduce function that runs over them. A separate identification layer knows which of the boxes is yours. But who knows, maybe from the results you can be fingerprinted anyway. As in the game, how many questions before you can guess the thing I'm thinking of? Answer: not that many.
myshapeprotocol 11 hours ago [-]
Making homomorphic encryption practical for AI workloads is a massive step forward for privacy-preserving architectures. Brilliant milestone.
magios 17 hours ago [-]
https://fhetextbook.github.io/ which i believe was linked on this website previous is what i used to learn about how this stuff works.
I see a lot of comments here about how private AI is much cheaper than doing this, and that is currently true.
But I am curious if anyone can think of any use cases for this as it currently stands? For every idea I can think of, I can think of another solution that would probably be a better solution at current slowdown in cost from using homomorphic encryption.
For their two examples...
1) For the "will they click the add" one, how would anyone verify that the model I am uploading of myself is remotely accurate? And can't they learn my characteristics by running them against very specific ads that pinpoint my preferences?
2) For the "Do you have heart disease" one, why not just generating a billion datapoints (or more). The user can download the compressed data of this huge sample of points and then just enter their data on their own side and find the point that is closest (if not an exact match) to their own data?
I'm not pulling apart the idea of homorphic encryption, I'm just curious if anyone can think of a really compelling use case for it given it 10^3 to 10^6 greater compute cost?
catlifeonmars 13 hours ago [-]
If the bottleneck is data transfer rate or volume, then I think you’ll find more use from today’s FHE. Incidentally there is a fair amount of overlap in the use case space between homomorphisms and oblivious transfer.
bilsbie 5 hours ago [-]
I think this could be an effective privacy preserving approach:
Run the encoding and first and last layer of the LLM on the users machine. They could still get some idea of the content but really couldn’t easily get the actual text back.
Anyone know if that’s viable?
Frannky 11 hours ago [-]
A homomorphic encryption blogpost without any mention of the computational overhead...
bmenrigh 23 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 21 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.
nl 15 hours ago [-]
It's not running LLMs.
sean_pedersen 21 hours ago [-]
There are LLM models which compute only using addition no?
sheesdev 23 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 22 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 23 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).
senand 10 hours ago [-]
I‘m new to this, but mildly skeptical. In complex agentic engineering, there are lots of intermediate steps that depend on each other. Even if you disregard the significant encryption cost, this makes it impractical. So seems like this will stay a niche.
furkanturan 6 hours ago [-]
Thanks a lot. We have some road ahead for using encrypted AI for your agentic work. Today, I would not suggest thinking that as the primary target. Instead, there are many untapped applications (e.g. inter-bank transfers, industry, healthcare) where regulations, privacy laws and compliance requirements restrict institutions from touching data. These will initially be our key enablers, and over time we hope to extend the range of applications. At Belfort we are exploring such use cases that will benefit our FHE acceleration.
r3trohack3r 11 hours ago [-]
Does this also solve provable compute as a side effect? Since the compute is fully encrypted end-to-end, the host wouldn’t be able to modify the program and still give valid results?
So a caller could run a program on untrusted hardware and trust that the hardware actually ran the program?
tsimionescu 10 hours ago [-]
No, with FHE you don't know what program is running on the data, you just know that it can't access your data.
drblast 21 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?
vkaku 9 hours ago [-]
I really want nobody to waste cycles on my AI than me. This is useless because now I need to pay for wasted inference AND encryption cycles on top of wire encryption.
furkanturan 6 hours ago [-]
While encrypted AI chatbots seem within reach, we don’t see them as the primary target today. There is a set of untapped applications, such as inter-bank transfers, industrial use cases, and healthcare; where regulations, privacy laws, and compliance requirements prevent institutions from directly accessing or processing sensitive data.
This is where we believe Belfort can make a real difference: enabling organizations to compute on sensitive data while preserving strong privacy guarantees. And FHE doesn’t necessarily mean relying on Google, AWS, or Azure for encrypted compute. Companies can run FHE on their own infrastructure, allowing them to process their clients’ data privately while maintaining control over their systems and keys.
These applications are our initial focus, and over time, we aim to expand the range of use cases that FHE can unlock.
NyxWulf 23 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?
mswphd 12 hours ago [-]
the basic encryption scheme used here is fairly straightforward actually, at least the symmetric encryption version. Let s be a uniformly random, 512-dimensional u32 vector. To encrypt a message m (say a 512-dimensional bit vector for simplicity), you
1. generate a 512 x 512 random (u32) matrix A, and
2. generate a 512-dimensional rounded (to the nearest integer) Gaussian, say of standard deviation 10, e.
The ciphertext is then [A, b :=As + e + 2^8 m].
To decrypt, you compute b - A
s to recover 2^8 m + e. You can then recover m, as e << 2^8 with high probability.
Anyway, if you have two of these ciphertexts, you can sum them together to get
[A1 + A2, (A1 + A2)s + (e1 + e2) + 2^8 (m1 + m2)]
this decrypts to m1 + m2, so you can recover homomorphic sums (or scalings by small integers).
Multiplication is more complex, so I won't get into it here. But the high level from the above example is that you could have someone compute arbitrary linear functions of your data without them knowing what your data is.
Chris2048 3 hours ago [-]
Will the new (summed) A, e and b be the same size as the originals,
and is m2 + m2 still a 512-dimensional bit vector?
I though (when I tried to understand it) that some part of the HE inflates some component of the result?
jijji 10 hours ago [-]
this isnt about the progress of FHE, this is about models hiding reasoning traces (i.e. "thinking") from their paying customers because they dont want them knowing how question A got to answer B.
luckydata 22 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 :)
maxo133 17 hours ago [-]
Funny to read this, but google is currently number one anti-privacy big tech company. No other company makes it as difficult for its users using anonymization/privacy software to access their services
kccqzy 16 hours ago [-]
Pure hyperbole. I can’t even browse Facebook or Instagram anonymously for 15 seconds; I get a hard login popup that would require me to be identified in order to continue. Same with X. I’m also starting to see this with Reddit. Google is the tamest of the bunch; I still do all my Google searches while logged out. Occasionally I get a CAPTCHA but that’s about it.
stackskipton 16 hours ago [-]
Google generally doesn't need you logged in unless you are doing heavy privacy cleaning.
Even in that case, they see data they are getting to be worthwhile enough for their other lines of business.
19 hours ago [-]
p0w3n3d 21 hours ago [-]
Ideally: we will have private AI
Reality: our computers will be used as distributed AI calculators
hamper653 20 hours ago [-]
Freenet, but for AI inference.
p0w3n3d 4 hours ago [-]
That's not what I meant. I meant botnet taken over by Google
sarjann 20 hours 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.
nazgulsenpai 22 hours ago [-]
Why is the bold letter n lighter than the rest in this page's font?
Danox 17 hours ago [-]
The only question is do you trust Google? No…
furkanturan 6 hours ago [-]
That is the key advantage of FHE: you encrypt your data locally, using keys that you own, and never need to share the plaintext—or the keys—with anyone.
But there is more to it. Teams like us at Belfort, we are working to make FHE practical for organizations that want to deploy it for their own use cases, including on infrastructure they control themselves. Even in these setups, FHE can enable applications that would otherwise be blocked by regulatory, privacy, or compliance requirements.
Deukhoofd 24 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.
24 hours ago [-]
traceroute66 23 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.
FloatArtifact 1 days 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 1 days ago [-]
With Fully Homomorphic Encryption it's nobody elses.
The basic idea of of the project is to remove the need for trust.
unsungNovelty 1 days 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 24 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 21 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 24 hours ago [-]
There's more to life than branding.
tonyhart7 24 hours ago [-]
so what's the option ??? Meta ?? xAi ?? or OpenAI ???
unsungNovelty 23 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.
23 hours ago [-]
thih9 24 hours ago [-]
To what end?
u1hcw9nx 22 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.
thih9 10 hours ago [-]
I do like that list and thank you for the explanation.
I still worry about how an ad company is going to approach this. Each of these advancements could be used to put ads in more places.
kccqzy 23 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 23 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.
kccqzy 17 hours ago [-]
That’s not a problem solvable by cryptography. Your ISP can’t read your traffic, but can cut off your traffic. You can use end-to-end encryption to encrypt your files to upload to Google Drive, but Google can choose to delete your files.
furkanturan 6 hours ago [-]
FHE is not always for using somebody else's server; but for sure you do not share keys with that somebody else.
It's FHE for "cryptographically-secure private AI inference" not for every other service where they snoop into your behavioral information.
bitpush 20 hours ago [-]
Unless all of your money is under your mattress, you're already making such decisions with a far more valuable asset.
yjftsjthsd-h 23 hours ago [-]
It can give you confidentiality without availability. Not sure about integrity? Anyways, still useful.
17 hours ago [-]
chrisan 17 hours ago [-]
Man oh man did I read that title wrong and was completely confused
cantalopes 20 hours 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
FartyMcFarter 5 hours ago [-]
How would advertising be implemented in the scenario of using this technique?
noident 24 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 24 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.
> 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?
The point of FHE is that you only ever send encrypted data. So if you trust that Google hasn't broken the encryption algorithm entirely, they never access the plaintext.
hellohello2 20 hours ago [-]
Have all the skeptics in this thread somehow forgot about Moore's law?
pinkmuffinere 20 hours 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 20 hours 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 20 hours 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 20 hours 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.
pamcake 16 hours ago [-]
Now have you met my friend Planck Length?
hellohello2 15 hours ago [-]
Haven't seen him no ;)
lupire 17 hours ago [-]
Look at DRAM price on a Moore's Law chart.
tjpnz 6 hours ago [-]
Sounds like a fantastic waste of compute. The future of private AI is local inference rendering this application of it pointless.
cryptographical 16 hours ago [-]
all we need now is indistinguishable obfuscation
nullc 21 hours ago [-]
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.
Tepix 19 hours ago [-]
> Google’s history of innovations in privacy technology
The list contains more than 6 chapters with multiple entries each.
Google has truly been very innovative in destroying privacy online.
gigatexal 11 hours ago [-]
Maybe Apple will put its watches behind this and the computational complexity will be solved by some breakthrough.
gigatexal 5 hours ago [-]
s/watches/war chest/g
Watney-0717 11 hours ago [-]
Can we slash Google's 1000x FHE cost by 50%+ using a brain-inspired RC router like Project Ares-TCO?
josefritzishere 19 hours ago [-]
Why is Homomorphic Encryption necessary at all? The article seems to lose the plot in the process of tooting their own horn.
fillihp 13 hours ago [-]
homoerotic fan cryption - after dark.
oulipo 23 hours ago [-]
Zama.ai is also a player in this space
furkanturan 7 hours ago [-]
Yes, it is. But it’s important to recognize that there are different FHE schemes. Zama has invested heavily in TFHE and achieved impressive results. However, time has shown that TFHE is not the best fit for encrypted AI workloads, with CKKS and related schemes gaining an advantage with mathematical and algorithmic advances continue. At Belfort we have foot on both sides; FPGA acceleration for integrating to Zama's TFHE-rs, and GPU acceleration for CKKS.
LoganDark 24 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 23 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 23 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 23 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?
LoganDark 11 hours ago [-]
I feel like that'd have to be generated as a side effect of the computation somehow?
mswphd 21 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.
shevy-java 20 hours ago [-]
I do not want to make Google more powerful than it already is.
jrm4 23 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."
jijji 10 hours ago [-]
gaslighting people by pretending that encrypting reasoning traces between agent and client is a win for "private AI"... the title should be rewritten as it is plainly conceding -- Closed AI providers use encrypted reasoning traces to hide what the model is doing to come to a conclusion. This is not scientific progress, this is molopoly protectionism. No person using these models wants the reasoning traces hidden from them, it prevents the user from learning how conclusions about a question are derived.
mmeyerlein 2 hours ago [-]
[flagged]
CurbStomper 16 hours ago [-]
[dead]
gaigalas 20 hours 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.
mohamedkoubaa 23 hours ago [-]
Anything to keep people from running local models
Havoc 18 hours ago [-]
Can't say I have much faith in "send it to google it'll be private thanks to crypto magic".
nah bro...the solution here is to not trust google
weatherlite 21 hours ago [-]
> Google is making private AI practical with homomorphic encryption
I don't understand why we need to bring LGBTQ+ into everything
jacquesm 18 hours ago [-]
Private AI is perfectly practical already and it really doesn't need Google at all. Besides the word 'practical' here is really stretching things.
furkanturan 7 hours ago [-]
FHE doesn’t need Google too. Google research is investing in to it. Like we are at Belfort, various teams work on making FHE practical for organizations that want to run it for their own use cases, including on infrastructure they control themselves. Even in these setups, FHE can enable applications that would otherwise be blocked by regulatory or privacy requirements. Check out; https://belfortlabs.com/blog/belfort-partners-with-lg-on-enc...https://belfortlabs.com/blog/encrypted-fraud-detection-with-...
filup 24 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 21 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.
mswphd 12 hours ago [-]
conceptually your example is fine/good, but it's worth clarifying that the scheme you describe is insecure, as unpadded RSA fails to be IND-CPA secure. this is because Enc(m)Enc(m') = Enc(mm') is a predicate a passive observer can check, to gain information about Enc(m*m').
that being said, you can construct IND-CPA secure homomorphic encryption schemes from factoring-based assumptions iirc, so this isn't a fundamental obstacle.
flambo 23 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 23 hours ago [-]
If it only appears indistinguishable from noise, but it's actually not, then it's just deception.
drdeca 23 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 22 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 23 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 23 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 23 hours ago [-]
I'm not saying that you can't design a system for secure cloud computing.
drdeca 23 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 23 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 23 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 22 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 22 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 21 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).
hnaccount_rng 9 hours ago [-]
I think the term information is misleading here. In any encrypted message there is the original information, it must be because we are able to decrypt it. So from an information theory point of view that the server can "distinguished my ciphertext enough to produce a coherent reply" is always possible. The whole point of encryption is that we have Math that allows the identification of that information only under presence of the (or at least some kind of) secret.
The price that HE is paying is essentially "have to run every possible contributing computation", which means it has to scale extremely badly for anything real world complex
hamper653 20 hours 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.
speedstyle 15 hours ago [-]
If you send someone `key xor X`, they can reply with `key xor X xor Y`, and you can recover `X xor Y` – without them having a clue what X is.
Hopefully then it's not too hard to believe you can build an encryption scheme and operations where `dec(enc(X) ⊞ Y) = X + Y` and `dec(enc(X) ⊠ Y) = X × Y`. If these operations can also be composed, i.e. homomorphism, then they're Turing complete! You can turn any function f(X) into a ciphertext version `dec(F(enc(X))) = f(X)`. It can't leak any information about X, because you only ever provided enc(X). For example you transform 'branching' code to something which traverses every path, and paths which do nothing will still appear to randomize the ciphertext, because you can't invent operations that distinguish which path is taken, because it's a secure ciphertext.
Modern homomorphic encryption uses more complex encryption schemes and primitives, to achieve thousands/hundreds rather than millions of times slower than f. Nonetheless it's impossible for the provider to gain a single bit of information about X.
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...
On the other hand, each FHE step is a LOT more costly (e.g. elliptic curve exponentiation) than a vectorized BF8 multiply on GPU.
Unlike the sorting number case, it is probably same complexity. But no hardware support AND a massive slow down constant even if you were comparing apples to apples on hardware.
Disclaimer: I spent a decade working on crypto systems but I am not familiar with TFA’s research.
But softmax sampling, where you pick a single output token at the end and feed it back in to generate the next one, is branchy, so you need to do some extra encrypted computation to avoid leaking which token was sampled.
I'm not sure I've interpreted [1] correctly though, and would appreciate correction if necessary.
[1] https://arxiv.org/pdf/2604.04783 -- GPU Acceleration of TFHE-Based High-Precision Nonlinear Layers for Encrypted LLM Inference -- Guoci Chen, Xiurui Pan, Qiao Li, Bo Mao, Congming Gao, Chengying Huan, Mingzhe Zhang, Jie Zhang -- Apr 2026
Bitwise: X = A&C | B&¬C, Y = A&¬C | B&C
Arithmetic: X = A*C + B*(1-C), Y = A*(1-C) + B*C
Edit: Or to put it another way, one of the most basic things you can make in a circuit is a multiplexer, and a conditional swap is two minimum size multiplexers next to each other.
Taking the above point to the extreme, a very simple yet mildly effective “homeomorphic encryption” scheme would be to run the first layer(s) of the ML model on-device, run the majority of the model in cloud, then run the remainder of the model on the device. But then you leak a lot of information that can essentially be used to get back the original text. (Usually in this type of scheme, to defend against this, the provider of cloud services doesn’t have access to the full model, it’s been used before on vision applications involving medical data)
Ideally, give me a dial, to ask for encrypted intelligence when I need it. Kind of like a private chat, but with deeper privacy protections.
What real datasets exist where this would be a worthwhile trade off versus simply owning the hardware?
The numbers are so bad that underpowered local hardware would still beat it.
Project intro talk from 2023: https://www.youtube.com/watch?v=kqDFdKUTNA4
https://github.com/google/fully-homomorphic-encryption/tree/...
https://fhe-benchmarking.github.io/
"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!
ex: A 7900XTX barely gets 0.5 TOPS of u/i64 naively w/ hip-direct, 5-10s just to bootstrap!
I needed more throughput for non-crypto i64 diff eqs so I slopped up a lib that uses RNS & CRT w/ Int8 GEMM... it's good for ~3.9 TOPS (~90% theoretical peak of the RDNA3) at prod relevant FHE sizes (2048/4096). This lowers bootstrap time to 200-500ms. It was basically free real estate lol
It isn't done yet (not worth the heat in the summer), going to finish it in the fall. Have been accumulating cloud credits to do CDNA3/4 validation in the meantime (If anyone has some to offer do let me know!)
It's neat but very dry, uses semantic contracts so you tell it what kind of mult you need and it chooses the validated best backend. If you're doing lots of smaller ops (512, 1024) it will use custom WMMA/MFMA kernels, dual issue, and grouped dispatch to land >70x over hip-direct.
https://github.com/doublemover/RNS8/
- https://belfortlabs.com/blog/belfort-partners-with-lg-on-enc... - https://belfortlabs.com/blog/encrypted-fraud-detection-with-...
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.
Typical use cases are for doing biometric authentication without giving your biometric information, or sensitive queries using medical information. Apple has homomorphic encryption in image search. You can use your own photos encrypted into the cloud to search for landmarks in the image without revealing photos.
People can also coordinate and compare information without sharing sensitive data.
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.
Would be interesting to read it (and no judgement!)
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.
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.
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.
That for some cases they are still all show doesn't prove everything is all show.
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.
If cloud can sell compute to enterprise that can only use FHE, then they will not give a fuck if the ad goons are disgruntled about it.
Ads doesn’t care until something affects them, GCP doesn’t.
I'm now curious. Who are you?
I don't see the need to do computations on the encrypted data here, which is what FHE would provide in addition to traditional encryption.
> and don't have access to the account anymore.
This would be trouble with or without FHE. Even if the backend wouldn't need to decrypt the data, the user will - so as soon as you actually want to show something in the app, you have the same key management problems as without FHE.
In order to do the data mining in order to make those kinds of claims, traditionally you'd need to have access to the data.
As you point out, encrypted-at-rest is solved. But what about when it's not at rest?
In-use and in-transit is when FHE kicks in. Sure, you could just do it locally, but then you miss out on the aggregate data mining. Not for advertisers, but because it helps women with their bodies. The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
I don't know much about period tracking apps, but is this really the main reason people install those apps? Wouldn't you be able to get similar results by simply monitoring (on-device) the cycle of the person who uses the app for a few months?
How do those apps work before they have millions of users?
All the warnings I've seen about period tracking apps were about unexpected data collection of the entered data. This would be pretty silly if the data collection was integral to what the user expects the app to do.
> Sure, you could just do it locally, but then you miss out on the aggregate data mining.
Ok, a bit of a technical question about FHE here: My understanding of FHE was that you have input data encrypted with some key (plus auxiliary inputs, if needed, that are not encrypted), then you do operations on that data and get a result that is (still) encrypted by that same key.
No questions there as long as you're dealing with a single key.
But the whole point of aggregation and data mining is to combine data from many different users, i.e. inputs that are encrypted by many different keys. Does that work with FHE at all? And if yes, by which key is the aggregation result encrypted?
I don't see how that would work without either "moving" data from one key to another - which would be practically equivalent to decryption - or getting a result that is simultaneously encrypted by all user keys, i.e. practically useless because no one could individually decrypt it.
> The compelling product claim is "we literally cannot read your period data." Not "we pinky swear not to" but "we actually really really actually can't!"
You could obviously read the data enough to do aggregations on it.
If you can do that for "good" purposes, what stops you to use the same aggregation algorithm for advertisers - except pinky promises again?
> "we literally cannot read your period data."
If the purpose is aggregated data for statistic, then surely the only per-user data they need centrally can already be aggregated (to some degree) on the device, e.g. send back only statistical-distribution variables of the personal data, for distributions over the 3-4 months? And at some point, does the service need to keep collecting data, once the model is good enough (at predicting ovulation etc)?
Another concern would be: If they are building a model, using user data, why should they own the model and thus monetise it (i.e. sell it back to its users) when users get no compensation for supplying that data in the first place.
A flow-tracking app should just stick to that, and purchase the model (for a fee) from a third party. The third party should concern itself with how to get the data without being able to leverage its position as a flow-app maintainer to trick or mislead the majority of its users into giving them free data.
Homomorphic encryption is cool technology, but I'm really not sure what problem it solves.
The Swift one is interesting, but I don't understand why the transaction needs to be encrypted, or more specifically why the model can only run in the encrypted part of the pipeline.
Super cool tech, but I guess I just don't see the application yet.
And wow, I worked with Marc a decade ago, small world.
People are giving them everything. Their thoughts, feelings, intentions, company IP... It's a fucking gold mine.
There's just too much value in retraining on that data and even if there wasn't, the feds lean so heavily on Google search histories to get convictions I am certain there will be pressure to prevent any mass market services from adopting this.
This is the same kind of thing. The crazy overhead of FHE means it's not practical for almost any kind of real world computational work. But having it available at all is undeniably technically impressive, and some of that sense of technical refinement bleeds over into your opinion of Google as a whole.
Incidentally, being a business client of Google's who actually uses this (or, say, quantum computing) for $BUSINESS_FEATURE would garner the same kind of positive attention, independently of whether it's technically a good idea.
Finally, if the overheads come down to the level where they are still significant but not insane, GCP is in a great position.
Not that I'm a frequent customer, either before or after.
But at the same time HE is classic Google promotion fodder. Really difficult technical problem! That’s what gets people promoted at Google. Nobody actually cares about it or will use it? That also is what gets people promoted at Google. Because Google only employs “the smartest people on earth” which means people who solve difficult problems. Difficult problems - not problems that need solving.
The most private AI is the one running on my own hardware, not in some giant data center.
I want that too, but you gotta ask yourself the question how efficient that is compared to running it in a datacenter shared with everybody else.
As an aside: The computation might also not be the same e.g. ever-changing hidden pre-prompts, security/safety checks blocking or degrading responses, unavoidable verbosity to simple questions, watermarking, collection of prompt data to build user profiles for the purpose of advertising - and we haven't even seen in-response adverts, or sponsor-biased responses yet, but no doubt it's coming.
Using regular encryption and secure enclaves, there are already providers that are roughly 2x the cost of normal providers. For example, https://tinfoil.sh/
Heh yes absolutely, but there is some nuance.
Secure Enclave still requires you to trust the operator and also trust that it’s configured properly, supply chain is secure, etc.
The beauty of FHE is that it doesn’t rely on the compute being secure. All you need to secure are things you already have control over as a client.
I agree with you it’s still way too slow to be generally useful. (By general, I mean practical for arbitrary computation — you can relax the requirement and have fast homomorphic encryption if you only do specific kinds of operations).
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
- The output can reveal information to the provider, which homomorphic encryption would have protected
- Inference is running on GPUs - so its moreso nvidia than amd/intel, but this is just a nit
So homomorphic encryption exists so the user doesn't need to do work to figure out if the provider could be adversarial.
That's why they provide cryptographic attestation that the open model they're running is exactly what they advertise without any modifications.
That combined with GPU confidential compute should protect your LLM prompt and output.
E2E encryption (including homomorphic encryption) have the nice property that there are much fewer ways for things to fail.
(Tangentially, attestation is basically trying to ensure that faults are obvious, but that doesn’t reduce the probability of the faults in the first place).
1. A ZDR clause is "trust me bro". You have zero way of verifying their pinky-promise.
2. A ZDR clause is still subject to the old-classic "government, court or administrative order" catch-all clause. :)
3. "Even with ZDR enabled, Anthropic may retain data where required by law or to address Usage Policy violations. If a session is flagged for a policy violation, Anthropic may retain the associated inputs and outputs for up to 2 years, consistent with Anthropic’s standard ZDR policy." (I quoted Anthropic, I'm sure all the others have similar).
> 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?
I was very much surprised and asked. give me demerits for the way of asking.
but the question stays: how come an encryption scheme inflates data by this order of magnitude and needs GB sized keys?
where can I learn about this? not the nutty gritty details proofs and all but an overview. assume I did my CS masters in the 1990s and worked as SW eng ever since.
NVM, I asked Gemini
https://share.google/aimode/pqZO1VF3cGTeetamq
> 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
We've banned this account.
We've asked you politely, several times over the years to observe the guidelines. In recent times you've been acting more than ever like they don't apply to you. They do apply to you just as they apply to everyone and it's time we made that clear.
In this case, someone has raised the notion that sometimes someone can hold two legitimate positions that are contradictory, which, as the original commenter mentioned, is attributable to F. Scott Fitzgerald but has been noted in different ways by many reputable philosophers and scholars through history. In your reply, you've effectively sneered at anyone who wrestles with such contradictions, including the parent commenter, then gone on to use the term “garbage person” for another human.
Other terms you've used in past months include:
most humans are dumber than a box of rocks
literally not figuratively the 1930s Nazis
fools
idiots
morons
cretins
It's always a challenge for us to fairly moderate political discussions on HN. We want people to be able to discuss important, difficult topics and ideally to work together to develop ways of making the world better. HN is a place for builders, and that can and should include building solutions for the difficult problems the world faces, or at least talking about how we could. Identifying and critiquing flaws in the ideas and actions of one's political or intellectual opponents is fine and healthy.
Continually demeaning individuals or groups with dehumanizing or contemptuous epithets and caricatured characterizations makes this place toxic and drives away people who come here with the expectation of having intellectually gratifying discussions with reasonable people.
When people continue to break the guidelines, even after several appeals from moderators, we have to assume they have no intention to use the site as intended and in fact want to be banned. If that's not the case, you can email us at hn@ycombinator.com to discuss how you can demonstrate that.
My takeaway is that you were personally offended by the (mild) attack on Cook and Apple products, likely because you use them and associate them with your self worth, and responded in defense of ego.
I say this based on observing casual usage of 'fool' and 'idiot' and other terms a myriad of times in other threads with no action or response.
I'm glad to see a moderator in the wild but JFC not attacking a windmill.
It’s true that this comment alone was not sufficient for a ban; as I explained in my comment, it’s the pattern of comments, particularly in recent days, continuing a pattern over years that we’ve posted several warnings about. And it's the fact that other users who have a solid track record of contributing positively to HN are being driven away by that style of rhetoric from this user, or at least signaling that these comments were beyond the pale.
Our role here is to make HN a place where reasonable people feel they can have intellectually gratifying discussions that are of higher quality than elsewhere online. When we see signs that good contributors are being driven away by an escalating pattern of toxic comments from a user who has been warned many times over a decade, it would be negligent of us not to act.
As we say all the time, we don’t see every guidelines breach, or reply every time we do; there are over 10,000 comments posted each day and only two of us. But when we see an ongoing pattern of abuse, we always issue warnings, then ban the account if it continues. You’re always welcome to email us (hn@ycombinator.com) when you see anything egregious, or at least just flag the comment. That's what people do when they wholeheartedly support moderation.
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.
Seems counterproductive to their stated aim of privacy.
This is what I don't like about all this "I'm not touching you" privacy tech, also including the new trend of nonvoluntary on-device processing.
They pretend "privacy" was a primary goal of it's own, completely detached from any reasons why you would want to have it.
Then they go on gloriously holding up the flag of privacy, while at the same time enabling all the things that you wanted to have privacy against in the first place.
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 I am curious if anyone can think of any use cases for this as it currently stands? For every idea I can think of, I can think of another solution that would probably be a better solution at current slowdown in cost from using homomorphic encryption.
For their two examples...
1) For the "will they click the add" one, how would anyone verify that the model I am uploading of myself is remotely accurate? And can't they learn my characteristics by running them against very specific ads that pinpoint my preferences?
2) For the "Do you have heart disease" one, why not just generating a billion datapoints (or more). The user can download the compressed data of this huge sample of points and then just enter their data on their own side and find the point that is closest (if not an exact match) to their own data?
I'm not pulling apart the idea of homorphic encryption, I'm just curious if anyone can think of a really compelling use case for it given it 10^3 to 10^6 greater compute cost?
Run the encoding and first and last layer of the LLM on the users machine. They could still get some idea of the content but really couldn’t easily get the actual text back.
Anyone know if that’s viable?
> 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.
So a caller could run a program on untrusted hardware and trust that the hardware actually ran the program?
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?
This is where we believe Belfort can make a real difference: enabling organizations to compute on sensitive data while preserving strong privacy guarantees. And FHE doesn’t necessarily mean relying on Google, AWS, or Azure for encrypted compute. Companies can run FHE on their own infrastructure, allowing them to process their clients’ data privately while maintaining control over their systems and keys.
These applications are our initial focus, and over time, we aim to expand the range of use cases that FHE can unlock.
1. generate a 512 x 512 random (u32) matrix A, and
2. generate a 512-dimensional rounded (to the nearest integer) Gaussian, say of standard deviation 10, e.
The ciphertext is then [A, b :=As + e + 2^8 m].
To decrypt, you compute b - A
s to recover 2^8 m + e. You can then recover m, as e << 2^8 with high probability.Anyway, if you have two of these ciphertexts, you can sum them together to get
[A1 + A2, (A1 + A2)s + (e1 + e2) + 2^8 (m1 + m2)]
this decrypts to m1 + m2, so you can recover homomorphic sums (or scalings by small integers).
Multiplication is more complex, so I won't get into it here. But the high level from the above example is that you could have someone compute arbitrary linear functions of your data without them knowing what your data is.
I though (when I tried to understand it) that some part of the HE inflates some component of the result?
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 :)
Even in that case, they see data they are getting to be worthwhile enough for their other lines of business.
Reality: our computers will be used as distributed AI calculators
But there is more to it. Teams like us at Belfort, we are working to make FHE practical for organizations that want to deploy it for their own use cases, including on infrastructure they control themselves. Even in these setups, FHE can enable applications that would otherwise be blocked by regulatory, privacy, or compliance requirements.
> 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/
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.
I still worry about how an ad company is going to approach this. Each of these advancements could be used to put ads in more places.
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.
Besides, FHE is not always about using somebody else's server. At Belfort, in addition to FHE acceleration, we also explore such uses cases; https://belfortlabs.com/blog/encrypted-fraud-detection-with-... https://belfortlabs.com/blog/belfort-partners-with-lg-on-enc...
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
The point of FHE is that you only ever send encrypted data. So if you trust that Google hasn't broken the encryption algorithm entirely, they never access the plaintext.
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.
Ah yes, their history of innovations! Thanks to Gemini for making a list for me over at https://share.gemini.google/vx9lE5dEJ1L7
The list contains more than 6 chapters with multiple entries each.
Google has truly been very innovative in destroying privacy online.
Which is to say, I believe that google is strongly implying the falsehood of "no one at Google can read your stuff."
- 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.
nah bro...the solution here is to not trust google
I don't understand why we need to bring LGBTQ+ into everything
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.
that being said, you can construct IND-CPA secure homomorphic encryption schemes from factoring-based assumptions iirc, so this isn't a fundamental obstacle.
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 price that HE is paying is essentially "have to run every possible contributing computation", which means it has to scale extremely badly for anything real world complex
The server doesn’t need any information to perform inference.
Hopefully then it's not too hard to believe you can build an encryption scheme and operations where `dec(enc(X) ⊞ Y) = X + Y` and `dec(enc(X) ⊠ Y) = X × Y`. If these operations can also be composed, i.e. homomorphism, then they're Turing complete! You can turn any function f(X) into a ciphertext version `dec(F(enc(X))) = f(X)`. It can't leak any information about X, because you only ever provided enc(X). For example you transform 'branching' code to something which traverses every path, and paths which do nothing will still appear to randomize the ciphertext, because you can't invent operations that distinguish which path is taken, because it's a secure ciphertext.
Modern homomorphic encryption uses more complex encryption schemes and primitives, to achieve thousands/hundreds rather than millions of times slower than f. Nonetheless it's impossible for the provider to gain a single bit of information about X.