Symphony of Cryptography-Construction
One of KZen’ primary missions is to provide a secure infrastructure for interacting with blockchains. To do so we are implementing multi-party variants of digital signature schemes for private key generation and signing cryptocurrency transactions.
With the help of the open source community we are creating a cryptographic infrastructure, containing multiple signature schemes, cryptographic utilities and primitives. In this post we describe our design for supporting 2-Party Computation protocols.
Multi-party Computation (MPC) is an important branch in modern cryptography. It enables the evaluation of math functions with distributed inputs between un-trusting participants. MPC was introduced decades ago and ever since it received a lot of attention from the academic community. Recent breakthroughs has made MPC efficient enough to be considered practical for real world use cases, such as blockchain transactions (and many more).
At KZen Networks, we use MPC as a method to decentralize the private key generation and transaction signing between participants, without changing the signature verification by blockchain operators and users (such as miners, exchanges and other wallets).
We started with ECDSA (Elliptic Curve Digital Signature Algorithm). This particular signing algorithm is being used by most blockchains (Bitcoin, Ethereum etc..) which is what made it a natural first candidate. The problem is that it is also one of the most challenging algorithms to expend to a two party setting. Only in the last couple of years, handful of papers have succeeded to create secure and efficient enough protocols for threshold-ECDSA. Our first mission was to pick the right programming language to provide a safe environment and performance optimizations to this complex protocols. We had experimented with various languages such as JavaScript / TypeScript, Go, C++ only to finally land, safely and securely, in the Rust language world. At first, our Rust experience provided us with countless hours of nightly compiler fights, but now once we got over that, it’s a pure joy for both cryptographers and engineers.
However, applying the MPC mathematical fairy dust is only a part of the bigger story. We needed an additional layer on top of MPC to manage the keys and provide some additional advanced security features such as private key’s shares constant rotation (such that attacker must attack few locations simultaneously) and support for hierarchical deterministic (HD) structure, similar to BIP-32 for the multiparty setting.
The lowest level layer of KZen’ MPC ECDSA Architecture consists of cryptographic utilities (cryptography-utils) to abstract elliptic curves and provide basic cryptographic primitives: Hash functions, hmac, commitments (hash based, Pedersen based, UC based), simple Zero Knowledge Proofs (e.g. proof of knowledge of EC-DLog, proof of correctness of Pedersen). On top of that simple two party protocols such as coin flip and Diffie-Hellman key exchange are implemented. In addition, we extended an existing Rust library for Paillier Zero Knowledge Proofs (rust-paillier).
We use these building blocks to implement different types of threshold signatures such as ECDSA we mentioned above, Schnorr signatures, Ed25519 and so on. The upper layer is for management: the need of a Key Management System (KMS) is to instantiate threshold signature libraries in a context of a wallet. This is where we implemented private key rotation and distributed Hierarchical Deterministic (HD) structure described above.
As always with code, bugs are inevitable. Therefore we plan to invest in Formal Verification of our Rust code to formally prove the correctness of our implementations.We had already started collaborating with some well known universities and research labs on this effort.
It is just the beginning for KZen Networks and we welcome reviews and contributions on GitHub. We will make sure to keep the community up-to-date on our efforts.
