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 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 server doesn’t need any information to perform inference.

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

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...

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/

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)

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.

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.

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.

"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!

https://belfortlabs.com/blog/belfort-partners-with-lg-on-enc...

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.

I'm now curious. Who are you?

Thats the embarrassing part, you know “don’t be evil” went out the window years ago, yet still think you’re making a difference with your little bit shifting games. As if the moment the work you do bumped against against revenue it would hold.

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.

- 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.

With wildlife management, you're dealing with health issues, like rabies outbreaks. That requires privacy. You want to preserve customer confidentially because it's often embarassing. And private property cameras and sensors can leak information about private citizens or kids in a neighborhood without appropriate social and technical protections.

There are hundreds of fields like this. Not just healthcare and policing.

We are likely to see a lot of the hardware required for this to move out into space data centers for batch jobs at least.

And along with that calls for reduced RF and light pollution like StarLink.

And that is going to be helped by a large number of angry liberal citizens who are being riled up about data centers. And that anti-tech rhetoric is already leading to violent responses and debate.

Which hurts the liberal cause for universal healthcare. Conservatives see angry liberal anti-tech actions and tarnish calls for healthcare reform and other liberal causes.

The people who are going to benefit the most from cheaper PPML in orbiting data centers are in many ways making it harder for the rest of us.

It's not a small issue, and I wish I had had the reputation to reduce the anger.

It seems unrelated to PPML. But PPML is a clever political gas pedal to get space control.

Cost-wise the only viable private compute is local compute. It's more expensive than cloud, but true private compute in the cloud is definitely pricier.

Homomorphic encryption got significantly efficient with the first few iterations, but I don't really see the necessary orders of magnitude savings coming soon. You could reduce this by some partial encryption schemes (e.g., for LLMs you need a handful of basic operations) but a better alternative already exists: multi-party computation.

Source: I did research in this area in the past.

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.

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/

Would be interesting to read it (and no judgement!)

> 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.

They can still and should still continue using great security practices while protecting E2EE data.

>Of course, I would also advise almost all users not to self-custody cryptocurrency.

There's no point in crypto if you're not holding your own keys. It's the antithesis of cryptocurrency. People can have highly secure self custody wallets on a modern iPhone or Pixel. And their seeds would have been safe if LastPass didn't have terrible security or they used long passphrases.

You can separate Cook is a garbage person from the fact that he makes good stuff which quite frankly not an accomplishment insofar as it's the same trade-off virtually everyone makes. They aren't even contradictory you are simply weighing a trade off in moral outrage vs personal gain.

> 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 [email protected] 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 ([email protected]) when you see anything egregious, or at least just flag the comment. That's what people do when they wholeheartedly support moderation.

"I know the raw materials for these clothes come from slavery, but hey, what can I do ? They're the softest."

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.

Which is to say, I believe that google is strongly implying the falsehood of "no one at Google can read your stuff."

> 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.

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.

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 :)

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 - As 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?

CS = 2^8 m + e

here, S = [-s, 1] is a padded version of the initial secret. So recast everything as a linear equation (matrix) equation

CS = 2^8m + e

Without getting into too much details, one can define a "product" * such that

(CC)(SS) = (2^8m + e)(2^8m + e)

This becomes a "degree 2" equation. Mildly faking the details for simplicity, one can expand it out not in terms of A, b, but in terms of three components A, b, c, where c is the "degree 2" component. So here things have inflated. But there is also a technique to shrink this back down to a linear equation.

This shrinking process requires some auxiliary data, namely an encryption of SS under S. it is not the problematic part of HE though. Instead, data movement (say a circular rotation by k indices) also requires some "fixing up", though here involving an encryption of rot^i(S) under S.

This is more problematic, as there are many different rotations (often on the order of thousands), and you naively need a piece of auxiliary data for each of them (vs one for multiplication). There are ways to shrink the required number of keys, but in general they're the "heavyweight" part of FHE.

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.

> 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/

Reality: our computers will be used as distributed AI calculators

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.

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?

The most private AI is the one running on my own hardware, not in some giant data center.

Using regular encryption and secure enclaves, there are already providers that are roughly 2x the cost of normal providers. For example, https://tinfoil.sh/

Using this other encryption, the provider has neither need nor capability to decrypt it on their end, so the user gets extra security.

the main difference is where the guarantee comes from. for FHE, it comes from math, which we trust. for secure enclave, the guarantee comes from Intel/AMD's promise that their hardware is bugless/backdoorless, and that your adversary cannot directly inspect bits in the hardware

- 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).

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).

> 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

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.

I don't understand why we need to bring LGBTQ+ into everything

- 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.

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.

nah bro...the solution here is to not trust google

Even in that case, they see data they are getting to be worthwhile enough for their other lines of business.

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.

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.

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.

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 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?

So, by that logic, we are potentially looking for a problem space where their is a large amount of data that is too large to even be paged through by the client, and where the FHE would actually make financial sense relative to downloading it?

I'll think about that, but nothing immediately comes to mind.

So a caller could run a program on untrusted hardware and trust that the hardware actually ran the program?

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.

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.

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.

Suggesting alternative approaches to such large corporations is not straightforward. Their IT and security teams cannot afford to risk handling sensitive financial data in plaintext. No manager would readily approve a solution that offers additional functionality at the cost of deviating, even slightly, from well-established compliance practices. Encryption is therefore fundamental to how these systems operate.

The challenge arises when these institutions need to perform computations or checks on such encrypted data. Decrypting the data, even under controlled conditions and with trained personnel, is operationally complex, introduces additional risk, and can create a significant compliance burden.

This is where FHE offers a compelling solution. We demonstrate how a check can be performed directly on encrypted transactions against a known blacklist, without requiring the underlying transaction data to be decrypted.

P.S. It is great to work with Marc :)

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?

(in the voice of George Bush Jr.) And it feels good doing it.

Google doing something private is like Microsoft doing something secure.