This PR implements the SimpleOT protocol core due to Chou and Orlandi.
To summarize, an Oblivious Transfer protocol is between a sender and receiver, where the sender has two inputs v_0 and v_1 and the receiver has a choice bit b. The goal of the protocol is for the receiver to learn v_b and for noone to learn anything more. In particular the sender should not learn what the receiver's choice was and the receiver should not learn v_(1-b).
~It's not yet integrated into the communication harness, i.e. the parties do not actually send and receive OT messages yet, hence it's a draft.~
I've removed the ideal functionality and attempts to generically call subprotocols either via this ideal functionality or run them among the parties. I did not manage to implement it correctly and it was getting more and more complicated, when it would have only really served for testing purposes.
Instead, parties now directly call subprotocol routines, e.g. ot_receive, ot_send which trigger the required messages and there is no way to simulate subprotocols anymore. I will instead focus on testing subprotocol components and results directly when I've implemented them using the parties (as opposed to via an ideal functionality).
To be clear, that means Party::run will not "do the right thing" until I've ultimately implemented the whole MPC protocol and, e.g. what it does now is just to demonstrate a round of dummy OT sessions that would not happen in the final protocol.
The PR also includes a number of new dependencies required by the OT, like the spec for ChaCha20Poly1305 and attempts to clean up and unify dependencies across the workspace. There is nothing special there, the main work happens in the mpc-engine crate.
This PR implements the SimpleOT protocol core due to Chou and Orlandi.
To summarize, an Oblivious Transfer protocol is between a sender and receiver, where the sender has two inputs
v_0andv_1and the receiver has a choice bitb. The goal of the protocol is for the receiver to learnv_band for noone to learn anything more. In particular the sender should not learn what the receiver's choice was and the receiver should not learnv_(1-b).~It's not yet integrated into the communication harness, i.e. the parties do not actually send and receive OT messages yet, hence it's a draft.~
I've removed the ideal functionality and attempts to generically call subprotocols either via this ideal functionality or run them among the parties. I did not manage to implement it correctly and it was getting more and more complicated, when it would have only really served for testing purposes. Instead, parties now directly call subprotocol routines, e.g.
ot_receive,ot_sendwhich trigger the required messages and there is no way to simulate subprotocols anymore. I will instead focus on testing subprotocol components and results directly when I've implemented them using the parties (as opposed to via an ideal functionality).To be clear, that means
Party::runwill not "do the right thing" until I've ultimately implemented the whole MPC protocol and, e.g. what it does now is just to demonstrate a round of dummy OT sessions that would not happen in the final protocol.The PR also includes a number of new dependencies required by the OT, like the spec for ChaCha20Poly1305 and attempts to clean up and unify dependencies across the workspace. There is nothing special there, the main work happens in the
mpc-enginecrate.Fixes #48