Breaking MPC Wallets: How Implementation Flaws in dlnproof Lead to Full Key Extraction

TLDR: Researchers at Black Hat 2023 demonstrated that popular Threshold Signature Scheme (TSS) implementations, including those used by THORChain and Keep Network, are vulnerable to private-key extraction. By exploiting implementation flaws in the dlnproof sub-protocol, an attacker only needs one malicious node to reconstruct the full private key. This research highlights the critical danger of optimizing complex cryptographic protocols without rigorous security validation.

Multi-Party Computation (MPC) is often sold as the silver bullet for digital asset custody. The promise is simple: instead of a single private key that can be stolen, the key is split into shares across multiple parties. To sign a transaction, these parties perform a joint computation without ever reconstructing the full key. It sounds secure, but as we saw at Black Hat 2023, the complexity of these protocols is where the real danger hides. When developers rush to optimize these implementations for performance, they often introduce subtle flaws that turn a theoretically secure protocol into a trivial key-theft vector.

The Vulnerability: When Proofs Fail

The research focuses on the GG18 and GG20 protocols, which are widely used for threshold ECDSA. These protocols rely on a series of sub-protocols to ensure that each party is acting honestly. One of these is the dlnproof, a zero-knowledge proof designed to verify that a party knows the discrete logarithm of a value. If this proof is flawed, a malicious party can provide invalid inputs that allow them to extract the private key shares of other participants.

The researchers identified three specific attack vectors: alpha-shuffle, c-split, and c-guess. These are not theoretical edge cases. They are practical, exploitable bugs that stem from how these protocols are implemented in Go and Rust.

Alpha-Shuffle and Ambiguous Encoding

The alpha-shuffle attack exploits an ambiguous encoding scheme. In many implementations, the data being processed is appended with a delimiter. If an attacker can manipulate the input values to include that same delimiter, they can cause the protocol to misinterpret the data structure. By shuffling the alpha values, an attacker can force the protocol to accept a malicious proof, effectively bypassing the integrity checks that are supposed to prevent key reconstruction.

C-Split and C-Guess: Reducing the Complexity

The c-split and c-guess attacks target the iteration count of the dlnproof. These proofs are designed to be repeated multiple times to reduce the probability of a successful forgery. However, if the implementation uses a larger challenge space or reduces the number of iterations, the security margin collapses. In the c-guess attack, the attacker predicts the challenge bits, and because the implementation doesn't enforce enough iterations, the probability of a successful guess becomes high enough to be practical.

Real-World Impact: Draining the Vault

During the presentation, the researchers provided a proof-of-concept (PoC) demonstrating how they could drain assets from a THORChain vault. The setup involved five nodes, where one node was designated as malicious. By injecting malicious parameters during the key generation phase, the attacker node was able to capture the private key shares as they were being generated.

Once the malicious node had the necessary information, it waited for a normal transaction to trigger the threshold signing process. Because the attacker already possessed the key material, they could sign a transaction on behalf of the vault and transfer the assets to an attacker-controlled wallet. The entire process was silent. The network nodes continued to operate as if nothing had happened, and the vault balance appeared correct in the UI, even though the underlying assets had been moved.

This is a nightmare scenario for any project using MPC for custody. If you are a pentester or a researcher auditing these systems, you need to look beyond the high-level protocol design. The OWASP Cryptographic Failures category is the right place to start, but you must go deeper into the implementation-specific logic. Check how the proofs are validated. Are there any shortcuts in the math? Is the encoding scheme robust against injection?

Defensive Considerations

For those building or maintaining these systems, the takeaway is clear: do not roll your own crypto, and be extremely wary of "optimizations." The researchers noted that many of these vulnerabilities were introduced when developers tried to make the protocol faster or more compatible with specific blockchain environments.

If you are using an MPC library, ensure it has undergone a formal, independent security audit. Look for implementations that follow the official documentation and avoid any custom modifications to the core cryptographic primitives. Defenders should also implement robust monitoring for anomalous signing patterns. If a single node starts requesting unusual data or if the signing process deviates from the expected heartbeat, it should trigger an immediate alert and an automated halt of the signing service.

The security of MPC is only as strong as the weakest implementation. As these protocols become more common in decentralized finance, we should expect to see more research targeting these specific implementation flaws. Keep your eyes on the NVD for updates related to these libraries, and if you are testing a system that relies on threshold signatures, prioritize the validation logic of the zero-knowledge proofs. The math might be sound, but the code is almost certainly not.