feat(threshold): a module to validate cryptographic parameters #18 #106
Conversation
A new module for validating cryptographic scheme parameters (N, f) and deriving the threshold. It provides a single `validate_and_derive_threshold` function to ensure protocol safety for `DKG`, `OT-based ECDSA`, and `Robust ECDSA` schemes, simplifying the API and removing unnecessary complexity.
0xsecaas
force-pushed
the
feat_hardcode_threshold
branch
from
36ded65 to
9614fde
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #106 +/- ##
==========================================
+ Coverage 88.27% 88.52% +0.24%
==========================================
Files 40 41 +1
Lines 8179 8390 +211
Branches 8179 8390 +211
==========================================
+ Hits 7220 7427 +207
- Misses 399 401 +2
- Partials 560 562 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
0xsecaas
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Refine ckd test to use the correct hardcoded threshold restriction
`f` should be calculated differently for RobustEcdsa.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
0xsecaas
changed the title
|
Hello @0xsecaas , hope you are doing great! I finally got back to this PR. I see there are different things happening in this PR from some code refactoring, to tests adjustments, to Readme updates to parameter handling. Would you be fine to split it into multiple PRs while adapting it to the new code (that is conflicted here)? |
| let max_malicious = 5; | ||
| let threshold = max_malicious + 1; | ||
| let keys = run_keygen(&participants, threshold)?; | ||
| let keys = run_keygen(Scheme::OtBasedEcdsa, &participants, threshold)?; |
There was a problem hiding this comment.
The "t" is capital OT refers to Oblivious Transfer.
| let keys = run_keygen(Scheme::OtBasedEcdsa, &participants, threshold)?; | |
| let keys = run_keygen(Scheme::OTBasedEcdsa, &participants, threshold)?; |
| //! # Parameters | ||
| //! | ||
| //! - **`N`**: Total participants. | ||
| //! - **`f`**: Maximum assumed faulty participants. |
There was a problem hiding this comment.
In distributed systems, the terminology used is "faulty" nodes. In cryptography, the terminology is malicious nodes.
| //! | ||
| //! - **`N`**: Total participants. | ||
| //! - **`f`**: Maximum assumed faulty participants. | ||
| //! - **`t` (threshold)**: Minimum participants required to generate a signature, derived from `N` and `f`. |
There was a problem hiding this comment.
Let us not use the term threshold as multiple definitions exist in the wild and we do not want to confuse the library users.
| Scheme::Dkg => { | ||
| // require f <= floor(n/3) which is equivalent to 3f <= n | ||
| if f.checked_mul(3).ok_or(ValidationError::ArithmeticError)? > n { | ||
| return Err(ValidationError::FTooLargeForDkg); | ||
| } | ||
| f.checked_add(1).ok_or(ValidationError::ArithmeticError)? | ||
| } |
There was a problem hiding this comment.
DKG is very tricky as there are two actual "thresholds". The first is the Distributed systems' threshold which assumes that not more than one third of the participants are malicious (while running the DKG). The second is the threshold you are creating for the cryptography part i.e., the minimal number of shares needed to recover the key. Both exist in the DKG.
One might ask whether it makes sense to have these two thresholds different. The only answer I can give is "the library user should be clearly notified about this thing and should know what he/she is doing"
| OtBasedEcdsa, | ||
| /// Robust ECDSA | ||
| RobustEcdsa, |
There was a problem hiding this comment.
What about parameters for the subprotocols (presign, sign and so on?) Some of the schemes should be robust and "might" allow changing some parameters from the one protocol to the other.
There was a problem hiding this comment.
To wire this up properly, I just need to know which schemes actually allow it (e.g., robust ECDSA can sign with more active nodes but the same threshold).
I assume full invariance for now, but do you already have some cases in mind?
|
@0xsecaas would you still like to take care of this? Thank you always for your help |
|
@SimonRastikian Definitely, I’ll make sure to take care of it this week. |
Sure @SimonRastikian, lets start with the documentation #221 |
|
I will close this PR as you are opening smaller ones on the side. Thank you @0xsecaas ! |
3 participants
A a module for validating cryptographic scheme parameters (
N,f) and deriving thethreshold.It provides a single
validate_and_derive_thresholdfunction to ensure protocol safety forDKG,OT-based ECDSA,Robust ECDSAand possible future schemes.closes #18