crypto/tss/recovery: add private key recovery from dkg results #239
Conversation
a749c6c to
90bace1
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #239 +/- ##
==========================================
+ Coverage 76.77% 76.85% +0.07%
==========================================
Files 145 146 +1
Lines 11326 11357 +31
==========================================
+ Hits 8696 8728 +32
+ Misses 1869 1868 -1
Partials 761 761 ☔ View full report in Codecov by Sentry. |
90bace1 to
b1f96b1
Compare
|
Hi zhelnov, Thanks for your PR. We will check it in this week! Sincerely |
| privKeyBigInt.Mod(privKeyBigInt, fieldOrder) | ||
|
|
||
| pubKey := ecpointgrouplaw.NewBase(curve).ScalarMult(privKeyBigInt) | ||
| privKey := &ecdsa.PrivateKey{ |
There was a problem hiding this comment.
Do we need to check the public generating by this private and the public key owned by all participants, which are the same ?
There was a problem hiding this comment.
Good point, i just added ECpoint pubkey param to recovery function and check if public generated from our recovered private key is equal to provided one. It'll not affect recovery flow, but it will be some kind of fuse to protect against incorrect recovery.
Also i rewrote tests on ginkgo/gomega tools.
b1f96b1 to
52912a7
Compare
| bk *birkhoffinterpolation.BkParameter | ||
| } | ||
|
|
||
| func RecoverPrivateKey(curve elliptic.Curve, threshold uint32, pubKey *ecpointgrouplaw.ECPoint, peers []RecoveryPeer) (*ecdsa.PrivateKey, error) { |
There was a problem hiding this comment.
A point to consider here: i chose to describe function arguments in NewDkg/NewSigner arguments style to keep it simple and unambiguous. But i suppose actual use case of such function may be that library user provides array of DKG results. I have higher-level function that accepts such array and does necessary validation (BKs/Pubkey/Threshold consistency in each array entry for example to check its same peer quorum results) but not sure if it makes sense to keep that logic as part of Alice. Altough i'll be happy to add such function here if it makes sense.
There was a problem hiding this comment.
I think it's acceptable for this version. Your consideration is meaningful.
|
Hi zhelnov, Thanks for your PR. The PR will be merged until @markya0616 reviewed it. |
|
Hi! A tiny addition i feel like i should mention. Unlike EcDSA, where recovered big.Int is actually a private key, it seems for EDDSA we're just getting so called scalar, which is not the private key. Furthermore, according to EDDSA RFC https://www.rfc-editor.org/rfc/rfc8032#section-3.3 scalar is derivative of source private key by hashing. As hashing is irreversible operation, unfortunately we cant recover original EDDSA private key and best we can get is scalar. Despite we still can sign something using scalar with library like |
52912a7 to
9a25eaa
Compare
|
I just rebased it with upstream |
9a25eaa to
1af96c7
Compare
|
@cychuang0924 @markya0616 hello! Is any change this PR will be merged? Still would be useful to have this packed into Alice. |
1af96c7 to
1d3e7db
Compare
This PR is adding functionality for private key recovery from multi-party DKG results (shares and BK's). It may be useful in case all parties agreed to "exit" HTSS process and wants to receive single private key to work with further, like emergency case for some services providing HTSS are down.
This implementation tested for both EcDSA (
secp265k1andsecp256r1) and EDDSA (ed25519) algo's with threshold considering (3/3, 2/3 DKG quorums).I'm about to cover hierarchical scenarios too (involving different BK's Rank values) and write some readme for that tool, but would be nice to hear from maintainers if this whole thing correct and makes sense as part of Alice lib. @markya0616 @cychuang0924 what do you think?
(UPD 28.02.2023 added EDDSA tests)
Before submitting a pull request, please make sure the following is done:
Checklist
master.