T-ECDSA: Protocol document by nkuba · Pull Request #282 · threshold-network/keep-core

nkuba · 2018-09-03T16:32:08Z

Documentation for T-ECDSA Protocol.

Main focus on:

Where are the borders between the APIs, components, and phases in the T-ECDSA implementation?
What are the threat models for each component (e.g. passive vs active adversary)? What variables do we assume are private and from whom?

Previous document contained very detailed technical description which need to be moved to a second stage of this documentation process.

pdyraga

Just a quick first pass over the high-level description of phases.

pdyraga · 2018-09-05T13:47:31Z

+In this phase signers jointly generate _DSA Key_ which will be used in the Signing
+phase.
+
+Each signer generates _Secret Key Share_ and _Public Key Share_ which form


which together form?

pdyraga · 2018-09-05T13:54:03Z

+=== Key Generation
+
+[.lead]
+In this phase signers jointly generate _DSA Key_ which will be used in the Signing


which may be used or which is used sounds here better for in my opinion.

DSA Key -> ECDSA key

pdyraga · 2018-09-05T14:48:04Z

+Paillier and broadcasts the encrypted _Secret Key Share_ along with _Public Key Share_
+to other signers. +
+After receiving all shares, signers combine them to get _ECDSA Key_, consisting of
+_Encrypted Secret Key_ and _Public Key_.


Maybe it's worth to add an information that the secret key is encrypted with a threshold Paillier scheme and no single player can decrypt it?

pdyraga · 2018-09-05T14:51:55Z

+After receiving all shares, signers combine them to get _ECDSA Key_, consisting of
+_Encrypted Secret Key_ and _Public Key_.
+
+This phase requires all signers in the group to produce a valid _ECDSA Key_.


Actually, it requires all signers to cooperate in order to produce a valid key. If malicious behavior is detected we abort the protocol. There is no threshold for Key-Gen phase - worth mentioning it.

pdyraga · 2018-09-05T15:05:56Z

+
+This phase requires also _ECDSA Key_ which is a result of Key Generation Phase.
+
+To complete this round just part of signers is required. The number of signers


The minimum number of signers ?

pdyraga · 2018-09-06T15:12:18Z

+Each signer generates _Secret Key Share_ and _Public Key Share_ which together form
+_ECDSA Key Share_. +
+Since _Secret Key Share_ must always be kept private, signer encrypts it with 
+Paillier and broadcasts the encrypted _Secret Key Share_ along with _Public Key Share_


with plaintext Public Key Share ?

pdyraga · 2018-09-06T15:12:52Z

+Paillier scheme in a way that no single signer is able decrypt it.
+
+This phase requires all signers in the group to cooperate to produce a valid 
+_ECDSA Key_.+


pdyraga · 2018-09-06T15:14:59Z

+
+This phase requires also _ECDSA Key_ which is a result of Key Generation Phase.
+
+To complete this round just part of signers is required. The minimum number of signers


Comma after To complete this round?

pdyraga · 2018-09-06T15:16:37Z

+
+=== Setup
+
+==== Master Public Key


Master Public Key looks like an orphan here. We already have: Output: Commitment Master Public Key as an output of the Setup round.

I wanted to have a subsection here for Master Public Key generation, in case we would do more things under the === Setup section.

@pdyraga is this fine?

Maybe if we don't plan to do anything more under the === Setup section, let's remove it. WDYT?

I vote for leaving it here, so we know that this part is about Master Public Key

pdyraga · 2018-09-06T15:44:56Z

+
+//-
+
+. Each signer computes a set of parameters and calculates a commitment to these


Maybe we can just name those parameters explicitly here and say they are used to compute the final signature? Not going deep into details.

pdyraga · 2018-09-06T15:50:09Z

+. Each signer computes hash of _Signature Factor Public_ parameter.
+
+. Signers jointly decrypt _Encrypted Signature Unmask_ with Paillier, so each signer
+receives just a part of _Signature Unmask_.


Actually, they receive partial decryptions, not a part of Signature Unmask. There is a difference - partial decryption is not like a public key share for instance.

