# In simulation proofs of MPC, why could random oracle extract adversary's input?

I am learning the simulation-based security proofs in MPC, and have read the great tutorial "How to simulate it" by Prof. Lindell.

Here's my understanding about why we need to "extract adversary's input" in writing simulation proofs against malicious adversaries (please correct if I am wrong): For a malicious adversary, it is not guaranteed to follow the protocol, so "a simulator is able to extract A's input" means "as long as the protocol does not abort, we could be sure that A must be inputting something valid (i.e. following the protocol) ". So the "extracting input" step is crucial for writing proofs against malicious adversary. If we can extract A's input, everything left are just the same as the semihonest proofs.

The example of changing semihonest OT into malicious OT with ZKP meets my above understandings, because ZKP could prove the prover's correct behaviors, and could extract the prover's input. However, when reading other proofs, I found it hard to understand why could random oracles extract inputs as well.

E.g. Proof of Theorem 1 in  says "SIMs builds two tables T1 = (x, φ) and T2 = ((h, t), ψ) to answer the hash queries to H1 and H2 respectively". How could SIMs know the inputs to H1 and H2? If SIMs could do that, does it mean we can extract inputs simply by asking the parties to hash their inputs, and any semihonest-secure protocols become malicious-secure ones by simply introducing an extra hash-input step (which is obviously not true) ?

I know there must be some basic mistakes in my understandings, and would be very grateful if someone could point it out. Thanks.

 Jarecki S, Liu X. Fast secure computation of set intersection.

This is exactly what makes the random oracle model an idealized model. If $$H$$ is a hash function in the standard model, an adversary can run $$H$$ "in its head", and this will be inscrutable to a simulator. But in the random oracle model, the only way to evaluate the hash function $$H$$ is through a well-defined oracle interface. The simulator gets to play the role of this interface! -- just like it is allowed to play the role of the honest parties.
I think you will find that the examples in "How to Simulate It" will have this property. You can't just ask an adversary to query $$H$$ on their private input, but then do nothing with the result. They have to interact with $$H$$ in a way that gives the simulator an advantage, when the simulator is allowed to observe all queries to $$H$$ and also observe the rest of the protocol messages too. I'm sure you will see that in "How to Simulate It", the simulator will "cross-reference" these tables $$T_1$$ and $$T_2$$ with protocol messages sent by the adversary, in order to extract.