Rust中的阈值密码库.zip

# Tofn (t-of-n): a threshold cryptography library in Rust Tofn provides the following: * An implementation of the [GG20](https://eprint.iacr.org/2020/540.pdf) threshold-ECDSA protocol. * A general-purpose SDK (software development kit) to facilitate the development and use of threshold cryptography protocols such as GG20. # Setup * Get the latest version of Rust stable (currently 1.53.0). * Clone this repo. * You might need to install the GMP library. On MacOS: ``` brew install gmp ``` On Ubuntu: ``` sudo apt install libgmp-dev ``` # Demo and tests Tofn integration tests (in `tests/integration`) serve to demo use of the library. (These demos would be in the `examples` directory but we want them to run automatically as part of the normal test sequence.) Demo test hieararchy: ``` tests └── integration ├── multi_thread └── single_thread └── malicious ├── keygen.rs ├── sign.rs └── timeout_corrupt.rs ``` ## Multi-threaded tests Tests in `multi_thread` are a more accurate reflection of typical use than those in `single_thread`. Threshold cryptography protocols are multi-party computation protocols: parties exchange messages with one another and perform local computations in order to reach consensus on an output of the protocol. The `multi_thread` tests aim to simulate such an environment by spawning an independent thread for each party. These tests simulate network communication by using concurrency primitives from Rust's standard library (`sync::mpsc`) to pass messages between threads. Run all multi-threaded integration tests: ``` cargo test --test integration -- multi_thread ``` ## Single-threaded tests Multi-threaded code is inherently more difficult to write, test, and debug. For development purposes it is useful to have a single-threaded reference implementation so as to eliminate concurrency as a source of bugs. Most examples of tofn functionality occur in `single_thread`. Some tests illustrate the fault protection and identification properties of the GG20 protocol. These tests require one or more parties to act maliciously during protocol execution. Malicious behaviour is enabled in tofn via the `malicious` crate feature---see [Malicious crate feature](#malicious-crate-feature) below. Run all single-threaded integration tests with only honest parties: ``` cargo test --test integration -- single_thread ``` Run all single-threaded integration tests, including those with malicious parties: ``` cargo test --all-features --test integration -- single_thread ``` Tests using `malicious` display extensive log messages to the terminal. For example: ``` Jul 23 10:46:04.933 INFO integration::single_thread::malicious::sign: sign with malicious behaviour R6BadProof Jul 23 10:46:13.005 INFO tofn::gg20::sign::malicious: malicious peer 3 does R6BadProof Jul 23 10:46:13.273 WARN tofn::gg20::sign::r7::happy: peer 0 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] Jul 23 10:46:13.312 WARN tofn::gg20::sign::r7::happy: peer 1 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] Jul 23 10:46:13.350 WARN tofn::gg20::sign::r7::happy: peer 2 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] Jul 23 10:46:13.391 WARN tofn::gg20::sign::r7::happy: peer 3 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] Jul 23 10:46:13.429 WARN tofn::gg20::sign::r7::happy: peer 4 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] Jul 23 10:46:13.470 WARN tofn::gg20::sign::r7::happy: peer 5 says: pedersen proof wc failed to verify for peer 3 because ['wc' check fail] ``` # Two types of tofn user The tofn SDK supports two types of users: 1. Library users 2. Protocol implementers ## Library users A typical library user should need code from only the following tofn modules: * `tofn::sdk::api` and `tofn::collections` for generic tofn SDK. * `tofn::gg20` for protocol-specific code for the GG20 protocol. See [Demo and tests](#demo-and-tests) for working code to illustrate use of tofn. See the [Tofnd](https://github.com/axelarnetwork/tofnd) crate for usage of tofn in production code. The core of the API is a generic `Protocol` type: ```rust pub enum Protocol<F, K, P> { NotDone(Round<F, K, P>), Done(ProtocolOutput<F, P>), } ``` where * `F` is the type of the final output of the protocol. (Examples: keygen produces a secret key share, sign produces a signature.) * `K`, `P` are marker types for typed collection indices. See [Typed collection indices](#typed-collection-indices) below. Specific protocol implementations provide constructors that create a new concrete `Protocol` instance. Examples: * `tofn::gg20::keygen::new_keygen` returns a new keygen protocol * `tofn::gg20::sign::new_sign` returns a new sign protocol Each party in the protocol has its own `Protocol` instance. A `Protocol` can be either `Done` or `NotDone`. The `Done` variant has `ProtocolOutput` data defined like so: ```rust pub type ProtocolOutput<F, P> = Result<F, ProtocolFaulters<P>>; pub type ProtocolFaulters<P> = FillVecMap<P, Fault>; ``` where the `ProtocolOutput` variants are: * `Ok(output)`: the protocol completed in happy path, producing `output` of type `F` (eg. secret key share or signature). * `Err(faulters)`: the protocol completed in sad path. An output of type `F` could not be produced because one or more parties was malicious. `faulters` is a list of malicious parties detected by this `Protocol` instance during execution. `ProtocolFaulters` is a custom collection type describing the faulty parties. The `NotDone` variant has `Round` data with several core methods used to exchange messages and progress the protocol to the next round: * `bcast_out`, `p2ps_out`: outgoing messages to be sent over the network to other parties. * `msg_in`: incoming messages received over the network from other parties. * `expecting_more_msgs_this_round`: have we received all the incoming messages we expect for this round? Library users use this method to determine whether it's safe to progress to the next round. * `execute_next_round`: proceed to the next round of the protocol with whatever messages we have received so far. Consumes `self` and returns a new `Protocol` instance for the next round. * If a message from party `A` is missing then `A` is flagged as a faulter. This is how tofn facilitates timeout faults. ## Protocol implementers A typical protocol implementer would use code from the following tofn modules: * `tofn::sdk::api` * `tofn::sdk::implementer_api` * `tofn::collections` See the `tofn::gg20` module for an example of a protocol built using the tofn SDK. The intent of the implementer API is to allow the protocol implementer to concentrate only on the stateless math functions for each round that map ``` (current_state, incoming_messages) -> (next_state, outgoing_messages) ``` The implementer does not need to worry about generic work such as collecting incoming messages, deserializing data, identifying generic faults (timeout, message corruption), etc. Concretely, protocol implementers must supply: * A constructor for a party in the protocol. Examples: `gg20::keygen::new_keygen`, `gg20::sign::new_sign`. * For each round of the protocol: a struct implementing the `Executer` trait from one of the modules `no_messages`, `bcast_only`, `p2p_only`, `bcast_and_p2p` according to which types of messages are expected in this round. # All messages delivered to all parties Tofn requires that all messages be delivered to all parties. Specifically: * **p2p:** Any p2p message from `A` to `B` should also be delivered to all other parties `C`. * **self-delivery:** A party `A` treats a missing message from any party `P` the same way, even if `P=A`: party `P` is declared as a faulter. # Support for multiple shares per party Tofn