Live data from Hacker News

A very casual introduction to Fully Homomorphic Encryption (2012)

blog.cryptographyengineering.com

11–20 of 22 posts

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#11

Was there ever a followup blogpost?

Nope. Seny Kamara managed to write such a good series that you're better off treating his posts as the follow up:

http://outsourcedbits.org/2012/06/26/applying-fully-homomorp...

http://outsourcedbits.org/2012/09/29/applying-fully-homomorp...

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#12
Oh hey, this is something I've actually done some real work on!

> Just try converting that into a circuit

Hmm. I think this article is a little behind the times. Loops are not a problem with Homomorphic encryption, as we can create circuits that work exactly like a transistor-based CPU.

In fact, I've got an implementation of one that I've been working on here: https://github.com/mmastrac/oblivious-cpu

The trick to making this work is that you may not know how long the computation is going to take, so you need to either add a set number of iterations to run (ie: clock cycles), or send back encrypted updates as you run to give your trusted computer a chance to determine when the calculation has finished.

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#15

Oh hey, this is something I've actually done some real work on! > Just try converting that into a circuit Hmm. I think this article is a little behind the times. Loops are not a problem with Homomorphic encryption, as we can create circuits that work exactly like a transistor-based CPU. In fact, I've got an implementation of one that I've been working on here: https://github.com/mmastrac/oblivious-cpu The trick to ma…

The very next line of Matt's blog post explains this:

> I mean, it’s not impossible to unroll loops (if you know the maximum number of iterations), but the resulting circuit is not likely to be practical. Moreover, this isn’t purely an issue with the use of circuits, but rather with the use of encrypted data. No matter what computational model you employ, you’re always going to have difficulty with things like control flow changes that depend on input data that the executing party can’t see.

If you want to add in interaction, then you have other far more efficient schemes for achieving such FHE, like garbled circuits

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#16

Oh hey, this is something I've actually done some real work on! > Just try converting that into a circuit Hmm. I think this article is a little behind the times. Loops are not a problem with Homomorphic encryption, as we can create circuits that work exactly like a transistor-based CPU. In fact, I've got an implementation of one that I've been working on here: https://github.com/mmastrac/oblivious-cpu The trick to ma…

I'm not sure what specific scheme you have in mind, but while FHE for Turing machines does exist, it is really, really hard to instantiate. A construction with some restrictions and requiring a massive amount of preprocessing is given in Goldwasser et al.'s famous paper on reusable garbled circuits, and it already uses succinct functional encryption as a building block; and for the stronger notion of FHE for TM you basically need obfuscation. So thinking about implementing any of this seems somewhat premature to me.

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#17
post #4
post #3

One 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?

Could you spare a minute to comment of the current state of functional encryption?

Is it practical on an intel cpu ?

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#18
post #5

Earlier quoted context omitted.

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.

That might be it - Thanks.

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#19
post #8
post #3

One 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"?

Pretty much. Like mmastrac's comment (currently top). I hadn't realised people had got so far.

What you'd like to be able to do, is something like encrypt the code of a tor node in such a way that it could be run by an untrusted hosting provider, without breaking the security of tor.

Re: A very casual introduction to Fully Homomorphic Encryption (2012)

#20
post #17
post #4

Earlier 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?

Could you spare a minute to comment of the current state of functional encryption? Is it practical on an intel cpu ?

If you want fully general functional FE, then no; constructions are based on something called "indistinguishability obfuscation", a crypto primitive that a) we're not sure exists b) has conjectured constructions that are ultra ultra ultra slow.
Post reply on HN