pdyraga · 2018-09-06T15:52:52Z

+^|_Signature.S_ partial decryption.
+|=== 
+
+. Signer validates received _Sign Round 6 Messages_. +


Are they really validated? I think we need to add some validation, per https://github.com/keep-network/keep-core/issues/246 but it's not covered in the Gennaro's paper and we are not currently doing it.

Same as in other rounds we're checking a number of messages we've received.

pdyraga

Left a few comments. This looks good for me but I'd like to have an opinion of someone not involved in the T-ECDSA.

Having the protocol documented, we should now start with another section describing what are the potential threats to each phase / round.

pdyraga · 2018-09-10T11:41:02Z

+
+This phase requires also _ECDSA Key_ which is a result of Key Generation Phase.
+
+To complete this round, just part of signers is required. The minimum number of signers


this round

Which round? Did you mean phase?

ofc phase

pdyraga · 2018-09-10T12:06:24Z

+
+^|`signerID` 
+^|`string`
+^|Signer's ID


I am not sure if it makes sense to include signerID here. I see two reasons for that:

Now it's only signerID but it will become senderID and receiverID when we'll merge the setup PR

signerID / senderID / receiverID - all of them are related to transport layer and matching messages together. I think we should focus only on T-ECDSA-specific parameters.

Thoughts?

Yeah it's unnecessary. I was documenting the code too much, but it's more about describing the protocol.

pdyraga · 2018-09-10T12:14:19Z

+
+D(_encryptedSecretKeyShare_) = _secretKeyShare_
+
+where _q_ is an order and _g_ is a generator point of an Elliptic Curve


... and D is a Decrypt function of a Paillier scheme?

I was wondering if D() is obvious or not. It's better to describe it :)

pdyraga · 2018-09-10T12:16:02Z

+****
+
+_Public Key Share_ is published with a decommitment key used in a previous round
+to produce commitment to _Public Key Share_ value.


Hmm... I am not sure. Decommitment key is not used to produce a commitment. Rather, as a result of calling commitment function, we get both commitment string and decommitment key.

In our implementation of a commitment generation we're taking a random value r and we are using it in commitment computation commitment = g^digest + he^r.

pdyraga · 2018-09-10T12:22:46Z

+
+D(_encryptedSecretKeyFactorShare_) = _secretKeyFactorShare_
+
+D(_secretKeyMultipleShare_) = η * D(_secretKey_)


and what is η here? secretKeyFactorShare?

pdyraga · 2018-09-10T12:28:25Z

+
+//-
+
+. Each signer computes _Encrypted Signature_ value which next they jointly decrypt.


What if we mention which parameters are used to compute Encrypted Signature?

nkuba · 2018-09-18T15:44:37Z

I combined Phases description with Rounds description.
I also updated Commitment Master Public Key section to reflect changes from PR #274 - @pdyraga please check if this section correctly describes how the Commitment Master Public Key will work.

pdyraga · 2018-09-20T11:09:17Z

+signing. +
+The value is calculated by a signer for each peer signer and send to them.
+The peer signer have to use received value when calculating a commitment for given
+signer.


It should be rather:

Commitment master public key is generated by each signer individually and sent to all other peer signers.

When generating a commitment that will be sent to some verifier, it's required to use that verifier's commitment master public key.

Shadowfiend

Couple more thoughts; I like this organization a lot better!

Shadowfiend · 2018-09-20T19:52:43Z

+[.lead]
+_Commitment Master Public Key_ is a value needed for commitment generation.
+This setup needs to be performed before each of two phases: key generation and 
+signing. +


In general I think we're going paragraph-heavy throughout the content here. It feels like this and the next bit can be the same paragraph without any problems. Thoughts?

I just wanted to have a general description as [.lead] and more details in next paragraph. But yes, I can fit it all into one paragraph which will be lead.

Shadowfiend · 2018-09-20T19:58:35Z

+Output::
+* _Commitment Master Public Key_ for each peer signer
+
+//-


It feels like it would be good to have an explicit heading for these rather than the //- trick; perhaps Description or Procedure?

Shadowfiend · 2018-09-20T19:58:48Z

