Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One note, first of all: I made one mistake, the algorithm is not secret in HE (the HE runtime has to know it). Only the input data is guaranteed to be secret.

I'm not sure what you mean. This is how HE works, at a high level. The whole point is that you're doing public operations on secret data on a machine that can never know what the data was, nor what response it gave you. Furthermore, the point of HE is also that you know that your data remained secret regardless of how the HE runtime was implemented, as you just send it encrypted information.

Making it more efficient by giving it access to the decrypted data would defeat the whole point. Making it more efficient by optimizing based on the actual data would allow your data to leak through timing side-channels, again defeating the whole point.

Basically, HE refers to computing schemes where DECRYPT(ALGORITHM(ENCRYPT(X)) == ALGORITHM(X). You send [ALGORITHM, ENCRYPT(X)] to the runtime, and it gives you Y. DECRYPT(Y) is then the result of your computation.

As far as we know, this is indeed hopelessly slow, and there is no guarantee that we will ever find fast secure HE primitives.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: