Hacker News Reader

Comment by djcapelis | Hacker News Reader

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

View on HN

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.

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.

but it is a natural consequence of one, right? [i am asking; it seems like it might be, but i have no technical insight]

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 Read that one instead.

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.

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.

This is a much better explanation, thank you.

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.

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.

> 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

I'm not familiar with the details of bitcoin, but in that case aren't (some of) the inputs to the function hidden not the function itself.

Proof of work techniques are relying on forcing the other party to run a known function in order to prevent various attacks. If the other party can't verify the result they would be no use.

Reply on news.ycombinator.com