> If you send your server two encryped numbers and ask to multiply them for you, the server may send you their addition instead, or just encrypt some constant it chooses and send you that.

That's not what FHE intends to solve. You have the exact same problem with any kind of remote processing, encrypted or not. I don't see why you think it's important to point out the obvious.

Because, sometimes it is said that fully homomorphic encryption means that you don't have to trust the server anymore. And as you pointed out, that is not true. You have to trust a server less.

These are orthogonal definitions of trust, though.

Trusting the server to perform the operation I asked it to is an entirely different domain than trusting the server with the knowing the input and output data of the operation.

This is the key point that the original commenter was trying to elucidate.

Well put.

I've been following FHE casually for a while now and I definitely thought it meant I didn't have to trust the server anymore.

I didn't know it. They taught me something. That's why it's important to point out the obvious, it's not obvious to everyone.

The poster is just making sure people understand precisely what this does and does not guarantee. That’s always one of the most important things to know about a cryptographic primitive.

Whenever you see a cryptographic protocol that does not include authentication you should be highly suspicious. In most cases there are some smart attacks.

Gnull just pointed out that FHE by itself does not provide authentication so you still need some additional means to achieve that.

FHE doesn't provide authentication of correctness (i.e. that the correct operation was performed) but you can verify its signature. You can still verify that it's your data but you just can't verify what they've done with it.

With the use cases of FHE though that just is not a major downside. Instead if you rely on some consensus protocol you can get a reasonable guarantee of correctness. If a random N out of M available operators are selected and all produce the same result or hash of a result, you can be reasonably sure that the expected operation was performed.

Additionally, as the "master" who can actually read the FHE data, for most non-trivial tasks I suspect there is often a proof or heuristic you can use to reasonably judge whether the result is correct or at the very least reasonable which should stave off a significant portion of the avenues for attack.

Because it is crucial in practice, right?

Is it, though? OTOH I cannot think of a single service or provider thereof that makes any guarantees about the trustworthiness of the actual calculation being performed as suggested by the GP.

While trusted computing could be used for such verification, I'm not aware of any commercial real world implementation. I'd be genuinely happy to be made aware of one, though, so please feel free to point me to one.

Most of the major cloud providers have trusted/confidential compute offerings.

To my knowledge, those make no guarantee that the work done is correct, only that it is private and secure (which is effectively the same root assumption as with FHE).

The offerings that use SGX or SEV also guarantee correct execution as long as you perform remote attestation of the code before execution and as long as you trust the CPU manufacturer.

> If you send your server two encryped numbers and ask to multiply them for you, the server may send you their addition instead, or just encrypt some constant it chooses and send you that. And you can't check that your data was processed the way you want.

I don't see how authenticated encryption would address that. In fact, I don't see how any kind of encryption can address that. Every way I can see to verify that the server is actually carrying out the correct operation would work without encryption.

Authentication proves that you are talking to the right server and that the result you got back from the server was the result it tried to send you, but whether or not that was what it was supposed to send you is out of scope for encryption.

I think they mean verifiable. As in, an encryption where you could verify that A*B==C given only the encrypted values of A, B, and C.

I don't want a database I can query privately, I want to be able to lease my idle hardware out to strangers on the internet and vice versa without needing to trust them.

Would this work better in a decentralized environment with high number of consensus nodes? The protocol will work to ensure the outputs are more trusted

Is FHE CPA secure? Is that even a sensible question to ask wrt FHE?

Couldn’t you just sign the payload to verify authenticity?

Usual signatures do not allow homomorphic operations on the signed values. You will have to use special fully homomorphic signatures (FHS) for that.

Suppose you did this and encrypted + signed your values with FHE and FHS as Sign(Encrypt(x)) and Sign(Encrypt(y)). Now you want to add x and y. For that, you will have to run the homomorphic addition of Encrypt(·) values using homomorphic operations of Sign(·), i.e. you do Encrypt(x) + Encrypt(y) inside Sign(·), not just x + y.

This means that the overheads introduced by FHE and FHE do not just add up, they get composed (as in composition of functions). This will be a terrible blow-up in performance. I guess, for this reason people try to build authenticated FHE that will have the properties of FHE + FHS but as a one, more efficient block.

Then your input is signed. And now what? How does this authenticate the output?

I suppose you can just rerun the function? Most cases I know don’t have a large nested set of operations.

Then you didnt need to do the remote operation... Some operations are verifiable though in less time than doing the whole computation.

Maybe in the way the operation affects the signature?