A Key Recovery Protocol for Multiparty Threshold ECDSA Schemesopen access
- Authors
- Kim, Myungsun; Cho, Sangrae; Choi, Seongbong; Cho, Young-Seob; Kim, Soohyung; Lee, Hyung Tae
- Issue Date
- Dec-2022
- Publisher
- IEEE-INST ELECTRICAL ELECTRONICS ENGINEERS INC
- Keywords
- Recovery protocol; proactive security; threshold ECDSA; secret sharing
- Citation
- IEEE ACCESS, v.10, pp 133206 - 133218
- Pages
- 13
- Journal Title
- IEEE ACCESS
- Volume
- 10
- Start Page
- 133206
- End Page
- 133218
- URI
- https://scholarworks.bwise.kr/cau/handle/2019.sw.cau/61124
- DOI
- 10.1109/ACCESS.2022.3230683
- ISSN
- 2169-3536
- Abstract
- Recently, threshold ECDSA schemes have received much attention from the security community, due to the need of efficient key management in the blockchain system. For the practical use of threshold cryptosystem, a key recovery protocol is essential for users who lost their own secret shares to recover them. It was studied for a long time in the proactive secret sharing area, but the main aim of recent studies in that area is to achieve stronger security and so they are immoderate for the currently existing threshold ECDSA schemes. In this paper, we provide a new key recovery protocol for threshold ECDSA schemes that is secure against static corruptions by malicious adversaries, as in the common adversary model of the state-of-the-art threshold ECDSA schemes. Our proposed protocol reduces both the computational and communication costs to O(t(2)) from O(t(3)) where t is the threshold of the schemes, that is, the minimum number of users required for generating a valid signature. According to our experimental results, when t = 2 with 128-bit security, while the previous result takes 10.46 ms in total for all computations (excluding the transmission time on the network), our protocol takes 4.21 ms, which improves by a factor of about 2.48 times. The advantage of our protocol over the previous result is bigger when t is larger. For example, when t = 9 with 128-bit security, while the previous result requires 333.42 ms in total for all computations, our protocol requires 56.61 ms, which outperforms the previous result by a factor of about 5.89 times.
- Files in This Item
-
- Appears in
Collections - College of Software > School of Computer Science and Engineering > 1. Journal Articles
![qrcode](https://api.qrserver.com/v1/create-qr-code/?size=55x55&data=https://scholarworks.bwise.kr/cau/handle/2019.sw.cau/61124)
Items in ScholarWorks are protected by copyright, with all rights reserved, unless otherwise indicated.