Preprocessing with Yao GC?

[ghost]

Is there a way to send the garbled circuits to the client during the preprocessing phase (rather than online phase) for Yao GCs? If so, how can this be done?

[mkskeller]

You can use -O to garble as much at once as possible, but that only works if you don't reveal any data on the way. Other than that, there isn't really a separation also because there isn't easy preprocessing to be done as the preprocessing is function-dependent.

[ghost]

If the function is known ahead of time, is there a way to allow preprocessing for one of the garbled circuit implementation?

[mkskeller]

You'd need to go into the C++ code. See also this thread: https://gitter.im/MP-SPDZ/community?at=60d5e5c1258ebf6d92eb17a8

The larger issue is that the one-shot view of garbled circuits is more narrow than the MP-SPDZ bytecode. The bytecode allows the function to be dependent on previous outputs, for example branching on a revealed value. This makes the function dependent in the input. This is the reason that the garbling and execution are tangled.

[ghost]

The linked thread is very helpful, and I'm aiming to do exactly what user Johannes mentioned. I'll look into modifying the c++ code to do this.

To confirm, what Johannes mentioned in your link is doable right (saving the circuits to a file, then loading them at runtime)? From the Yao process_receiver_inputs code, it doesn't seem like it depends on any of the intermediate input. So, what you mentioned regarding garbling and execution being tangled is primarily a design choice (rather than being a barrier in the current code), is that correct?

[mkskeller]

To confirm, what Johannes mentioned in your link is doable right (saving the circuits to a file, then loading them at runtime)? I don't see any inherent issues.

From the Yao process_receiver_inputs code, it doesn't seem like it depends on any of the intermediate input.

Indeed. I referred to the convcbit function in both YaoEvalWire and YaoGarbleWire. This function is used to convert circuit outputs to values that allow branching. They thus invoke communication.

So, what you mentioned regarding garbling and execution being tangled is primarily a design choice (rather than being a barrier in the current code), is that correct?

I'm not sure what you consider the difference between design choice and a barrier in the code. They run inherently independently, so as long as no instruction involving communication comes up, the whole garbled circuit will appear in the mentioned buffer when you call program.execute().

[ghost]

To confirm, if no instruction involves communication, then the whole garbled circuit will appear in gates, which would allow it to be saved/loaded from a file (and subsequently executed independently afterwards)?

Which instructions involve communication? (specifically, does if_else, +, -, < involve communication?)

[mkskeller]

To confirm, if no instruction involves communication, then the whole garbled circuit will appear in gates, which would allow it to be saved/loaded from a file (and subsequently executed independently afterwards)?

Yes

Which instructions involve communication? (specifically, does if_else, +, -, < involve communication?)

None of these. The ones I can think of are input instructions and said conversion instruction. The conversion instruction is potentially called for a number of things I can't completely list (largely related to control flow) but certainly not just executing arithmetic functions.

[ghost]

Fantastic. Thank you so much for your assistance -- this was extremely helpful.