Rethinking Signatures

PUBLISHED

03.17.2025

AUTHOR

José Reis and Manuel B. Santos

CATEGORY

Project Update

Overcoming Risks through Decentralized Cryptography

Why signatures?

Signatures play an important role in cryptography to ensure trust in communications. Firstly, they are used as a mechanism to guarantee that a signed message truly comes from the claimed sender. This way the receiver knows who is sending the message. Secondly, by confirming that the message was not tampered while reaching the receiver, they protect the integrity of the message. Finally, once a message is signed, the sender cannot deny its authorship, ensuring accountability.

These properties are especially valuable in a blockchain setting where users perform cryptocurrency transactions, such as Bitcoin or ETH. A transaction can only happen if the user authorizes it, and all the participants in the blockchain want to be sure that the transaction was properly authorized, the amount remains unchanged, and the sender cannot later deny the transaction. For these reasons, signatures are used to authorize transactions of cryptocurrencies – without a signature the transaction of digital assets is simply impossible.

 

Risks associated with signatures

To create a signature, users must use a private key. An immediate consequence of this is that if a user loses the private key, they can no longer authorize transactions making their cryptocurrencies inaccessible, and then are considered lost. For instance, one user lost access to a digital wallet containing over $400 million in ETH ^{\text{1}}, and about 3 million Bitcoins are considered lost ^{\text{2 , 3}}. This risk is even more relevant today, as cryptocurrencies are reaching historical high values, with Bitcoin recently surpassing the $100k value ^{\text{4}}. In short, losing the private key is a real risk with profound consequences.

To diminish the risk of losing their private key, the users often feel compelled to store it in some form. However, most users are not security  experts and probably adopt poor storage practices, like saving it in plain text files on devices or storing it in emails or cloud services. This increases the risks of falling victim to hackers or phishing attacks.

From a user’s perspective, it seems they have to choose between two risks: either not storing the private key and risking its loss or storing it but becoming vulnerable to attacks. Ideally, there would be a way to mitigate both risks. Something where the key is distributed across multiple locations, yet even if some are compromised the attacker would not be able to use it and the user could still have control over their assets.

 

A solution

An answer to this problem is the decentralization of the signing process through threshold signature schemes (TSS), where a set of n parties holds shares of the signing key and can sign a message if and only if at least t<n agree to do it ^{\text{5}}. In this setting, when a user wants to authorize a transaction, they simply ask the signing network to sign it and all the participating nodes collaborate to sign the transaction. The user doesn’t directly sign the message but just provides it to the network. This tackles the issues discussed above. On one hand, this removes the single point of failure of the previous setup – if the user loses the key, they can no longer sign and perform transactions. On the other hand, it addresses the storage issue because the key is not stored in a single place. Instead, shares of the key are distributed among different parties. However, one needs to consider another potential source of attacks when using a decentralized signing process: Network Attacks. If enough parties within the signing network collude, they could perform a transaction without the user’s consent. That’s why, even though they are using threshold cryptographic techniques, the singing nodes should not be controlled by the same entity.

To address inherited risks of threshold techniques, NIST issued a call in 2021 ^{\text{6}} to establish some criteria for multi-party threshold schemes.

  • Active security model: There are two options for adversarial behavior. The passive security model assumes adversaries follow the protocol but try to learn information from communications. The active security model allows corrupted parties to deviate from the protocol, aiming not only to ensure privacy but also to maintain the correctness of the output. NIST’s criteria recommend the active security model for stronger protection, since it aligns better with real-world scenarios where parties may not follow the protocol.
  • Dynamic adversaries: These schemes should assume that the adversary is dynamic, not static. This means that the computing parties involved can be corrupted by the adversary not just at the start of the protocol, but also during its execution. As a consequence, one of the NIST’s criteria is that the protocol should include mechanisms to recover corrupted parties to an uncorrupted state.
  • Availability: Due to the adversarial model with active attackers, the protocol must include features related to availability. This means incorporating mechanisms like identifiable abort, robustness, fairness or guaranteed output delivery. Identifiable abort ensures that honest parties can identify at least one of the corrupted parties and abort the protocol ^{\text{7}}. Robustness stands for the ability of guaranteeing the correctness of the output, ^{\text{8}}. The fairness property guarantees that if the corrupted parties receive the output, then the honest parties receive it as well. Guaranteed output delivery, which implies fairness, ensures that the corrupted parties cannot prevent the honest parties from receiving the output, ^{\text{9}}.

 

