A very casual introduction to Fully Homomorphic Encryption (2012)
blog.cryptographyengineering.com
A very casual introduction to Fully Homomorphic Encryption (2012)
1–10 of 22 posts
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#2Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#3One limitation of Homomorphic encryption, as far as I can see, is that there is no way for the encrypted program to choose to communicate some data in the clear.
Which means it can't be used to allow an untrusted party to run your encrypted server, and have the server communicate with parties that it doesn't trust. Which is what most servers do. Unless I'm mistaken, or there has been an advance?
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#4One limitation of Homomorphic encryption, as far as I can see, is that there is no way for the encrypted program to choose to communicate some data in the clear. Which means it can't be used to allow an untrusted party to run your encrypted server, and have the server communicate with parties that it doesn't trust. Which is what most servers do. Unless I'm mistaken, or there has been an advance?
There is no encrypted program, there is encrypted data. You can operate on this data, and it will reflect on the plaintext after decryption. I think what you're thinking about is functional encryption?
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#5One limitation of Homomorphic encryption, as far as I can see, is that there is no way for the encrypted program to choose to communicate some data in the clear. Which means it can't be used to allow an untrusted party to run your encrypted server, and have the server communicate with parties that it doesn't trust. Which is what most servers do. Unless I'm mistaken, or there has been an advance?
There is no encrypted program, there is encrypted data. You can operate on this data, and it will reflect on the plaintext after decryption. I think what you're thinking about is functional encryption?
I'm not thinking of functional encryption. I thought I'd read somewhere a plan to use homomorphic encryption with an encrypted program by simply applying an interpreter to it.
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#6Earlier quoted context omitted.
There is no encrypted program, there is encrypted data. You can operate on this data, and it will reflect on the plaintext after decryption. I think what you're thinking about is functional encryption?
I'm not thinking of functional encryption. I thought I'd read somewhere a plan to use homomorphic encryption with an encrypted program by simply applying an interpreter to it.
You're not thinking of Indistinguishability Obfuscation per chance?
https://blog.cryptographyengineering.com/2014/02/21/cryptogr... seems an interesting article.
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#7Was there ever a followup blogpost?
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#8One limitation of Homomorphic encryption, as far as I can see, is that there is no way for the encrypted program to choose to communicate some data in the clear. Which means it can't be used to allow an untrusted party to run your encrypted server, and have the server communicate with parties that it doesn't trust. Which is what most servers do. Unless I'm mistaken, or there has been an advance?
Can you tell us what do you mean by "encrypted program"?
Do you mean that if all operations of a universal Turing machine were homomorphic then you can encryt the code with a hard-coded input and get an encrypted output?
Can you also elaborate on your server example? I don't understand what you are trying to do. (Whats an "encrypted server"?
Re: A very casual introduction to Fully Homomorphic Encryption (2012)
#9One limitation of Homomorphic encryption, as far as I can see, is that there is no way for the encrypted program to choose to communicate some data in the clear. Which means it can't be used to allow an untrusted party to run your encrypted server, and have the server communicate with parties that it doesn't trust. Which is what most servers do. Unless I'm mistaken, or there has been an advance?
There is no encrypted program, there is encrypted data. You can operate on this data, and it will reflect on the plaintext after decryption. I think what you're thinking about is functional encryption?
The distinction between program and data is not a sharp one, since f(x) = apply() = eval_x(f) (where eval_x takes the description of some program f and runs it on the constant input x). You can use this equivalence to compute f(x) where f is in plaintext and x is encrypted (ordinary HE), f and x are both encrypted (but apply is plaintext), or f is encrypted but x is not (so we can derive eval_x). In every case, however, the output is encrypted.
In general, this is only of theoretical interest, since the interpreter apply and the specialized interpreter eval_x are large, complicated programs.