Homomorphic encryption implementation

Re:Homomorphic encryption implementation by SilasX on Friday May 23, 2014 @02:31AM (#7788221)

That method doesn't get around the limitations of writing the plainfunction directly as FHE operations. The FHE interpreter still acts on the equivalent of opcodes, with known behavior corresponding to each code, every bit as apparent as knowing that you're ANDing two HE values. It's obfuscated, but no more than you can do with plain ol' obfuscated code.

[ Parent | on HN ]

Re:Homomorphic encryption implementation by darkmighty on Friday May 23, 2014 @03:41AM (#7788353)

I still don't see your point. Afaik, we could have something like:

Input = FHE(data|opcode1|opcode2|...|opcodeN)

The server won't know what are the (opcode1|...|opcodeN) if the FHE scheme is properly implemented. That is, the actual implementation would be something like

Output' = InverseHE(FHEval(Input'))

Output = Output' - randomness

I.e. the server can't uncover the (data,opcode1,...,opcodeN) tuple by enumeration if exp(randomness) is large enough. Is this what you had in mind?

[ Parent | on HN ]

Re:Homomorphic encryption implementation by SilasX on Friday May 23, 2014 @01:18PM (#7790264)

See my reply to nullc: https://news.ycombinator.com/item?id=7790084

It still has to execute the opcodes, revealing the computation in that sense. All the randomness adds (if I understand your example) is additional "junk" computation, that's unrelated to the output you really want -- but that's no different than you can already get with "plain" FHE, with obfuscation, or with adding pointless operations to a regular program.

[ Parent | on HN ]