These features are supported by the threshold signing protocol CGGMP24 ^{\text{10}} and its predecessor CGGMP21 ^{\text{11}}. The Linux Foundation Decentralized Trust (LFDT) has implemented CGGMP21 in ^{\text{12}}, though it still does not support identifiable abort, for example. This CGGMP21 implementation is supported by Nillion Threshold Signature library and we are contributing to add the identifiable abort feature, providing a more complete implementation of this threshold protocol.

 

Opportunities

This decentralization of the signing process opens the door for a safer wallet ecosystem, which can be further enhanced by programmability. Consider the following use case: a user wants to perform a transaction and requests the signing network to sign it. Up to this point, the process mirrors the typical decentralized signing approach. However, one could add layers to this process. For example, a decentralized network could perform various checks on the transaction, or previous transaction, or could do secure multi-party computation (MPC) of fraud detection protocols like the PageRank algorithm to detect fraudulent transactions as proposed in ^{\text{13}} or ^{\text{14}}. With a history of transactions, these algorithms could determine the risk of a given transaction being fraudulent or to an address associated with fraudulent behaviour. The signing network could also perform other checks, like confirming the value does not exceed a threshold previously defined by the user. In this setup, each node performs these types of checks or runs these algorithms and, if the transaction passes, the nodes sign it. Otherwise, the nodes don’t sign it and provide an explanation.

Now, let’s add AI agents into the equation. This can bring several benefits to the user experience (UX) by allowing users to initiate transactions by giving instruction in everyday language to the AI agent, and then the AI agent would take care of performing the transaction. However, this raises safety concerns. By trusting, for example, the private key to the AI agent it could happen that the key is leaked. A solution to address this concern is to use threshold signatures, as we did in ^{\text{15}} by introducing DeFAI. There, developers create agents that can sign transactions without having access to the user’s private key! The user simply interacts with the AI agent through natural language, and the AI agent takes care of the rest by using Nillion’s Signature Tools. With regards to UX this already brings some benefits, after all the key management becomes lighter and also it is much easier to perform the operations that the user wants to perform as all communication with the AI agent is done in everyday language.

The UX can be further enhanced by granting AI agents greater autonomy while taking advantage of the decentralization of the signing process to provide security measures. Namely, users can create and use an Autonomous AI agent that interacts directly with the blockchains, smart contracts or wallet providers. To guarantee security, the user sets several rules that the AI agent must follow when performing financial operations. Once the AI agent initializes a transaction, it does not need to verify with the user. Instead, it  uses the decentralized signing network, which checks whether the transaction complies with the user defined-rules. This allows for greater automation, since users just need to specify the kind of transaction they want to perform and the autonomous AI agents do all the work. Moreover, an Autonomous AI agent can learn from past fraudulent transactions and scams, and can actively avoid participating in similar operations. This reduces the risk of fraud and scams. Thus, the use of autonomous AI agents improves UX and provides several practical benefits, while the decentralized signing network avoids that the AI agent goes rogue by performing checks before signing the transactions.

 

Conclusion

All in all, the decentralized signing process offers several advantages. From a user’s perspective, it tackles the single point of failure of a user losing access to digital assets while it addresses some of the issues concerning the storage of private keys. Additionally, it enhances the UX by providing easier key management for the user. While there are inherited risks in the decentralized signing process, namely network attacks, these risks can be mitigated by following NIST’s criteria. Nillion’s tools already include SecretSigner which allows users to securely sign messages and transactions using threshold cryptographic techniques! Currently, it supports threshold ECDSA, with more threshold signatures on the way!

