webb-tools / cggmp-threshold-ecdsa Goto Github PK
View Code? Open in Web Editor NEWMPC protocols for threshold ECDSA
License: GNU General Public License v3.0
MPC protocols for threshold ECDSA
License: GNU General Public License v3.0
Issue summary
Message types do not implement the serde Serialize
and Deserialize
traits which means we can't pass messages across the webassembly/javascript bindings.
I will look into adding serde
support to ProtocolMessage
etc so we can create bindings in webassembly.
Just wanted to let you know about this.
Other information and links
The multi-party-ecdsa
library implements Serialize
and Deserialize
for all message types and LocalKey
so that it works with wasm_bindgen
so I think the CGGMP implementation should to.
Thanks!
Issue summary
CGGMP paper requires that the ring-Pedersen parameters is a product of safe primes. For security we need to generate 1024 bit safe primes, which is quite time-consuming. One issue is that right now we're using kzen-paillier for generating Paillier keys. It uses fixed number of Miller-Rabin primality checks, but it is more than recommended.
Additionally, we could use https://eprint.iacr.org/2003/186.pdf - right now we sieve p,q individually but the paper recommends an unified sieve, giving potentially 15x speedup
Goal of this note is to extend
De-commit from
Note the values
Also, set the group public key as
Each party now has access to an
Describe the bug
Some tests are flaky due to a [u8; 32]
conversion that fails when the byte length is less than 32.
For details, see: #26 (comment)
Replaces #27.
Expected behaviour
Tests always pass.
The webassembly checks are broken on Linux, see this comment for more information.
Issue summary
When we originally modified the Zengo mp-ecdsa, we added additional encryption to P2P messages because we were originally broadcasting/gossiping all messages over our network,
Some old commits which added this extra encryption are:
I think we should remove this and make more explicit how this type of message can be encrypted before the P2P messages hit the wire.
Unlike in the key refresh presented in the CGGMP '21 paper, FS-DKR does not result in each party having ring-Pedersen parameters. So this is something we have to append to our protocol.
It makes sense to append this to FS-DKR itself. We also need a ZK that the parameters are generated properly:
The steps for pre-signing and signing are specified clearly in the CGGMP '21 paper.
What is missing from these screenshots is how actually to implement the non-interactive zero-knowledge proofs (NIZKs), but this is also given in the paper. So we provide more screenshots.
In pre-signing round 1, we need:
In pre-signing rounds 2 and 3 we additionally need:
In pre-signing round 4, we additionally need:
In signing, we additionally need:
All of the ZKs screenshotted above are three-move protocols. That is, they are interactive. We need to make them non-interactive.
enc
)aff-g
)log*
)mul
)dec
)mul*
)The current implementation is an evaluation over different protocols. There is some mismatch between the proofs and values being transmitted with the papers, leading to potential vulnerabilities. The goal of this checklist is to define a roadmap to streamline the implementation to be more compatible with the paper and easier to audit.
Say you have
Let the corresponding Lagrange basis polynomials be
Then:
So to convert the
JoinMessage
.RefreshMessage
to every other partyRefreshMessage
's it receives.Main takeaway from the above section:
What is a state machine?
Contextualizing w.r.t. GG '20. The KeyGen
struct makes up the state space, message space, and transition function for each party. Let's be more specific:
round
attribute.msgs1, msgs2,...
. Note each of these is a collection of messages.proceed
function.Basically things work as follows. The handle_incoming
function on the StateMachine
trait adds a message to a message store. Once the store is filled (a.k.a. the messages have been received from all parties), the state machine is ready to transition state via the proceed
function, since it has access to the full message.
The initial state will be an Option<LocalKey<Secp256k1>>
. If this Option
is None
then it corresponds to a newly joining party and if it corresponds to an already existing party.
pub struct Round0 {
local_key: Option<LocalKey<Secp256k1>>
}
The proceed
transition from round 0 to round 1 does not entail receiving any messages. Rather the state transition works as follows:
Option<JoinMessage>
(see here).None
if local_key
is Some
and Some
if local_key
is None
.The round 1 struct looks like:
pub struct Round1 {
local_key: LocalKey<Secp256k1>,
...
}
Notice here local_key
is no longer an Option
since every party has generated their local keys.
The transition from round 1 to round 2 entails receiving BroadcastMsgs<Option<JoinMessage>>
as the messages. The proceed
transition function receives these messages and:
local_key
. Specifically, the JoinMessage
's of the new parties contain Paillier
keys so the paillier_key_vec
attribute of local_key
needs to be updated (for each existing party).RefreshMessage
see here.The round 2 state looks like:
pub struct Round2 {
local_key: LocalKey<Secp256k1>,
...
}
...with the updated local_keys
.
Each party receives BroadcastMsgs<Option<RefreshMessage>>
does the relevant checks and updates its local_key
accordingly. The final state is a new LocalKey
.
KeyRefresh
struct:StateMachine
trait for KeyRefresh
structRound0, Round1, Round2
structs.As this library was built on top of the ZenGo library I assume it is also vulnerable to the c-split
attack documented here:
https://www.verichains.io/tsshock/
Can somebody verify this please?
Task summary
Certain modules are duplicated in both utilities
modules, these need to be standardized to a single location.
mta
zk_pdl
zk_pdl_with_slack
Describe the bug
Just saw this failure, subsequent test run passes ok:
running 21 tests
test utilities::aff_g::tests::test_affine_g_proof ... ok
test utilities::dec_q::tests::test_paillier_decryption_modulo_q ... FAILED
test utilities::enc::tests::test_paillier_encryption_in_range_proof ... ok
test utilities::log_star::tests::test_log_star_proof ... ok
test utilities::mta::range_proofs::tests::alice_zkp ... ok
test presign::state_machine::test::presign_all_parties_works ... ok
test sign::state_machine::test::sign_all_parties_works ... ok
test utilities::mta::test::test_mta ... ok
test utilities::mul::tests::test_paillier_mul ... ok
test utilities::mul_star::tests::test_mul_star_proof ... ok
test utilities::zk_pdl_with_slack::test::test_zk_pdl_with_slack ... ok
test utilities::zk_pdl::test::test_zk_pdl ... ok
test utilities::zk_pdl_with_slack::test::test_zk_pdl_with_slack_soundness - should panic ... ok
test presign::state_machine::test::presign_threshold_works ... ok
test sign::state_machine::test::sign_threshold_works ... ok
test utilities::mta::range_proofs::tests::bob_zkp ... ok
test refresh::state_machine::test::test_dkr_with_remove_parties ... ok
test refresh::state_machine::test::test_dkr_with_no_new_parties ... ok
test refresh::state_machine::test::test_dkr_with_new_threshold ... ok
test refresh::state_machine::test::test_dkr_with_replace_parties ... ok
test refresh::state_machine::test::test_dkr_with_new_parties ... ok
failures:
---- utilities::dec_q::tests::test_paillier_decryption_modulo_q stdout ----
thread 'utilities::dec_q::tests::test_paillier_decryption_modulo_q' panicked at src/utilities/dec_q/mod.rs:168:79:
called `Result::unwrap()` on an `Err` value: [5, 125, 189, 169, 34, 120, 151, 194, 233, 222, 20, 200, 108, 156, 213, 51, 130, 65, 232, 80, 37, 41, 158, 85, 105, 164, 15, 195, 144, 245, 96]
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Goal of this note is to extend
For notation and how keygen works please see: #2
There are two sets of secret values from keygen the
An attacker that compromises EITHER of these sets of values will learn the secret
We can refresh the
fs-dkr-notes.pdf
Let the
Each party Feldman VSS shares
Each party makes its new
CGGMP paper defines ZK proof Π-mod (See Fig 16 https://eprint.iacr.org/2021/060.pdf#page=36) for ensuring that the Paillier modulus is a semiprime and gcd(N, phi(N)) = 1
. There is an attack which assumes that N
has many small factors described at https://www.fireblocks.com/blog/gg18-and-gg20-paillier-key-vulnerability-technical-report.
I tried searching for the implementation of Π-mod in the repository and wasn't able to find it. Does it seem right and if so, should we implement it? Or would it be sufficient if we test N
not to have small factors? (for example primes up to 2**20?)
@drewstone, I have mentioned that the curv library doesn't seem to be maintained (see this comment) and it would be good for us to forge a path towards using the constant time crypto-bigint
library as the BigInt backend which would require forking curv.
And then I just came across this security advisory regarding the secp256k1
library that curv depends upon.
I have searched the codebase(s) and I don't think we are exposed to the issue with Secp256k1::preallocated_gen_new
however I do want to start a conversation about what we should do with the curv
dependency.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.