+
+//-
+
+. A signer generates _Commitment Master Public Key_ for each peer signer and publishes it to them in _CommitmentMasterPublicKeyMessage_:


Though “publish” implies in the clear, it may be good to clarify whether this needs to be confidential or not.

Actually the implementation changed a little. A signer calculates one Commitment Master Public Key and broadcasts it to all other peer signers. The value is not confidential.

Shadowfiend · 2018-09-20T20:01:15Z

+the plaintext _ECDSA Public Key Share_ to other signers. +
+After receiving all shares, signers combine them to get the _ECDSA Key_, consisting 
+of the _Encrypted ECDSA Private Key_ and the _ECDSA Public Key_. 
+The _ECDSA Private Key_ is created by combining the Paillier-encrypted _ECDSA 


This feels like maybe it should be a numbered list? I'm unclear on the relationship between this section and the one after the “Output” block; both seem to describe the protocol, but they describe different components of it. Should they be combined somehow?

This remained from the previous version of the document where phases were described separately from rounds. Much of information here duplicates those in rounds. I combined the two parts.

Shadowfiend · 2018-09-20T20:02:36Z

+This setup needs to be performed before each of two phases: key generation and 
+signing. +
+The value is calculated by a signer for each peer signer and send to them.
+The peer signer have to use received value when calculating a commitment for given


“has to use the received value…” “for a given…”

Shadowfiend · 2018-09-20T20:24:11Z

+Paillier and this encrypted value is published along with Zero Knowledge Proof 
+Π~i~, which states that:
+
+****


This defines a sidebar, which means technically it's outside of the flow of text. It may make more sense to use a standard ==== block, perhaps with a custom role like [proof]?

Good point. For now I used [NOTE] role. It can be updated later if we want use some custom formatting.

nkuba · 2018-09-27T07:06:09Z

It's ready for a next round, gents!

Shadowfiend

One tiny note, and let's also go ahead and merge master. Then I'm good to go

nkuba · 2018-09-28T06:38:54Z

Thank you @Shadowfiend and @pdyraga for your valuable comments!
I'm ready with the updates.

pdyraga

Just three small comments, the rest looks very good.

pdyraga · 2018-09-28T08:12:33Z

+|Decommitment key for _ECDSA Public Key Share_
+
+|`secretKeyProof` 
+|`zkp.DsaPaillierKeyRangeProof`


zkp.DsaPaillierKeyRangeProof -> zkp.EcdsaPaillierKeyRangeProof

pdyraga · 2018-09-28T08:23:43Z

+|Decommitment key for a commitment to _ECDSA Private Key Factor Share_ and _ECDSA Private Key Multiple Share_
+
+|`secretKeyFactorProof` 
+|`zkp.DsaPaillierSecretKeyFactorRangeProof`


zkp.DsaPaillierSecretKeyFactorRangeProof -> zkp.EcdsaPaillierSecretKeyFactorRangeProof

pdyraga · 2018-09-28T08:27:20Z

+
+|`signatureFactorShareCommitment` 
+|`commitment.MultiTrapdoorCommitment`
+|Commitment to parameters from <<sign_round_3>>


Maybe we should be explicit here? Commitment to signature factor public share and signature unmask share ?

nkuba · 2018-09-28T08:38:30Z

@pdyraga updates are ready

pdyraga · 2018-09-28T09:24:05Z

I am good to go 👍 Waiting for a green light from @Shadowfiend

Shadowfiend

Rock 'n roll 🎸

Jakub Nowakowski added 12 commits September 3, 2018 18:31

TECDSA document setup phase

025c7d6

TECDSA document key-gen phase

c6730cf

Updates to Setup and KeyGen phases

e813ded

Signing phase round 1 and 2

b3fb74c

Document TECDSA on higher level

420bb6d

Previous document contained very detailed technical description which need to be moved to a second stage of this documentation process.

Misspelling fix

22e66cf

Table Of Content update to 4 levels

986a0c0

Split to phases and round descriptions

57a3887

Update phases description

8db88d7

Changed input output lists format

846170b

Signing rounds description

