Skip to main content

Digital Signature Scheme

Technical Summary For Cryptographers

We give a succinct summary of the cryptographic protocols used in the SDK:

  • For ECDSA we use DKLs19.
    • We used SoftSpokenOT to realize the FCOTeη\mathcal{F}^{\eta}_{\sf COTe} functionality.
    • We used MRR21 to realize the FOT1ˉ2,knC,L\mathcal{F}^{2,kn_{\mathcal{C}},{\mathcal{L}}}_{\sf OT-\bar{1}} to realize endemic 1-out-of-2 base OT of batch size knCk\cdot n_{\mathcal{C}}.
  • For EdDSA we use FROST.
  • We use BLAKE3 official Rust crate as a pseudorandom generator/function.

What is a Digital Signature Scheme?

A digital signature scheme realizes, in a sense, classical (i.e. "non-digital", handwritten) signatures but with stronger security guarantees. Unlike classical signatures, we wish that only a certain entity who owns some secret key (sk\sf sk) to be able to authorize some message m\sf m by producing a signature s\sf s which can later be verified by any entity using a public key (pk\sf pk).

More explicitly, a signature scheme is a set of three algorithms: KeyGen,Sign,Verify\sf KeyGen, Sign, Verify such that:

  • KeyGen{\sf KeyGen} outputs a pair (sk,pk)\sf (sk,pk) where sk\sf sk is a secret key, held by the key generator while pk\sf pk is a public key, that is, it is published to the public.
  • Sign(sk,m){\sf Sign(sk,m)} is a method taking a secret key sk\sf sk and a message m\sf m and outputs a signature sig\sf sig.
  • Verify(pk,m,sig){\sf Verify(pk,m, sig)} is a method taking a public pk\sf pk, a message m\sf m and a signature sig\sf sig and verifies whether sig\sf sig was created by the owner of sk\sf sk. If the verification succeeds it returns success\sf success and if it fails it returns fail\sf fail.

A signature scheme should be both correct and secure that is:

  • Correctness means that a signature generated by an "honest" signer (i.e. a signer who knows the secret key sk\sf sk) should always be successfully verified. In mathmatical notation it means that for all (sk,pk)\sf (sk,pk) output by KeyGen\sf KeyGen and for all message m\sf m we have:
    Verify(pk,m,Sign(sk,m))=success\sf Verify(pk,m, Sign(sk,m)) = success
  • Security means that a malicious entity who doesn't know the secret key sk\sf sk and wishes to sign some predetermined message m\sf m^* should not be able to do this 1 even if it is being given signatures of other messages of its choice.2

Notice that the security guarantees do not hold against the scenario where the secret key falls into the hands of a malicious entity. This is a key reason to use Sodot MPC SDK.

Types of Digital Signature Schemes

Along the years a large number of digital signature schemes have been introduced and in the past few decades two main signature scheme have become prevalent in wide range of use cases:

Indeed, each of these schemes has its own triple of KeyGen,Sign,Verify\sf KeyGen, Sign, Verify algorithms. We will not be elaborting on these two schemes here, the interested reader can follow the links above for futher reading.


While these two digital signature algorithms have similar names, they are very different from one another.


Sodot MPC SDK supports both the ECDSA and EdDSA schemes.

What is a Threshold Signature Scheme?

As we've seen, the security of the signature scheme holds as long as the secret key is stored securely. But what does it even mean "securely" in this context? Well, the private key should be both secret and persistent.

  • Secret in the sense that no malicious entity should be able to retrieve the key.
  • Persistent in the sense that the entity who is eligible to use the key is indeed able to use it.

One way to ensure these two properties is by storing the secret key in a Hardware Security Module (HSM). This, however, introduces a single point of failure, as in the case of a loss or corruption of the HSM, the key material stored inside of it is lost. Another, more engineering-oriented argument against HSMs is that they introduce a scalability bottleneck as they possess limited processing capacity.

To address the issues above, cryptographers have come up with threshold signature schemes (TSS). These signature schemes operate in a distributed manner, between a set of NN clients with respect to a predetermined threshold TT where TNT \leq N. Informally, the secret key is split between the NN clients such that any subset of at least TT of them is capable of signing any message.

Slightly more formally, we say a signature scheme is a threshold signature scheme if on top of the existing KeyGen,Sign,Verify\sf KeyGen, Sign, Verify two additional algorithms are introduced:

  • DistributedKeyGen\sf DistributedKeyGen is a distributed algorithm between the NN clients resulting in a public key pk\sf pk and NN secret key shares sk1,,skN{\sf sk_1,\ldots,sk}_N where client number ii holds ski\sf sk_i.
  • DistributedSign(ski1,,skiT,m)\sf DistributedSign(sk_{i_1},\ldots,sk_{i_T}, m) is a distributed algorithm taking place between TT clients with secret shared ski1,,skiT\sf sk_{i_1},\ldots,sk_{i_T} resulting in a signature sig\sf sig on a message m\sf m.

Similarly, we require both correctness and security:

  • Correctness for every NN and every 1TN1\leq T\leq N, and every public key pk\sf pk and secret key shares sk1,,skN\sf sk_1,\ldots,sk_N generated by DistributedKeyGen\sf DistributedKeyGen and every subset of TT secret shared ski1,,skiT\sf sk_{i_1},\ldots,sk_{i_T} and every message mm it holds that:
    Verify(pk,m,DistributedSign(ski1,,skiT,m))=success\sf Verify(pk, m, DistributedSign(sk_{i_1},\ldots,sk_{i_T},m)) = success
  • Security every malicious entity holding less than TT secret shares should not be able to sign a predetermined message mm^* even if being given signatures of other messages of its choice.

The security guarantees of the TSS do not hold against the leakage of TT secret shares. Therefore, TT should be set sufficiently high.


Generating a valid signature is impossible if NTN-T shares have been lost. Therefore, TT should be set not too close to NN.

How should TT be set with respect to NN?

The above two notes result in a somewhat contradictory conclusion, that is:

  • We want persistency, so we can't have T=NT=N as in this extreme case, the loss of a single key share implies inability to sign any message.
  • We also want security, se we can't have T=1T=1 as in this extreme case, the loss of a single key share implies loss of all security guarantees.

Therefore, setting TT somewhere in the middle makes most sense in practice.


Sodot MPC SDK supports both ECDSA and EdDSA TSS for all values of threshold TT and any number of participants NN.

  1. Cryptographers usually refer to this "inability" as being able to do this with very small probability.
  2. This notion is known as "EUF-CMA" security.