Comment by ketzu | Hacker News Reader

Comment by ketzu | Hacker News Reader

Parent Full thread

After putting some thought into this during a deeper comment chain somewhere, I thought about it this way:

FHE is equivalent to circuits, i.e., every circuit has a representation as a FHE. I feel like the idea is: Circuits can perform arbitrary computations on a limited size input, but not on an arbitrary size inputs. Loops are not a problem, as they are an implementation detail. Unbounded output is not possible on a touring machine that halts for all inputs of size s limited by some constant. There exists a circuit that would compute the same thing, as you can take the (binary encoded) results of the touring machine and just create a truth table from that, which describes a circuit. Circuits are interesting because they are usually limited in size.

So you compile your program into a circuit of a fixed size and can then compute solutions of this size. If you are interested in larger problems, you compile your program into a larger circuit. E.g., a function returing an 32bit integer and taking 20 32bit integers as parameters can be represented this way (without infinite loops, but those aren't covered by turing machines either), no matter the computation within that function.

edit: correction, obviously a circuit can not represent all partial functions, only functions (i.e., all inputs have an output).

No, you cannot convert an arbitrary Turing machine to a circuit. Not even if you assume a bounded input size. Not even if you assume just one single allowed input, because you might not be able to know if that Turing machine ever terminates on that input.

And loops are not an implementation details. Bounded loop are, one might argue, an implementation detail, but unbounded loops are precisely _the_ problem: in general it is impossible, given an arbitrary Turing machine (or an arbitrary C, Python, whatever Turing-complete language program), to give an upper bound on the number of iterations its loops will require.

Seems like I didn't put enough thought into it and my computability class has been too long ago!

In hindsight it's kind of obvious: All functions computed by circuits must be a function an can not be a partial function, because a circuit can't output nothing.

ketzu isn't claiming that one can always describe a Turing machine using addition and multiplication only, only that one can describe a Turing machine's map on bounded inputs using addition and multiplication on the input only.

And that's precisely what I challenged. You can't even describe a Turing machine on one single input (using whatever operations you like) if you're not able to determine if that machine is going to terminate. And in general you are not (at least, I am not; if you are, I happen to have a few Turing machines for which I'd be happy to pay to know if they're going to terminate or not; good money, I promise).

You hold a misconception.

The task is not that; instead we assume that we already have a table that correctly describes the TM's maps from bounded input to output when they terminate. His claim is that this table can be expressed as a function in addition and multiplication with the input as operands. To be more precise, with the input and constant numbers (arbitrarily choosable while designing the description of the function) as operands.

Incidentally,

> You can't even describe a Turing machine on one single input (using whatever operations you like)

is false, we can simply encode it as the encoded tuple of the TM and the input; this is a standard construct when we talk about simulating TMs with a UTM.

> The task is not that; instead we assume that we already have a table that correctly describes the TM's maps from bounded input to output when they terminate. His claim is that this table can be expressed as a function in addition and multiplication with the input as operands.

Ok, if the task is this then everything is very easy, I agree. I was commenting on a much harder task, i.e., converting a generic TM to a function adding and multiplying the inputs. That is something you can't do.

> is false, we can simply encode it as the encoded tuple of the TM and the input; this is a standard construct when we talk about simulating TMs with a UTM.

I don't see how that disproves my assertion. I was saying something different, which has to do with your (correct) first assertion: a TM cannot establish if another TM is going to terminate on a certain input.

> I was saying something different

It's important to be precise with language; said encoding is a description of a given TM on a particular input, since a map exists from it to the space of outputs union DOESNOTTERMINATE. Now, whether or not this map is a computable function is a different question.

Alan Turing proved that a solution to the halting problem cannot exist. Per Wikipedia:[0]

> A key part of the proof was a mathematical definition of a computer and program, which became known as a Turing machine; the halting problem is undecidable over Turing machines.

It cannot be possible to “map” a Turing machine with a finite number of operations. Without true decision trees and loops, FHE isn’t Turing complete. At minimum, there needs to be a concept of a conditional jump—if X, jump to instruction Y.

You can unravel some programs into a finite set of instructions, but that doesn’t make FHE Turing complete.

Take the following code, for example:

    function f(x):
      while x == 1:
        do nothing
      return x

For a machine to be Turing complete, it must be able to run that function. FHE can’t do that, by definition; it would reveal information about the input.

[0]: https://en.wikipedia.org/wiki/Halting_problem

You can simulate that program you gave on a finite circuit because you can simulate it on your computer which is a finite circuit.

Your computer has circuitry that is capable of being reused. It isn’t a simulator; it could, in theory, run that loop ad infinitum.

FHE can’t reuse circuitry. There’s no concept of, “based on the output, we now need to plug it back in and repeat.” Instead, it has to literally repeat that circuitry for every possible loop.

You could re-run FHE until some condition fails. This is what your CPU does BTW.

Again - the only reason you shouldn’t do that in homomorphic encryption is because this way you will leak run duration information.

You can’t do that—that reveals timing information.

Would you say that this circuit was fully homomorphic if, for all inputs, the processor appeared to be doing the same work?

That is to say? If X = 1 or X = 2 the processor did not appear to “do nothing” but, instead, performed an operation on an encrypted string that was constant time?

I’m not really sure what you’re asking. By definition, FHE cannot be Turing complete. A Turing machine must be capable of performing operations that cannot be handled in constant time, and for which the timing reveals information about the input. That is a fundamental feature of Turing machines; it’s the whole basis for how they came about.

Why can't FHE be capable of performing unbounded operations?

There’s no way to do a FHE style system with branching unless all branches are indistinguishable from one another. All branches must execute in the same amount of time, otherwise statistical analysis will leak information.

Forget Turing completeness for a second, that’s not actually what you want for a FHE style system. You want computational indistinguishability which can’t be achieved without side-channel resistance.

Some of the original work around FHE implies the researchers were applying ML models. If you had a complicated enough ML model (e.g. of a person) you could simulate a computer in that model. The assertion that FHE with just multiplication and addition is Turing-complete is true, and this is one proof.

If you can think of something besides encoding a Turning machine's state as NN weights I am very interested. Perhaps encoding a quantum circuit somehow? A technically correct but intractable solution would be simulating the quantum state of every atom in a silicon circuit.

Reply on news.ycombinator.com