5 ms·

You're actually looking at it backwards. The data is the black box. The operations being conducted on it are sometimes unknown by the system conducting them,

You're actually looking at it backwards. The data is the black box. The operations being conducted on it are sometimes unknown by the system conducting them, but this isn't a requirement for homomorphic encryption or necessarily the point. You might want to try wikipedia's explanation: http://en.wikipedia.org/wiki/Homomorphic_encryption http://en.wikipedia.org/wiki/Homomorphic_encryption

fragsworth 15y ago
The paper mentioned that the functions in the financing applications might be proprietary, and it would be the point in their case to keep this logic hidden.
- djcapelis 15y ago
  Yes, many homomorphic schemes seem to enable privacy of the operations being conducted as well as the data being operated on, but that isn't what defines a fully homomorphic scheme.
  - andrewcooke 15y ago
    but it is a natural consequence of one, right? [i am asking; it seems like it might be, but i have no technical insight]
    - djcapelis 15y ago
      I don't know. I'm not sure if it's been proven one way or another. Hopefully someone with more insight comes along. I remember Gentry's scheme working this way, but I'm not sure if all fully homomorphic ones do. Some of the partially homomorphic ones don't, I think. Edit: Someone with more insight came along. This post explains the real issue going on here much better: http://news.ycombinator.com/item?id=2827465 http://news.ycombinator.com/item?id=2827465 Read that one instead.
      - psykotic 15y ago
        What am I missing? Code is data. Fix a Boolean circuit for a universal interpreter unrolled to whatever depth is needed. Send your program code and its input as the data payload and have it passed to the circuit.
- emily37 15y ago
  My understanding is that fully homomorphic encryption allows proprietary logic to stay hidden by allowing a company to perform its proprietary logic on a customer's data without seeing the data. If I have a function f and you have some data x, and you want to compute f(x), then without fully homomorphic encryption, either I have to give you my function or you have to give me your data. With fully homomorphic encryption, you can give me your encrypted data and I can use that as input to my function, so that you don't learn what my function is and I don't learn what your data is. I give you the output of the function, and you can decrypt it to learn what f(x) is without learning f.
  - djcapelis 15y ago
    This is a much better explanation, thank you.
  - jjjabrams 15y ago
    I'd love to f your (x)....
  - justincormack 15y ago
    In a lot of use cases for this I also need to be able to verify you did apply f too, which may be hard. There is clearly a huge lack of trust here. Thinking of financial service applications like trading. I think the use case where I want to compute f(x) in an untrusted (eg cloud) environment is probably the real potential use case. The (slightly odd) book Translucent Databases gives some more use cases, such as working with anonymised statistics.
    - aquark 15y ago
      Interesting -- how can you verify that f() was applied when by definition you don't know what the output of f() should be? If someone was trying to be dishonest then they could fake any attribute of f() that you could likely verify.
      - dexen 15y ago
        > If someone was trying to be dishonest then they could fake any attribute of f() that you could likely verify. Not necessarily. For example: you can't fake bitcoin transactions, as each one requires significant amount of comuptation. Basically faking would require exactly the same work (modulo problems with SHA1 itself, but that's another matter). This is used for other purposes as well: http://en.wikipedia.org/wiki/Proof_of_work http://en.wikipedia.org/wiki/Proof_of_work

fragsworth 15y ago

The paper mentioned that the functions in the financing applications might be proprietary, and it would be the point in their case to keep this logic hidden.

djcapelis 15y ago
Yes, many homomorphic schemes seem to enable privacy of the operations being conducted as well as the data being operated on, but that isn't what defines a fully homomorphic scheme.
- andrewcooke 15y ago
  but it is a natural consequence of one, right? [i am asking; it seems like it might be, but i have no technical insight]
  - djcapelis 15y ago
    I don't know. I'm not sure if it's been proven one way or another. Hopefully someone with more insight comes along. I remember Gentry's scheme working this way, but I'm not sure if all fully homomorphic ones do. Some of the partially homomorphic ones don't, I think. Edit: Someone with more insight came along. This post explains the real issue going on here much better: http://news.ycombinator.com/item?id=2827465 http://news.ycombinator.com/item?id=2827465 Read that one instead.
    - psykotic 15y ago
      What am I missing? Code is data. Fix a Boolean circuit for a universal interpreter unrolled to whatever depth is needed. Send your program code and its input as the data payload and have it passed to the circuit.
emily37 15y ago
My understanding is that fully homomorphic encryption allows proprietary logic to stay hidden by allowing a company to perform its proprietary logic on a customer's data without seeing the data. If I have a function f and you have some data x, and you want to compute f(x), then without fully homomorphic encryption, either I have to give you my function or you have to give me your data. With fully homomorphic encryption, you can give me your encrypted data and I can use that as input to my function, so that you don't learn what my function is and I don't learn what your data is. I give you the output of the function, and you can decrypt it to learn what f(x) is without learning f.
- djcapelis 15y ago
  This is a much better explanation, thank you.
- jjjabrams 15y ago
  I'd love to f your (x)....
- justincormack 15y ago
  In a lot of use cases for this I also need to be able to verify you did apply f too, which may be hard. There is clearly a huge lack of trust here. Thinking of financial service applications like trading. I think the use case where I want to compute f(x) in an untrusted (eg cloud) environment is probably the real potential use case. The (slightly odd) book Translucent Databases gives some more use cases, such as working with anonymised statistics.
  - aquark 15y ago
    Interesting -- how can you verify that f() was applied when by definition you don't know what the output of f() should be? If someone was trying to be dishonest then they could fake any attribute of f() that you could likely verify.
    - dexen 15y ago
      > If someone was trying to be dishonest then they could fake any attribute of f() that you could likely verify. Not necessarily. For example: you can't fake bitcoin transactions, as each one requires significant amount of comuptation. Basically faking would require exactly the same work (modulo problems with SHA1 itself, but that's another matter). This is used for other purposes as well: http://en.wikipedia.org/wiki/Proof_of_work http://en.wikipedia.org/wiki/Proof_of_work