Multi-Party bit authentication spec

[jschneider-bensch]

This PR aims to implements a multi-party bit authentication protocol, i.e. a protocol, where a party can input some number of bits and receive information theoretic MACs on those bits under the global keys of the other parties. The other parties receive the corresponding local keys, which allow them to verify the MAC later on.

To this end the contributions are:

• A simplification of the API for commitments. It's no longer possible to attempt to open a commitment to an invalid value. Instead the opening information includes the expected value and successful opening returns that value. This makes for a safer API since it makes it impossible to continue with an invalid commitment.
• A round synchronization mechanism, since otherwise early parties can move on to the next phase of the protocol soon for later parties to catch up.
• An implementation of message broadcasting via a public bulletin board. The idea is that to broadcast a value, a party sends commitments to that value to all other parties as well as the opening of the commitment to the broadcast bulletin board. Other parties all receive the same opening from the bulletin board, so it is ensured that all commitments contain the same value, since there can be no two commitments that are valid for the same opening.
• A multi-party coin-flipping protocol where each party commits to some randomness and broadcasts the commitments to the other parties. (This is SINE's approach and seems to work even in the active security setting because of the specific commitment we use. In general it's not secure since an attacker could perhaps duplicate other parties commitments and bias the output this way.)
  Fixes [MPC] Specify multi-party coin-flipping protocol #67
• An specification of the information-theoretic MAC. Fixes [MPC] Specify information theoretic MAC #49
• A passively secure two-party bit authentication protocol using the OT protocol as a correlated OT.
• Building on all the above the specification of the actively secure multi-party bit authentication protocol. Fixes [MPC] Specify n-party authenticated bit protocol #66

This means that the protocol as a whole will not be actively secure as long as the two-party bit authentication is only passively secure and we introduce an additional trust assumption with the public bulletin-board. These issues are perhaps to be addressed in a follow-up.

---

When running the protocol on the example circuit (cargo run --example run_mpc), I've noticed the base OT is quite slow, due to it using non-optimized speccy implementations of its ECC & AEAD components. When generating a l authenticated bits between the parties, an additional 2 * rhoauthenticated bits have to be generated, where rho is the statistical security parameter in bits, to do the statistical checks for malicious security. This means it is ill-advised to call bit_auth repeatedly with small values when the calls could be batched. For testing the basic functionality I also experimented with what I call "ludicrous mode", i.e. basically without security, by setting computational and statistical security to the smallest possible value. This helped me find some logic bugs, but some might also slip by this way, since the statistical tests of course rely on a high number of samples to find cheaters (or buggy participants as the case may be).

[franziskuskiefer]

Thanks. I left a couple comments. But mostly for me to understand and to maybe add some clarifications. Let's get it in on Monday.