CGGMP21 Vulnerabilities Patched and Explained

^{CGGMP21 vulnerabilities have been disclosed and fixed. Dfns clients remain fully secure.}

Today, we are sharing important information about two vulnerabilities that were recently discovered in the CGGMP21 threshold signing scheme (TSS) protocol. Both are now fully patched in our implementation. CGGMP is arguably the world's most popular MPC protocol for ECDSA. More precisely, it's a threshold ECDSA protocol developed by leading academics (i.e., Ran Canetti, Rosario Gennaro, Steven Goldfeder et al.) and used across the industry by several wallet infrastructure providers, including Dfns.

First and foremost, we want to reassure our clients: No customer funds and operations were affected. More than 99% of our customers use our default KU23 protocol, which is not exposed to these two issues. For the very small number of clients using CGGMP21, our team has already deployed the patched implementation to their environments.

We credit the security researchers at Fireblocks, namely Arik Galansky, for the responsible disclosure of these issues. We also want to highlight the crucial work of Antoine Urban, Senior Cryptographer at Dfns, who independently identified and flagged the second vulnerability related to the use of presignatures when protocol assumptions do not hold. Urban’s discovery in May 2025 allowed us to switch our default codebase from CGGMP21 to KU23 and protect clients against potential future vulnerabilities in the CGGMP protocol.

While our managed clients are secure, this notice is important for all developers who use our open-source libraries via Lockness (LFDT). The vulnerabilities have been fixed, and we strongly urge you to update your implementations as soon as possible.

Action Required: Update To Latest Version

We are providing two paths for you to secure your implementation. Please choose the one that best suits your needs:

• Recommended Path: Migrate to cggmp24 v0.7.0-alpha.2. This is our latest protocol implementation and the one we recommend for all users. It includes the patches for the reported vulnerabilities along with other improvements. Follow migration guidelines to upgrade from cggmp21. We understand that migrating may take some effort, but it's the best way to ensure long-term security and access to new features. ‍
• Immediate Patch: Update to cggmp21 v0.6.3. If you need a quick fix and aren't ready to migrate to the new protocol, you can update to this patched version of the CGGMP21 library. This update resolves the most critical of the two vulnerabilities, providing an immediate security boost with minimal changes to your existing code.‍
• For our customers: No action required. We have patched and updated all environments to use the latest secure version of the protocol

Vulnerability Details

Let's take a closer look at the two vulnerabilities that were reported.

Vulnerability 1: Missing Verification Step in Zero-Knowledge Proof

The first vulnerability involves a missing check in the Zero-Knowledge Proof used during the Auxiliary Key Generation protocol.

In simple terms, Zero-Knowledge Proofs are a way for one party to prove to another that they know a secret value without revealing the secret itself. For this to be secure, the party verifying the proof must perform a specific set of checks.

It was discovered that the original CGGMP21 paper did not specify one of the required checks in its description of the Paillier-Blum Modulus ZK proof. This is a crucial step that ensures the integrity of the proof. Our implementation, following the paper, was also missing this verification step.

This has been corrected in the latest revision of the paper, CGGMP24, which now includes the necessary check.

For those interested in the technical specifics, the missing check is in the verification step of the proof, which is specified in:

• CGGMP21, Figure 16, page 36 (revision published in 2021 without the check)
• CGGMP24, Figure 12, page 31 (latest revision with the check)

The screenshots below highlight the exact difference between the two papers' specifications.

This missing check may lead to a full private key extraction attack.

How come? Isn't CGGMP proved to be secure?

That's a fair question. Yes, the CGGMP protocol does have a security proof that claims it's secure.

The issue, as pointed out in the vulnerability disclosure, was a subtle gap between the security proof's assumptions and the protocol's written description. The proof was written assuming that this important verification check was being performed, even though the step-by-step instructions in the paper didn't explicitly mention it.

The latest revision of the paper, CGGMP24, has corrected this by adding many more explicit security checks that were missing from the original text.

In response, we took two important steps:

1. We published a new cggmp24 crate that implements all the new, required checks from the updated paper.
2. To be extra safe, we also introduced many other checks that weren't strictly required by the paper. We did this to safeguard against the possibility that there were other assumptions made in security proofs.

A quick but important note on our patch versions

While we released cggmp21 v0.6.3 to fix the specific missing check from the disclosure, it does not include the other security improvements and additional checks that were introduced in the CGGMP24 paper.

This is why we strongly encourage everyone to migrate to cggmp24 v0.7. It is the only version that guarantees your implementation has all the latest security checks.

Vulnerability 2: Signature Forgery via Raw Signing with Presignatures

The second reported vulnerability is a known attack vector that can lead to signature forgery when a threshold signing protocol with presignatures is used for "raw signing."

First, let's quickly define these terms:

• Presignatures: In many efficient MPC protocols like CGGMP, the most intensive cryptographic work is done ahead of time to create a "presignature." This presignature is then quickly combined with message information to produce the final signature when needed.
• Raw Signing: This is a signing mode where the parties involved in signing only see the hash (or digest) of a message, not the original message itself. They are asked to sign the hash directly.

