upvote

points

by esseph7 hours ago |
comments
upvoteby numpad03 hours ago|
next
[-]
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.

reply
upvoteby u1hcw9nx6 hours ago|
prev|
next
[-]
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.

reply
upvoteby Foobar85685 hours ago|
parent|
[-]
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.
reply
upvoteby bilekas4 hours ago|
parent|
next
[-]
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.
reply
upvoteby Foobar85684 hours ago|
parent|
[-]
LWE estimator isn't a proxy for this?
reply
upvoteby anon2911 hours ago|
parent|
prev|
[-]
Math literacy needs to become standard for computer scientists. These takes are so bad
reply
upvoteby Foobar856826 minutes ago|
parent|
[-]
Or reading papers on the subjects, and playing with implementing FHE search.
reply
upvoteby gruez6 hours ago|
prev|
next
[-]
>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.

reply
upvoteby cwmma6 hours ago|
prev|
[-]
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.
reply
upvoteby esseph5 hours ago|
parent|
[-]
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.

reply
upvoteby jayd162 hours ago|
parent|
next
[-]
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.
reply
upvoteby cassonmars5 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby bilekas4 hours ago|
parent|
prev|
next
[-]
> 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
upvoteby anon2911 hours ago|
parent|
prev|
[-]
Well yeah... You do the initial encryption yourself by whatever means you trust
reply