2 unstable releases
new 0.1.0 | Nov 18, 2024 |
---|---|
0.0.0 | Feb 15, 2024 |
#548 in Cryptography
85 downloads per month
110KB
2K
SLoC
Threshold Schnorr implementation based on FROST IETF Draft
FROST is state of art protocol for Threshold Schnorr Signatures that supports 1-round signing (requires signers to commit nonces ahead of time), and identifiable abort.
This crate provides:
- Distributed Key Generation (DKG)
FROST does not define DKG protocol to be used. We simply re-export DKG based on CGGMP21 implementation whencggmp21-keygen
feature is enabled, which is a fairly reasonable choice as it's proven to be UC-secure. Alternatively, you can use any other UC-secure DKG protocol. - FROST Signing
We provide API for both manual signing execution (for better flexibility and efficiency) and interactive protocol (for easier usability and fool-proof design), seesigning
module for details. - Trusted dealer (importing key into TSS)
- reconstruct_secret_key (exporting key from TSS)
This crate doesn't support (currently):
- Identifiable abort
The crate is wasm and no_std friendly.
How to use the library
Distributed Key Generation (DKG)
First of all, you need to generate a key. For that purpose, you can use any secure
(preferably, UC-secure) DKG protocol. FROST IETF Draft does not define any DKG
protocol or requirements it needs to meet, so the choice is up to you. This library
re-exports CGGMP21 DKG from cggmp21-keygen
crate when cggmp21-keygen
feature
is enabled which is proven to be UC-secure and should be a reasonable default.
CGGMP21 DKG is an interactive protocol built on round_based
framework. In order
to carry it out, you need to define the transport layer (i.e. how the signers can
communicate with each other). It's simply a pair of stream and sink:
let incoming: impl Stream<Item = Result<Incoming<Msg>>>;
let outgoing: impl Sink<Outgoing<Msg>>;
where:
Msg
is a protocol message (e.g.,keygen::msg::threshold::Msg
)round_based::Incoming
andround_based::Outgoing
wrapMsg
and provide additional data (e.g., sender/recipient)futures::Stream
andfutures::Sink
are well-known async primitives.
Transport layer implementation needs to meet requirements:
- All messages must be authenticated
Whenever one party receives a message from another, the receiver should cryptographically verify that the message comes from the claimed sender. - All p2p messages must be encrypted
Only the designated recipient should be able to read the message
Then, construct an MpcParty:
let delivery = (incoming, outgoing);
let party = round_based::MpcParty::connected(delivery);
Now, you can finally execute the DKG protocol. The protocol involves all signers who will co-share a key. All signers need to agree on some basic parameters including the participants’ indices, the execution ID, and the threshold value (i.e., t).
use givre::ciphersuite::{Ciphersuite, Secp256k1};
let eid = givre::keygen::ExecutionId::new(b"execution id, unique per protocol execution");
let i = /* signer index (0 <= i < n) */;
let n = /* number of signers taking part in key generation */;
let t = /* threshold */;
let key_share = givre::keygen::<<Secp256k1 as Ciphersuite>::Curve>(eid, i, n)
.set_threshold(t)
.start(&mut OsRng, party)
.await?;
Signing
FROST signing can be carried out either interactively with the help of round_based
framework, or manually.
Manual Signing
In the manual signing, as the name suggests, you manually construct all messages
and drive the protocol. It gives you better control over protocol execution and
you can benefit from better performance (e.g. by having 1 round signing). However,
it also gives a greater chance of misusing the protocol and violating security.
When opting for manual signing, make sure you're familiar with the FROST IETF Draft.
Refer to signing
module docs for the instructions.
Interactive Signing (requires full-signing
feature)
Interactive Signing has more user-friendly interface and harder-to-misuse design.
It works on top of round_based
framework similarly to DKG described above.
As before, you need to define a secure transport layer and construct MpcParty.
Then, you need to assign each signer a unique index, in range from 0 to t-1. The
signers also need to know which index each of them occupied at the time of keygen.
use givre::ciphersuite::Secp256k1;
let i = /* signer index (0 <= i < min_signers) */;
let parties_indexes_at_keygen: [u16; MIN_SIGNERS] =
/* parties_indexes_at_keygen[i] is the index the i-th party had at keygen */;
let key_share = /* key share */;
let data_to_sign = b"data to be signed";
let signature = givre::signing::<Secp256k1>(i, &key_share, &parties_indexes_at_keygen, data_to_sign)
.sign(&mut OsRng, party)
.await?;
Signer indices
We use indices to uniquely refer to particular signers sharing a key. Each
index i
is an unsigned integer u16
with 0 ≤ i < n
where n
is the
total number of participants in the protocol.
All signers should have the same view about each others’ indices. For instance, if Signer A holds index 2, then all other signers must agree that i=2 corresponds to Signer A.
Assuming some sort of PKI (which would anyway likely be used to ensure secure communication, as described above), each signer has a public key that uniquely identifies that signer. It is then possible to assign unique indices to the signers by lexicographically sorting the signers’ public keys, and letting the index of a signer be the position of that signer’s public key in the sorted list.
Webassembly and no_std
support
This crate is compatible with wasm32-unknown-unknown
target and no_std
. Requires
disabling std
feature which is on by default.
Join us in Discord!
Feel free to reach out to us in Discord!
Dependencies
~4–6.5MB
~128K SLoC