The attack can be performed when these two features are used together. In this scenario, a malicious actor can forge a signature for a message that the signers never actually approved.

Here's how the attack works in simple steps:

1. An attacker wants to get a signature for a specific message, which we'll call m.
2. The attacker takes the public part of a presignature (which they might get by corrupting a single party).
3. Instead of presenting the true hash of m (H(m)) for signing, the attacker crafts a special, different hash, which we'll call h'.
4. The attacker requests the signing system to sign h'.
5. Once the system produces a signature for h', the attacker uses a mathematical trick to transform this signature into a valid signature for the original message m.

The end result is a signature forgery. The attacker successfully obtained a signature for message m, even though the signers were never asked to approve m—they were asked to approve a completely unrelated hash h'.

Background and academic context

While this issue was reported to us in the context of CGGMP21 with additive key derivation (used in HD wallets), the vulnerability is broader. The attack does not require additive key derivation and can be performed against any protocol that combines presignatures with raw signing.

To our knowledge, this class of attack was first formally described in the paper "On the security of ECDSA with additive key derivation and presignatures" by Jens Groth and Victor Shoup. Their research highlights the potential risks of using threshold ECDSA protocols with presignatures in these specific scenarios.

A note on HD wallets (a.k.a. additive key derivation)

The Groth and Shoup paper also describes a second, related attack that was not part of the recent disclosure. This attack is specifically against protocols that use presignatures together with HD wallet derivation (or, more broadly, additive key derivation).

In this scenario, an attacker could potentially forge a signature. However, this attack is far more difficult and expensive to carry out. It requires the attacker to break 85 bits of security, an immense computational task on the scale of a state-level attacker.

For context, ECDSA is designed to provide 128 bits of security (when secp256k1 curve is used). While an 85-bit security level is still formidable, we do not tolerate such a security reduction under any circumstances. Our commitment is to the full 128-bit standard.

Mitigation strategy

Unlike the first vulnerability, which was fixed by adding a missing check, this second attack cannot be fixed at the protocol level. The issue stems from the fundamental design of protocols like CGGMP that precompute the signature component R in a presignature. Addressing this would require re-randomizing the presignature, which would effectively create an entirely new and different TSS protocol.

Therefore, the only robust solution is to forbid these vulnerable use-cases at the library's API level. This is precisely what we have done.

In our latest cggmp24 v0.7 release, we have introduced safeguards in the API to prevent the combination of features that enable these attacks. This ensures that developers using our library are protected by default.

Please be aware that our patched cggmp21 v0.6.3 version does not include this mitigation. Implementing these safeguards required making breaking changes to the library's API, which goes against the purpose of a simple patch release.

This serves as another critical reason why we strongly recommend that all users migrate to cggmp24 v0.7. It is the only version that provides these API-level protections and guarantees you benefit from the best security practices we have implemented.

Wait, why is this attack possible if CGGMP is "as secure as ECDSA"?

You are right to ask this. The CGGMP paper does indeed have a security proof that reduces the protocol's security to that of ECDSA, and standard ECDSA is not vulnerable to the attack we've described above.

The devil is in the details. The security proof provides different guarantees for different ways of using the protocol:

1. Full, Interactive Signing: When you use the complete, interactive signing protocol from start to finish for every signature, the security is indeed equivalent to standard ECDSA. In this specific mode, you can safely use features like raw signing and HD wallets.
2. Signing with Presignatures: When you use the more efficient presignature mode, the security proof relies on a different, weaker security property called "enhanced unforgeability of ECDSA." This property makes an important extra assumption that an attacker can observe signature nonce R before submitting a message to be signed.

It so happens that in the first case, the attacker cannot craft a specific message or hash to exploit a relationship with R (which is unknown in this case). Thus, it remains secure even during raw signings. This does not apply to signing with presignatures, where the attacker is more powerful and can perform trickier attacks.

In other words, the full interactive signing protocol is as secure as you'd expect. But when you use the presignature shortcut, you must also respect the additional assumptions that come with its specific security proof. For the technical reader, this distinction is formally captured in Theorem 6.6 of the CGGMP24 paper.

Building Trust Through Community Collaboration

This security disclosure isn't a story about a failure, but a testament to the strength and maturity of the multi-party computation (MPC) community. It is the open sharing of knowledge that ultimately makes security stronger. This spirit is already deeply present in the industry, and initiatives like the MPC Alliance and Lockness (LFDT), bringing together researchers and providers, are key to advancing the technology and working toward common standards. They reflect the same collective effort that makes disclosure like this one effective and valuable to everyone.

An undiscovered flaw is a liability; a disclosed and patched flaw is a sign of a system that is robust, mature, and actively maintained.

We have done our part by developing the patches. Now, we encourage you to complete the cycle. By migrating to cggmp24 v0.7, you are adopting the latest security standards forged by this community effort.

‍