Multiple Bugs in Multi-Party Computation: Breaking Cryptocurrency's Strongest Wallets

The presentation discusses the importance of prioritizing code clarity over writability for better understanding and bug detection. It also highlights the three main classes of problems in implementing academic papers and emphasizes the need for backups and caution in choosing cryptocurrencies.

• Code should be optimized for readability instead of writability
• Academic papers may lack descriptions of data encoding and protocol parameters, leading to security problems
• A zero-knowledge proof of factorization example illustrates the danger of incomplete or confusing definitions
• Backups are important even with technologies like MPC and TSS
• Caution is needed in choosing cryptocurrencies and understanding their security
• The involvement of cryptographers in library development varies

The presentation gives an example of a zero-knowledge proof of factorization that was safe on paper but completely insecure in practice due to a misunderstanding of common input. This highlights the importance of clear and complete definitions in academic papers.

Cryptocurrency wallets in exchange platforms or banks require strong security because they protect vast amounts of money. Some solutions rely on advanced cryptographic methods that distribute trust across multiple parties, in the spirit of Shamir's secret-sharing. These include multi-party computation (MPC) and threshold signature schemes (TSS), which are a special case of MPC to sign data in a distributed, yet trustless manner. TSS has notably been tested and deployed in major organizations where secret key generation and digital signing are needed. But these techniques, although powerful and "magic" on paper, can prove fragile in practice, as this talk will show. We introduce MPC and TSS in a way suitable for non-experts, highlighting their unique properties and showing how they can be used to protect enterprise-grade wallets. We review TSS' building blocks such as verifiable secret sharing and Schnorr signatures and explain the design and security goals of TSS libraries, and how these goals differ from those of traditional cryptography, in terms of managing complexity, interactiveness, and composition of protocols. MPC and TSS seem very secure and state-of-the-art, so what could go wrong? Complexity is the enemy of security, and this complexity is what we exploit. We describe a new type of logical vulnerability, enabled by extra layers of complexity in TSS implementations, which opens up a new attack surface and devastating attacks allowing a malicious participant to sabotage key generation and break TSS's security. This attack could allow an attacker, for example, to empty an organization's cold wallet. We describe a related attack on a major MPC solution used by a leading organization. We conclude with lessons learned and best practices across the development pipeline of complex cryptographic software, including extensive testing, defense-in-depth controls, how to implement new academic work, and how an audit by specialists should be done to be the most effective.