fcf75a2

Keep to margins

1bdb1c5

nkuba changed the title ~~[WIP] T-ECDSA: Protocol document~~ T-ECDSA: Protocol document Sep 5, 2018

nkuba requested a review from pdyraga September 5, 2018 11:25

pdyraga reviewed Sep 5, 2018

View reviewed changes

Updates to phases desription

6178736

pdyraga reviewed Sep 6, 2018

View reviewed changes

Jakub Nowakowski added 11 commits September 7, 2018 14:27

Updates to Master Public Key doc

d533bd8

Updates to Key Generation phase doc

766e6c2

Updates to Signing docs

8f9da7f

Remove spaces from messages names in docs

5d42ccb

broadcast -> publish

9ffc4a2

Round 3 docs updated

4727269

Fix doc of Signature Unmask partial decryption

06c4fa8

Round 6 doc updated

944af2a

ZKP Pi2i explained in doc

429d5ab

ZKP PI i explained in doc

0dc2628

ZKP PI 1,i explained in doc

4dbf4a5

pdyraga reviewed Sep 10, 2018

View reviewed changes

Signing phase description round -> phase

5f15d44

Jakub Nowakowski added 6 commits September 18, 2018 16:50

T-ECDSA -> t-ECDSA

52dfde8

Update signing description

a205044

Update name of CommitmentMasterPublicKeyShareMessage

68d3557

. -> : for message specification

56e488b

Combine rounds and phases description

7251052

Document changes to Commitment Master Public Key generation

e713950

pdyraga reviewed Sep 20, 2018

View reviewed changes

Shadowfiend suggested changes Sep 20, 2018

View reviewed changes

Jakub Nowakowski added 6 commits September 25, 2018 13:08

Clarify R and S

0cf28a7

Updated description of master public key usage

1b194e8

Procedure subsection after Input/Output

6cdc945

Updated master public key sending procedure

0c9f487

Clean duplicates in key generation procedure

bbe5bca

Changed format of ZKP blocks

28137c3

Shadowfiend suggested changes Sep 27, 2018

View reviewed changes

Comment thread docs/cryptography/tecdsa.adoc Outdated

Jakub Nowakowski added 2 commits September 28, 2018 08:36

ZKP 'certifying that'

ee26b91

Merge branch 'master' into tecdsa-doc

db5e5d1

pdyraga suggested changes Sep 28, 2018

View reviewed changes

Jakub Nowakowski added 2 commits September 28, 2018 10:37

Dsa to Ecdsa for ZKPs

7e16d5e

Update Round 3 commitment description

e392bf2

pdyraga approved these changes Sep 28, 2018

View reviewed changes

Shadowfiend approved these changes Sep 28, 2018

View reviewed changes

Shadowfiend merged commit b10f5a0 into master Sep 28, 2018

Shadowfiend deleted the tecdsa-doc branch September 28, 2018 21:29

lrsaturnino mentioned this pull request May 10, 2026

feat(tbtc): covenant signer final project branch #3882

Open


		This phase requires also _ECDSA Key_ which is a result of Key Generation Phase.

		To complete this round just part of signers is required. The number of signers


		//-

		. Each signer computes a set of parameters and calculates a commitment to these


		This phase requires also _ECDSA Key_ which is a result of Key Generation Phase.

		To complete this round, just part of signers is required. The minimum number of signers


		D(_encryptedSecretKeyShare_) = _secretKeyShare_

		where _q_ is an order and _g_ is a generator point of an Elliptic Curve


		D(_encryptedSecretKeyFactorShare_) = _secretKeyFactorShare_

		D(_secretKeyMultipleShare_) = η * D(_secretKey_)


		//-

		. Each signer computes _Encrypted Signature_ value which next they jointly decrypt.


		//-

		. A signer generates _Commitment Master Public Key_ for each peer signer and publishes it to them in _CommitmentMasterPublicKeyMessage_:

Conversation

nkuba commented Sep 3, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pdyraga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pdyraga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nkuba commented Sep 18, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Shadowfiend left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nkuba commented Sep 3, 2018 •

edited

Loading