Hacker News Reader

Comment by esseph | Hacker News Reader

Everything about this in my head screams "bad idea".

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

View on HN

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.

So one of the potential use cases mentioned is for secure data transfer.

So here's my question: Could FHE hardware be used to extremely quickly and reliably secure something like a database connection?

I looked through Gemini, and it says the following:

"Zama are building libraries that use FHE accelerators to allow "Confidential Smart Contracts" or private AI queries. You could send a highly sensitive health query to an AI, and the AI hardware would process it and send the answer back without the AI company ever knowing what you asked."

https://www.zama.org/

Which is why I ask. Because if you have a backdoor into the hardware, as either a corporation or a government, then you can get access to those "very sensitive and fully secured communications".

They also discuss a crypto / smart contracts use case, and advertise " securing L1 or L2".

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.

But you leak all type of information and and the retrieve either leak even more data or you'll end up with transferring a god knows amount of data or your encryption is trivially broken or spend days/month/years to unencrypt.

I don't know how you got these ideas but when you crack it, do make sure to write a post about it. Can't wait for that writeup.

LWE estimator isn't a proxy for this?

Math literacy needs to become standard for computer scientists. These takes are so bad

Or reading papers on the subjects, and playing with implementing FHE search.

Yeah it pretty clear that many people in the HN community have no idea what this is and yet they have takes. It makes me wonder...

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

I updated another comment above, but FHE is also being advertised for use for securing crypto transactions and smart contracts.

"We believe that just like the internet went from zero encryption with HTTP to encrypting data in transit with HTTPS, the next natural step will be to use FHE to enable end-to-end encryption by default in every application, something we call HTTPZ"

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.

But can you trust the hardware encryption to not be backdoored, by design?

That's my point, this sounds like a way to create a backdoor for at-rest data.

By design, you don't trust it. You never hand out the keys so there's no secret to back door. The task is never unencrypted, at rest or otherwise.

You can if the manufacturer has a track record that refutes the notion, and especially if they have verifiable hardware matching publicly disclosed circuit designs. But this is Intel, with their track record, I wouldn't trust it even if the schematics were public. Intel ME not being disable-able by consumers, while being entirely omitted for certain classes of government buyers tells me everything I need to know.

Well yeah... You do the initial encryption yourself by whatever means you trust

There is no hardware encryption or decryption.

I encrypt some data and keep the key. I send the encrypted data to you (probably some cloud provider). I tell you to do some operations on the data. I don't tell you the key or what the data is or what the operations mean. You send the results back to me. I use the key to decrypt them.

You have helped me with my compute task, but the data you have is totally meaningless without the key, and only I have the key.

It's hard to believe that it's possible to make encryption where this can do useful work, but it is.

> That's my point, this sounds like a way to create a backdoor for at-rest data.

I get the feeling honestly it seems more expensive and more effort to backdoor it..

Reply on news.ycombinator.com