ADKG
Estimated time to read: 3 minutes
Asynchronous Distributed Key Generation (ADKG) is a cryptographic protocol that allows multiple parties to generate a public-private key pair cooperatively, without needing a trusted third party or synchronization.
Each party creates a partial private key and shares it with the others. Together, they use these partial keys to derive the final private key used for securing blockchain transactions in Web3 apps.
ADKG is ideal for geographically dispersed or poorly connected parties where traditional methods are impractical. ADKG's distributed trust also makes it more resistant to attacks compared to methods relying on a single central authority.
ADKG for Web3 Keys
Web3 blockchain transactions require user approval through cryptographic keys.
The Arcana Auth SDK uses ADKG to securely generate key shares for Web3 users. It allows users to securely access and generate their keys on the client side, handling security and privacy concerns. Users can easily sign transactions with the non-custodial Arcana wallet.
ADKG generates ECDSA keys on the secp256k1 curve, compatible with all EVM chains. Future updates will support other curves, blockchains, and key regeneration.
Why ADKG?
Our ADKG implementation uses the Practical Asynchronous Distributed Key Generation protocol. It improves on the previous DKG by removing the need for a trusted dealer, reducing key exposure, and automating share regeneration. ADKG is resilient to attacks and works well in asynchronous networks. It ensures security by preventing any single node from accessing a user's key.
ADKG Assumptions
The ADKG protocol works under the assumption that in an asynchronous network of n â„ 3t + 1 nodes, where at most t nodes could be malicious.
The protocol can achieve an expected communication cost of O(Îșn\(^3\) ) and terminates in expected O(log n) rounds. Here Îș is the security parameter. For example, if a collision-resistant hash function is used, in that case, Îș denotes the size of the hash function's output.
Implementation Notes
ADKG requires a set of at least 4 connected nodes at a minimum for accommodating a maximum of 1 malicious node.
At a very high level, the protocol requires each node to independently generate secrets and then share a part of that secret with the other nodes. Each node then shares a proposed set of key shares with other nodes. Asynchronous Binary Agreement (ABA) voting is done by the nodes for each proposed set. Only the accepted and agreed-upon set is used to derive the key shares and then those key shares are combined to arrive at the final key pair. None of the nodes have full access to the secret key.
There are four key phases in the ADKG protocol:
- Asynchronous Complete Secret Sharing (ACSS)
- Keyset Proposal Broadcast Phase
- Asynchronous Binary Agreement (ABA)
- Key Derivation Phase
For more details on each of these ADKG phases, see here.