Hacker News

Just to level set here. I think its important to realize this is really focused on allowing things like search to operate on encrypted data. This technique allows you to perform an operation on the data without decrypting it. Think a row in a database with email, first, last, and mailing address. You want to search by email to retrieve the other data, but don't want that data unencrypted since it is PII.

In general, this solution would be expensive and targeted at data lakes, or areas where you want to run computation but not necessarily expose the data.

With regard to DRM, one key thing to remember is that it has to be cheap, and widely deployable. Part of the reason dvds were easily broken is that the algorithm chosen was inexpensive both computationally, so you can install it on as many clients as possible.

I'm also thinking of what happens when quantum computing becomes available.

But when homomorphic encryption becomes efficient, perhaps governments can force companies to apply it (though they would lose their opportunity for backdooring, but E2EE is a thing too so I wouldn't worry too much).

> how it could be used against the users and device owners

Same here.

Can't wait to KYC myself in order to use a CPU.

> how it could be used against the users

We are not anymore their clients, we are just another product to sell. So, they do not design chips for us but for the benefit of other corporations.

3. Unskippable ads with data gathering at the CPU level.

I don't think it's applicable to DRM because you eventually need the decrypted content: DRM is typically used for books, music, video, etc., you can't enjoy an encrypted video.

I think eGovernment is the main use case: not super high traffic (we're not voting every day), but very high privacy expectations.

1. The private key is required to see anything computed under FHE, so DRM is pretty unlikely.

2. No, anyone can run the FHE computations anywhere on any hardware if they have the evaluation key (which would also have to be present in any FHE hardware).

See: https://news.ycombinator.com/item?id=47323743

It's not related to DRM or trusted computing.

No, because of the fundamental limitation of DRM. Content must be delivered as plaintext.

Regarding DRM, You could use stream ciphers and other well understood cryptography schemes to use a FHE chip like this to create an effectively tamper-proof and interception proof OS, with the FHE chip supplementing normal processors. You'd basically be setting up e2ee between the streaming server and the display, audio output, or other stream target, and there'd be no way to intercept or inspect unencrypted data without breaking the device. Put in modern tamper detection and you get a very secure setup, with modern performance, and a FHE chip basically just handling keys and encapsulation operations, fairly low compute and bandwidth needs. DRM and attestation both, as well as fairly dystopian manufacturer and corporate controls over devices users should own.

My thought is half cynical. As LLM crawlers seek to mop up absolutely everything, companies themselves start to worry more about keeping their own data secret. Maybe this is a reason for shifts like this; as encrypted and other privacy-preserving products become more in demand across the board.

This is quite the opposite, better than we have.

It raises the hurdle for those looking to surveil.

If a tree falls in the forest and no one is around to hear it, does it make a sound?

This is primarily for cloud compute I'd imagine, AI specifically. As it's generally not feasible/possible to run the state of the art models locally. Think GDPR and data sovereignty concerns, many demand privacy and can't use services without it.

Regarding DRM I don't see how it'll survive "Camera in front of the screen" + "AI video upscaling" once the second part is good enough. Can't DRM between the screen and your eyes. Until they put DRM in Neuralink.

There are applications that are currently doing this without hardware support and accepting much worse than 95% performance loss to do so.

This hardware won’t make the technique attractive for ALL computation. But, it could dramatically increase the range of applications.

Current FHE on general CPUs is typically 10,000x to 100,000x slower than plaintext, depending on the scheme and operation. So even with a 5,000x ASIC speedup you are still looking at roughly 20-100x overhead vs unencrypted compute.

That rules out anything latency-sensitive, but for batch workloads like aggregating encrypted medical records or running simple ML inference on private data it starts to become practical. The real unlock is not raw speed parity but getting FHE fast enough that you can justify the privacy tradeoff for specific regulated workloads.

Now we know why Intel more or less abandonned SEAL and rejected GPU requests.

Most of modern machine learning is effectively linear algebra. We can achieve semantic search over encrypted vectors if the encryption relies on similar principles.

If you're interested in "private AI", see Confer [0] by Moxie Marlinspike, the founder of Signal private messaging app. They go into more detail in their blog. [1]

[0] https://confer.to/

[1] https://confer.to/blog/2025/12/confessions-to-a-data-lake/

If encrypted outputs can be viewed or used, they can be reverse-engineered through that same interface. FHE shifts the attack surface, it does not eliminate it.

FHE is impractical by all means. Either it's trivially broken and unsecured or the space requirements go beyond anything usable.

There is basically no business demand beside from sellers and scholars.

> In a world where privacy is constantly being eroded intentionally by governments and private companies, I think this will NEVER, ever reach any consumer grade hardware.

Why not when government can just force companies to backdoor their hardware for them. That way users are secure most of the time except from the government (until the backdoor in intel's chips gets discovered anyway), and users have a false sense of security/privacy so people are more likely to share their secrets with corporations and the government gets to spy on people communicating more openly with each other.

Arguably this is less useful for consumer hardware in the first place. This is mostly useful when I don’t trust the service provider with my data but still need to use their services (casting my vote, encrypted inference, and so forth)

Not going to happen anytime soon, as the modern M4/ARM unified memory with on-chip GPU is years ahead of Intel. The software ecosystem is slowly growing to leverage this chip architecture, and due to the annoying PC RAM, SSD, and RTX GPU shenanigans it is no longer the lower value option.

The PC market was made shitty enough this year, that Mid/High class Mac Pro/laptops are actually often a better value deal now (if and only if your use-case is covered software wise.)

Intel does plan on a RTX + amd64 SoC soon, but still pooched the memory interface with a 30 year old mailbox kludge. Intel probably wont survive this choice without bailouts. =3

It is a bad idea but not in the way you think. FHE hardware don't decrypt data on-chip. It's like using the Diffie-Hellman key exchange for general computation. The data and operations stay encrypted at any given moment while outside your client device.

The textbook example application of FHE is phone book search. The server "multiply" the whole phonebook database file with your encrypted query, and sends back the whole database file to you every time regardless of queries. When you decrypt the file with the key used to encrypt the query, the database is all corrupt and garbled except for the rows matching the query, thereby causing the search to have practically occurred. The only information that exists in the clear are query and the size of entire database.

Sounds fantastically energy-efficient, no? That's the problem with FHE, not risks of backdooring.

In FHE the hardware running it don't know the secrets. That's the point.

First you encrypt the data. Then you send it to hardware to compute, get result back and decrypt it.

>If you need to trust the encryption and trust the hardware itself, it may not be suitable for your environment/ threat model.

Are we reading the same article? It's talking about homorphic encryption, ie. doing mathematical operations on already encrypted data, without being aware of its cleartext contents. It's not related to SGX or other trusted computing technologies.

In theory you only need to trust the hardware to be correct, since it doesn't have the decryption key the worst it can do is give you a wrong answer. In theory.