Thor chain #206
Closed
Thor chain #206
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
error handlings in other places are of different style. This PR aims to make the error handling style more consistent
rename N2&modN2 in RangeProofAlice.Verify to same style in RangeProofAlice.Prove
* create security policy * security: remove a para * security: update the text
style(mta::RangeProofAlice): rename for more consistent var name
style: refactor crypto lib to consistent verification style
dlog smallgroup 8
S in eddsa signature is not encoded correctly
* fix R and S may not be 32 bytes * refactor according to review comments
* move curve into tss.Parameters * regen proto with full package name * pass curve through parameter * add curve name in ecpoint json serialization
cherry pick > curve as parameter (#137)
…/protobuf-name-clash � Conflicts: � common/signature.pb.go � ecdsa/keygen/ecdsa-keygen.pb.go � ecdsa/keygen/local_party_test.go � ecdsa/resharing/ecdsa-resharing.pb.go � ecdsa/signing/ecdsa-signing.pb.go � eddsa/keygen/eddsa-keygen.pb.go � eddsa/resharing/eddsa-resharing.pb.go � eddsa/signing/eddsa-signing.pb.go � go.mod � protob/ecdsa-keygen.proto � protob/ecdsa-resharing.proto � protob/ecdsa-signing.proto � protob/eddsa-keygen.proto � protob/eddsa-resharing.proto � protob/eddsa-signing.proto � tss/message.pb.go
Updated protobuf dependency and fixed type clash
Check paillier ciphertext
We need to ensure that:
- all indexes are non-zero,
- all indexes are non-zero modulo the curve order,
- all indexes are unique modulo the curve order.
The first two are guarded in `CheckIndexes` function by:
```
vMod := new(big.Int).Mod(v, ec.Params().N)
if vMod.Cmp(zero) == 0 {
return nil, errors.New("party index should not be 0")
}
```
The last one is guarded by:
```
vModStr := vMod.String()
if _, ok := visited[vModStr]; ok {
return nil, fmt.Errorf("duplicate indexes %s", vModStr)
}
visited[vModStr] = struct{}{}
```
`CheckIndexes` was additionally normalizing identifiers mod elliptic curve order.
This was not really needed and could cause problems during signing.
Do not normalize IDs of Shamir's Secret Sharing
* Panic when save data and sortedIDs not match * Check Ks when computing Lagrange coefs
Fix for ECDSA keygen test
Add checks in dlnproof [TOB-BIN-8]
Generating DKG pre-parameters is a computationally expensive operation. As `GeneratePreParams` documentation explains, it is recommended to do it out of band. Keep ECDSA (TBTC) client has a pre-parameters pool from which the DKG process pulls pre-parameters to do not have the entire group wait with kicking off DKG until pre-parameters are generated. This approach was sufficient for TBTC v1 when signing groups were 3-of-3. For TBTC v2, we need much larger signing groups (51-of-100) and for clients having multiple seats in the signing group, generating multiple pre-parameters in a row eliminates other processes run by the client from the access to the CPU. To fix this problem, we plan to run pre-parameters generator only when no other processes are currently executed by the client. That is, when the client would normally be idle, it will keep generating pre-parameters and when the client starts a protocol execution (e.g. DKG), pre-parameters generation should be stopped. GeneratePreParams allows specifying a timeout which is really helpful but is not enough in this case. We want to stop the generator immediately when some protocol is about to start. To achieve it, the code has been refactored to accept a context as a parameter of all long-running generator functions. The context can be canceled or can be constructed in such a way that it times out after a certain time. To achieve backward compatibility, GeneratePreParams signature does not change and a new function accepting the context GeneratePreParamsWithContext has been introduced.
10ms delta was too aggresive - it was fine for local dev environment on Apple M1 but CI builds based on GitHub Actions kept failing. Increased to 1s.
Allow to stop pre-parameters generator with a context
update README.md to match the new version
* Add check in mta_proof * go fmt on range_proof.go This reverts commit 4871684.
* Cherrypick child key derivation (#140) * Cherrypick child_key_derivation from SwingbyProtocol https://github.com/SwingbyProtocol/tss-lib/pull/6/files#diff-e663957d1112b8c89bb7a782fe1cebe0d5e4d84a17861ae5af5cc0b59d1dbf56 * Add serialization to child key derivation add test case from github.com/btcsuite/hdkeychain * Making ec as parameter in key_derivation_util * Add version string to extendedkey, to comply with BIP32 * specify curve in NewExtendedKey * pass curve in DeriveChildKey * amend the HD cherry pick not to break the existing API of NewLocalParty * FillBytes not available in go 1.13 Fix test using FillBytes Co-authored-by: ycen <[email protected]> Co-authored-by: FitzLu <[email protected]>
…203) * Benchmark tests for DLN proof verification The DLN proof verification is one of the most expensive parts of the key generation protocol. This benchmark allows to check how expensive the Validate call is. * Control the concurrency level when verifying DLN proofs Control the concurrency level when verifying DLN proofs Verification of discrete logarithm proofs is the most expensive part of threshold ECDSA key generation for large groups. In round 2 of key generation, the local party needs to verify proofs received from all other parties. The cost of a call to `dlnProof.Verify` measured on Darwin/arm64 Apple M1 max is 341758528 ns/op - see `BenchmarkDLNProofVerification`. There are two proofs that need to be verified during the key generation so assuming there are two cores available exclusively for this work, the verification of 100 messages takes about 35 seconds. For a group size of 1000, the verification takes about 350 seconds. The verification is performed in separate goroutines with no control over the number of goroutines created. When executing the protocol locally, during the development, for a group size of 100, 100*99*2 = 19 800 goroutines for DLN proof verification are created more or less at the same time. Even such a powerful CPU as Apple M1 Max struggles with computing the proofs - it takes more than 16 minutes on all available cores and all other processes are starved. To optimize the code to allow it to be executed for larger groups, the number of goroutines created at the same time for DLN proof verification is throttled so that all other processes are not perpetually denied necessary CPU time to perform their work. This is achieved by introducing the `DlnProofVerifier` that limits the concurrency level, by default to the number of CPUs (cores) available. * Added benchmarks for DlnProofVerifier functions The benchmarks are promising and shows the the validator does not add any significant overhead over the DLN verification itself: BenchmarkDlnProof_Verify-10 3 342581417 ns/op 1766010 B/op 3790 allocs/op BenchmarkDlnVerifier_VerifyProof1-10 3 342741028 ns/op 1859093 B/op 4320 allocs/op BenchmarkDlnVerifier_VerifyProof2-10 3 341878361 ns/op 1851984 B/op 4311 allocs/op * Allow configuring key generation concurrency in params The concurrency defaults to `GOMAXPROCS` and can be updated with a call to `SetConcurrency`. The concurrency level is applied to the pre-params generator and DLN proof validator. Since there are two optional values now when constructing parameters, instead of passing safe prime gen timeout as the last value of `NewParameters`, all expected parameters should be configured with `Set*` functions. * Use DLN verifier for resharing protocol DLN proof verification is the most computationally expensive operation of the protocol when working in large groups. DLN verifier allows to throttle the number of goroutines verifying the proofs at the same time so that other processes do not get starved. DLN verifier is already applied to key generation protocol. Here, it is getting applied to resharing as well. * Always expect concurrency level to be passed to NewDlnProofVerifier The concurrency level is now available in all rounds constructing the verifier and the optional concurrency feature is never used. * Ensure that the concurrency level is non-zero `tss.NewParameters` is not validating provided values and I did not want to make a breaking change there. Instead, I added a comment to `SetConcurrency` and added a panic in the DLN proof verifier ensuring the protocol fails with a clear message instead of hanging. This is aligned with how `keygen.GeneratePreParamsWithContext` deals with an invalid value for `optionalConcurrency` param. * Log on DEBUG level concurrency level for DLN verification
* ECDSA protocol security updates * Update proofs.go * Limit y in Mta in range and prove * Add checks in proofFac * Add checks in MtA * Remove unnecessary assignments * Update unbiased reject sample * Make compatible for old parties with no facProof * Revert "Make compatible for old parties with no facProof" This reverts commit 4c9fa88. * Revised compatible for old parties with no facProof * Update facProof condition test * Allow empty proofFac, roll back rejectSample for compatibility --------- Co-authored-by: Wan Ziyi <[email protected]>
* Add modProof in ECDSA-keygen * Reduce test param to reduce github workflow load * Add test fixtures * Fix EDDSA keygen example * Restore test fixtures * Compress modproof * use warning instead of fatal in logger to prevent panic * Add more checks in range proof * Regenerate preparams for older version * Reset test params and regenerate fixtures * Update ecdsa-resharing with Paillier key proofs * Add a switch to optional turn off Pai key proofs * Update README for caution of preparams updated * add: ecdsa proof session byte --------- Co-authored-by: ycen <[email protected]> Co-authored-by: ZhAnGeek <[email protected]>
* Update dependencies * fix: compatibility of end channel output shift to pointer (#271) Co-authored-by: ZhAnGeek <[email protected]> * upgrade dependencies version * Clean code --------- Co-authored-by: ZhAnGeek <[email protected]> Co-authored-by: ZhAnGeek <[email protected]> Co-authored-by: asdfsx <[email protected]>
Co-authored-by: ZhAnGeek <[email protected]>
style: refactor to more consistent error handlings style
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thor chain