On top of the user advantage in regards to security, one could also include programmability to the signing network. Either to perform some checks on the transactions that the user directly wants to perform or to check that an autonomous AI agent created by the user is actually following the rules set by the user.

The combination of threshold signatures, autonomous AI agents and programmability would improve the UX considerably by facilitating the key management and the automation of transactions.

 

Acknowledgments

We thank José Cabrero-Holgueras for comments on this post.

References

  1. Coghlan, Jesse. “LHV Bank Founder Has $470M Worth of Ethereum, but Lost His Private Key.” Cointelegraph, 7 Nov. 2023, https://cointelegraph.com/news/lhv-bank-founder-owner-mystery-stuck-ether.
  2. Chainalysis Team. “60% of Bitcoin is Held Long Term as Digital Gold. What About the Rest?” Chainanalysis, 18 Jun. 2022 https://www.chainalysis.com/blog/bitcoin-market-data-exchanges-trading/.
  3. Bansal, Dhruv. “Bitcoin Data Science (Pt. 2): The Geology of Lost Coins” Unchained, 29 May 2018 https://www.unchained.com/blog/geology-of-lost-coins.
  4. Partz, Hele. “Bitcoin price hits $100K for first time in history” Cointelegraph, 5 Dec. 2024 https://cointelegraph.com/news/bitcoin-price-hits-100-000-first-time-new-all-time-high.
  5. Desmedt, Y.: Society and group oriented cryptography: A new concept. In: Pomerance, C. (ed.) CRYPTO’87. LNCS, vol. 293, pp. 120–127. Springer, Berlin, Heidelberg (Aug 1988). https://doi.org/10.1007/3-540-48184-2_8
  6. NIST: Call 2021a for feedback on criteria for threshold schemes (07 2021). https://csrc.nist.gov/csrc/media/Projects/threshold-cryptography/documents/MPTC-call2021a-feedback.pdf
  7. Rivinius, M., Reisert, P., Rausch, D., K¨usters, R.: Publicly accountable robust multi-party computation. In: 2022 IEEE Symposium on Security and Privacy. pp. 2430–2449. IEEE Computer Society Press (May 2022). https://doi.org/10.1109/SP46214.2022.9833608
  8. Hirt, M., Maurer, U.M.: Robustness for free in unconditional multi-party computation. In: Kilian, J. (ed.) CRYPTO 2001. LNCS, vol. 2139, pp. 101–118. Springer, Berlin, Heidelberg (Aug 2001). https://doi.org/10.1007/3-540-44647-8_6
  9. Cohen, R., Lindell, Y.: Fairness versus guaranteed output delivery in secure multiparty computation. Journal of Cryptology 30(4), 1157–1186 (Oct 2017). https://doi.org/10.1007/s00145-016-9245-5
  10. Canetti, R., et al. UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts, eprint 21 Oct 2024 version: https://eprint.iacr.org/2021/060
  11. Canetti, R., et al. UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts, CCS’20.
  12. cggmp21, State-of-art threshold ECDSA in Rust, https://github.com/LFDT-Lockness/cggmp21
  13. Sangers, A., van Heesch, M., Attema, T., Veugen, T., Wiggerman, M., Veldsink, J., Bloemen, O., Worm, D.T.H.: Secure multiparty pagerank algorithm for collaborative fraud detection. In: IACR Cryptology ePrint Archive (2019), https://api.semanticscholar.org/CorpusID:52977549
  14. Cozzo, D., Smart, N.P., Alaoui, Y.T.: Secure fast evaluation of iterative methods: With an application to secure PageRank. In: Paterson, K.G. (ed.) CT-RSA 2021. LNCS, vol. 12704, pp. 1–25. Springer, Cham (May 2021). https://doi.org/10.1007/978-3-030-75539-3_1
  15. Orpilla, Steph. “Combining AI Agents and Nillion Signatures for Smarter Safer DeFAI” Nillion.com, 17 Jan 2025 https://nillion.com/news/combining-ai-agents-and-nillion-signatures-for-smarter-safer-defai/.

 

 

 

Image

Follow @BuildOnNillion on X/Twitter for more updates like these