Table of contents
Open Table of contents
What it is
Two-Party ECDSA (2P-ECDSA) is a protocol that allows two entities to jointly create digital signatures over arbitrary messages via a shared private key that neither of the participants has full access to or control over.
Conceptually 2P-ECDSA is a threshold signature scheme that only creates a valid signature if both protocol participants collaborate.
How it works
Note: The 2P-ECDSA protocol described here is a simplified version of Yehuda Lindell’s ”Fast Secure Two-Party ECDSA Signing” construction which in turn uses the Paillier Cryptosystem and its additive homomorphic properties.
We won’t go into the full details of the Paillier Cryptosystem in this writeup. However there’ll be explanations when necessary to aid understanding.
Before continuing, it’s useful to have a good understanding of the Elliptic Curve Digital Signature Algorithm (ECDSA) for which you can find an in-depth explanation in my ECDSA blog post.
In our example we assume that Alice and Bob are the two protocol participants that agree on a shared private key (that neither Alice, nor Bob knows) which will be used to sign a message collaboratively.
This signed message can then be verified by a third party via the regular ECDSA signature verification algorithm.
We’ll work with an Elliptic Curve that is of order and has a generator . All calculations are done if not stated otherwise.
Note: Parameters generated by Alice will use the subscript while for Bob’s parameters we’ll use the subscript .
The first step is for Alice and Bob to generate their private- and public keys. The private keys are created by sampling a random value from while the public keys are derived by multiplying the private key with the generator .
Alice computes:
While Bob computes:
Alice also generates a private- and public key pair for the Paillier Cryptosystem and encrypts her private key under her Paillier public key which we’ll denote as .
Alice now shares her public key , her Paillier public key as well as her encrypted private key with Bob. Bob in turn sends his public key to Alice.
As a next step, both Alice and Bob use their private- and public keys to derive a shared public key via a protocol that’s called Elliptic Curve Diffie-Hellman. This is done by multiplying the private key with the other participant’s public key.
In Alice’s case, she computes:
Whereas Bob calculates:
Next up, Alice and Bob both need to separately sample another, random value from . This value is called the “nonce” (number used once) and should never be reused. The nonce is then multiplied by the generator to derive the value which is a point on the Elliptic Curve .
Alice calculates:
Bob does the same:
The and values are then exchanged and used to derive a shared, random point by multiplying the other’s value with the local nonce . Deriving this shared value follows the same Elliptic Curve Diffie-Hellman protocol that was used to agree on the value.
In this case Alice calculates:
And Bob computes:
Given that the shared, random value is a point on the Elliptic Curve it has an - and -coordinate. We can therefore define a value as the -coordinate of :
In our example Alice initiates the signature so she needs to turn her message into a representation that can be “mapped onto” the Elliptic Curve . She does this by hashing via a cryptographic hash function , the result of which can be interpreted as a point on the curve:
This value is then sent to Bob who uses it to generate a partial signature.
In the following, Bob will use the Paillier Cryptosystem to incorporate Alice’s and his private key into the signature. The Paillier Cryptosystem works with a different modulus compared to the modulus that’s used for our Elliptic Curve calculations.
To ensure that no information gets leaked to Alice, Bob randomly samples a large value :
This value is then multiplied by and added to the value inside of the encryption. Given that all calculations are done , the will cancel out in subsequent operations.
The first ciphertext that Bob calculates is the encryption of under Alice’s Paillier public key:
Next up, he derives the constant :
The value is then used to calculate another ciphertext in which Bob uses Alice’s encrypted private key (remember that Alice sent in the beginning of the protocol) to raise it to the power of .
In Paillier’s Cryptosystem, a ciphertext raised to a constant will decrypt to the product of the plaintext and the constant.
Finally, Bob calculates an “almost signature” by multiplying both ciphertexts and .
In Paillier’s Cryptosystem, the product of two ciphertexts will decrypt to the sum of their corresponding plaintexts.
Bob now shares this partial signature with Alice.
Finally Alice can turn into a valid by multiplying the decryption of with :
The signature for the message is the tuple which Alice can send alongside the shared public key to a third party for verification.
To verify the signature Alice and Bob generated, the verifier recomputes as . Furthermore the values , and need to be calculated as follows:
The signature is valid if .
That is, if the value from the signature equals the -coordinate of Alice’s and Bob’s shared Elliptic Curve point that the verifier calculated as .
Why it works
The first thing to note is that while Alice and Bob derive a shared public key , they don’t know each other’s private keys and . In fact Bob only get’s access to Alice’s encrypted version of her private key () which is encrypted via the Paillier Cryptosystem.
By utilizing the additive homomorphic properties of Paillier’s Cryptosystem, Bob can still calculate a partial signature that incorporates information about both of their private keys and without disclosing them.
In fact, even once Alice decrypts the partial signature she doesn’t learn anything about either private key as they’re “masked” by multiplying them with the shared value and adding the hashed message to it:
The signature verification algorithm is exactly the same as the one that’s used in standard ECDSA, which means that a signature generated via 2P-ECDSA looks and behaves like a regular ECDSA signature.
Let’s use some regular algebra to convince ourselves that the signature verification works.
First, we should recall that is the hash of the message which in turn is interpreted as a point on the Elliptic Curve .
We can then use the value of the signature to isolate the multiplication of both values (Remember that will cancel out given that all calculations are done ):
By expanding and substituting for (as we’ve just calculated), we can see that :
Checking this against the signature creation process we’ve described above, we can verify that this Elliptic Curve point is the same as the one Alice and Bob derived from their individual and values.
This implies that its -coordinate is equal to the value of the signature. The signature over the message is therefore valid.
References
The following resources have been invaluable for me to learn the concepts discussed in this article.
You should definitely give them a read if you want to dive deeper into the topic.