5 ms·
> 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 i
by qayxc 5y ago
> 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.
- klempotres 5y agoBecause it is crucial in practice, right?
- qayxc 5y agoIs 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.
- anonymousDan 5y agoMost of the major cloud providers have trusted/confidential compute offerings.
- jacoblambda 5y agoTo 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).
- warkdarrior 5y agoThe 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.
- aliasEli 5y agoWhenever 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.
- jacoblambda 5y agoFHE 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.
- funcDropShadow 5y agoBecause, 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.
- qayxc 5y agoThese 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.
- jnwatson 5y agoThis is the key point that the original commenter was trying to elucidate. Well put.
- throwaway894345 5y agoI've been following FHE casually for a while now and I definitely thought it meant I didn't have to trust the server anymore.
- api 5y agoThe 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.
- ketralnis 5y agoI 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.