What we learned reviewing one of the first DKLs23 libraries from Silence Laboratories

Joop van de Pol, Jim Miller, and Joe Doyle
cryptography, audits

In October 2023, we audited Silence Laboratories’ DKLs23 threshold signature scheme (TSS) library Silent Shard—one of the first production implementations of this then-novel protocol that uses oblivious transfer (OT) instead of traditional Paillier cryptography. Our review uncovered serious flaws that could enable key destruction attacks, which Silence Laboratories promptly fixed.

Our audit yielded three key lessons. First, the DKLs23 specification gives implementers significant freedom to choose sub-protocols (base OT, OT extension, pairwise multiplication), requiring careful study of both the specification and implementation choices. Second, OT-based systems generally prove less error-prone than Paillier-based systems, needing simpler validations for security once protected against selective abort attacks. Finally, all TSS schemes require attention to fundamentals like secure P2P communication, broadcasting, and consensus verification.

In this blog post, we cover our process, dive into the key issues we identified, and discuss recommendations to bolster the security and correctness of the implementation. Check out the full Silence Laboratories DKLs23 review report for more details!

A bold new library - Silent Shard

Silence Laboratories is a team of academic and industry scientists that has built a versatile TSS library called Silent Shard. The team aims to provide TSS support across a wide variety of applications and use cases, including the cryptocurrency wallet MetaMask.

To support ECDSA signatures, Silence Laboratories built the Silent Shard library on the then-novel DKLs23 protocol. Many of the common ECDSA protocols, such as CGGMP21, rely on the homomorphic properties of the Paillier encryption system to perform specific ECDSA signature operations. The DKLs23 protocol is a fundamentally different protocol, using the cryptographic primitive known as oblivious transfer (OT), instead of Paillier. This OT-based approach has been gaining additional attention and momentum over the past few years due to its competitive performance and the fragile nature of Paillier based systems (as an example, see the recent BitForge and TSShock vulnerabilities).

How we conducted our review

Our project with Silence Laboratories began with a manual review of the accompanying documentation and included periodic consultation with Silence Laboratories for certain clarifications. Implementing TSS protocols, especially DKLs23, is a very complex task, as the specifications are dense with complicated notations and many sub-protocols, each of which has its own sharp edges and security concerns. To give you a better sense of this, here is a screenshot of the main DKLs23 protocol, which is split across four pages of text:

Figure 1: The main DKLs23 protocol spans four dense pages of specifications, with each notation representing its own complex sub-protocol
Figure 1: The main DKLs23 protocol spans four dense pages of specifications, with each notation (\(\mathcal{𝓕}_{Com}\), \(\mathcal{𝓕}_{RVOLE}\), etc.) representing its own complex sub-protocol

If you’re not overwhelmed by all the different variables you need to understand and keep track of, also keep in mind that each of the \(\mathcal{𝓕}_{Com}\), \(\mathcal{𝓕}_{RVOLE}\), \(\mathcal{𝓕}_{Zero}\), etc. notations is its own complex sub-protocol with its own dense notation and security considerations. Some of these sub-protocols are actually defined in previous publications, so you have to perform plenty of reference chasing as well.

Alongside the manual review, we used relevant tools to perform automated analysis on the Rust codebase. In particular, we used cargo-audit and Clippy to identify known-vulnerable dependencies and common Rust mistakes. We also used cargo-llvm-cov to analyze the codebase’s test coverage and identify hot spots where additional testing would be most valuable. Lastly, we used Trail of Bits’ custom Rust tool, Dylint, which identifies more common Rust mistakes and code quality issues that Trail of Bits has uncovered on previous projects.

Key findings

Over the course of the project, we identified a total of 15 security issues. Of those 15, we identified two high-severity security issues that could have resulted in a key destruction attack and, potentially, a key recovery attack:

  • TOB-SILA-6: Communication channels between parties can reuse nonces. TSS protocols have strong communication requirements to keep the protocol secure. In particular, the parties in the protocol must have secure pairwise channels to prevent messages from being read or tampered with. This mistake in the implementation of the nonces used for encryption could allow a malicious party to alter one of the protocol messages between two parties, which would prevent them from signing messages. This is known as a key destruction attack. To address this issue, the Silence Laboratories team updated the communication channels to use different keys for each direction in the channel, which prevents the same nonce from being used twice with the same encryption key.

  • TOB-SILA-12: The implementation mishandles selective abort attacks. One of the crucial designs of these TSS protocols is to properly detect and handle malicious behavior from other parties. We identified a mistake in this malicious behavior handling that causes a panic, which prevents the parties from properly identifying the malicious party. Without a properly functioning identifiable abort, parties in the protocol either have to blame everyone (or some random subset of parties) in the protocol, which could lead to a key destruction attack, or blame or punish no one, which could lead to a key extraction attack. Silence Laboratories patched the implementation to return an explicit AbortProtocolAndBanReceiver error, which includes the ID of the party to be banned.

Some of the other findings we identified could also have led to key destruction attacks and other problematic issues. A detailed list of all security issues can be accessed in our full report.

Our report also includes our code quality recommendations, which are intended to enhance code readability, maintainability, and robustness. Some of the suggestions pertain to the use of specific types for increased readability and consistency, comprehensive documentation of function parameters for public library functions, and reduction in unnecessary uses of unsafe code. Refer to appendix C of the report for more information.

Side-channel analysis

The security review of Silence Laboratories’ Silent Shard DKLs23 library involved analyzing the implementation for potential side-channel vulnerabilities. We found that the codebase largely prevented side-channel attacks by using constant-time code with crates like subtle where appropriate. However, there was one function, eval_pprf, where timing information could disclose some information about a secret value. As we describe in the report, we believe the risk associated with this issue is quite low because a practical attack would be difficult if not entirely infeasible. But for defense-in-depth, we included recommendations for making this function constant-time and thus not disclosing any unnecessary information. In response to this issue, Silence Laboratories submitted a patch to remove this timing leakage. For more details, please see appendix D in our report.

Recommendations

In addition to offering recommendations to address the 15 security issues and code quality issues we identified, we provided two long-term recommendations for Silence Laboratories after the project concluded. The first recommendation for the DKLs23 implementation was to improve the documentation, especially for error handling, given how important handling of malicious behavior is in TSS systems and given the error handling issues we identified.

Our other main recommendation was to introduce additional negative testing to the codebase. In particular, negative testing could have detected and prevented some of the issues we identified, such as TOB-SILA-1 and TOB-SILA-2. The need for additional negative tests was also confirmed by our analysis with cargo-llvm-cov.

Since our project concluded, we are pleased to say that Silence Laboratories has resolved 14 of the 15 security issues and partially resolved the remaining informational issue. Silence Laboratories has also invested in additional documentation and testing, per our long-term recommendations.

Securing TSS protocols

We commend Silence Laboratories for their highly effective and collaborative work on this project and for their timely responsiveness to our findings and recommendations. Audits like this one demonstrate a proactive approach to bolstering a codebase’s security and are an important step in providing a versatile toolkit for TSS.

With the conclusion of this project, our cryptography team has now performed multiple security assessments on all major TSS protocols across ECDSA, Schnorr, and BLS signatures. In addition, all of the major TSS protocols have hired us for engineering services, building Go and Rust implementations for all of the related signature schemes. If you need a security review or engineering of any TSS protocol, please contact us! We offer free office-hour sessions where we can provide impactful advice based on our extensive experience with these systems.