idnits 2.17.1 draft-hallambaker-threshold-sigs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Implementations MUST not use threshold signatures in applications where signature values are used in place of cryptographic digests as unique content identifiers. -- The document date (13 January 2021) is 1198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 1266, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 13 January 2021 5 Expires: 17 July 2021 7 Threshold Signatures in Elliptic Curves 8 draft-hallambaker-threshold-sigs-06 10 Abstract 12 A Threshold signature scheme is described. The signatures created 13 are computationally indistinguishable from those produced using the 14 Ed25519 and Ed448 curves as specified in RFC8032 except in that they 15 are non-deterministic. Threshold signatures are a form of digital 16 signature whose creation requires two or more parties to interact but 17 does not disclose the number or identities of the parties involved. 19 https://mailarchive.ietf.org/arch/browse/cfrg/ 20 (http://whatever)Discussion of this draft should take place on the 21 CFRG mailing list (cfrg@irtf.org), which is archived at . 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 17 July 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1.1. HSM Binding . . . . . . . . . . . . . . . . . . . . . 4 56 1.1.2. Code Signing . . . . . . . . . . . . . . . . . . . . 4 57 1.1.3. Signing by Redundant Services . . . . . . . . . . . . 5 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 63 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Direct shared threshold signature . . . . . . . . . . . . 7 65 3.2. Shamir shared threshold signature . . . . . . . . . . . . 9 66 3.3. Stateless computation of final share . . . . . . . . . . 10 67 3.3.1. Side channel resistance . . . . . . . . . . . . . . . 11 68 3.4. Security Analysis . . . . . . . . . . . . . . . . . . . . 12 69 3.4.1. Calculation of r values . . . . . . . . . . . . . . . 12 70 3.4.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 13 71 3.4.3. Malicious Contribution Attack . . . . . . . . . . . . 13 72 3.4.4. Rogue Key Attack . . . . . . . . . . . . . . . . . . 13 73 4. Ed2519 Signature . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Ed448 Signature . . . . . . . . . . . . . . . . . . . . . . . 15 75 6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Direct Threshold Signature Ed25519 . . . . . . . . . . . 16 77 6.2. Direct Threshold Signature Ed448 . . . . . . . . . . . . 19 78 6.3. Shamir Threshold Signature Ed25519 . . . . . . . . . . . 22 79 6.4. Shamir Threshold Signature Ed448 . . . . . . . . . . . . 25 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 81 7.1. Rogue Key attack . . . . . . . . . . . . . . . . . . . . 28 82 7.2. Disclosure or reuse of the value r . . . . . . . . . . . 28 83 7.3. Resource exhaustion attack . . . . . . . . . . . . . . . 28 84 7.4. Signature Uniqueness . . . . . . . . . . . . . . . . . . 28 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 87 10. Normative References . . . . . . . . . . . . . . . . . . . . 29 88 11. Informative References . . . . . . . . . . . . . . . . . . . 29 90 1. Introduction 92 Threshold encryption and key generation provide compelling advantages 93 over single private key approaches because splitting the private key 94 permits the use of that key to be divided between two or more roles. 96 All existing digital signatures allow the signer role to be divided 97 between multiple parties by attaching multiple signatures to the 98 signed document. This approach, known as multi-signatures, is 99 distinguished from a threshold signature scheme in that the identity 100 and roles of the individual signers is exposed. In a threshold 101 signature scheme, the creation of a single signature requires the 102 participation of multiple signers and the signature itself does not 103 reveal the means by which it was constructed. 105 Rather than considering multi-signatures or threshold signatures to 106 be inherently superior, it is more useful to regard both as two 107 points on a continuum of choices: 109 Multi-signatures Multiple digital signatures on the same document. 110 Multi-signatures are simple to create and provide the verifier 111 with more information but require the acceptance criteria to be 112 specified independently of the signature itself. This requires 113 that the application logic or PKI provide some means of describing 114 the criteria to be applied. 116 Multi-party key release A single signature created using a single 117 private key stored in an encrypted form whose use requires 118 participation of multiple key decryption shares. 120 Threshold signatures A single signature created using multiple 121 signature key shares. Signature creation may be subject to 122 complex criteria such as requiring an (n,t) quorum of signers but 123 these criteria are fixed at the time the signature is created 125 Aggregate Signatures A single signature created using multiple 126 signature key shares such that validation of the aggregate 127 signature serves to validate the participation of each of the 128 individual signers. 130 This document builds on the approach described in 131 [draft-hallambaker-threshold] to define a scheme that creates 132 threshold signatures that are computationally indistinguishable from 133 those produced according to the algorithm specified in [RFC8032]. 134 The scheme does not support the creation of aggregate signatures. 136 The approach used is based on that developed in FROST [Komlo]. This 137 document describes the signature scheme itself. The techniques used 138 to generate keys are described separately in 139 [draft-hallambaker-threshold]. 141 As in the base document, we first describe signature generation for 142 the case that _n_ = _t_ using 'direct' coefficients, that is the 143 secret scalar is the sum of the secret shares. We then show how the 144 scheme is modified using Shamir secret sharing [Shamir79] and 145 Lagrange coefficients for the case that _n_ > _t_. 147 1.1. Applications 149 Threshold signatures have application in any situation where it is 150 desired to have finer grain control of signing operations without 151 this control structure being visible to external applications. It is 152 of particular interest in situations where legacy applications do not 153 support multi-signatures. 155 1.1.1. HSM Binding 157 Hardware Security Modules (HSMs) prevent accidental disclosures of 158 signature keys by binding private keys to a hardware device from 159 which it cannot be extracted without substantial effort. This 160 provides effective mitigation of the chief causes of key disclosure 161 but requires the signer to rely on the trustworthiness of a device 162 that represents a black box they have no means of auditing. 164 Threshold signatures allow the signer to take advantage of the key 165 binding control provided by an HSM without trusting it. The HSM only 166 contributes one of the key shares used to create the signature. The 167 other is provided by the application code (or possibly an additional 168 HSM). 170 1.1.2. Code Signing 172 Code signing is an important security control used to enable rapid 173 detection of malware by demonstrating the source of authorized code 174 distributions but places a critical reliance on the security of the 175 signer's private key. Inadvertent disclosure of code signing keys is 176 commonplace as they are typically stored in a form that allows them 177 to be used in automatic build processes. Popular source code 178 repositories are regularly scanned by attackers seeking to discover 179 private signature keys and passwords embedded in scripts. 181 Threshold signatures allow the code signing operation to be divided 182 between a developer key and an HSM held locally or by a signature 183 service. The threshold shares required to create the signature can 184 be mapped onto the process roles and personnel responsible for 185 authorizing code release. This last concern might be of particular 186 advantage in open source projects where the concentration of control 187 embodied in a single code signing key has proved to be difficult to 188 reconcile with community principles. 190 1.1.3. Signing by Redundant Services 192 Redundancy is as desirable for trusted services as for any other 193 service. But in the case that multiple hosts are tasked with 194 compiling a data set and signing the result, there is a risk of 195 different hosts obtaining a different view of the data set due to 196 timing or other concerns. This presents the risk of the hosts 197 signing inconsistent views of the data set. 199 Use of threshold signatures allows the criteria for agreeing on the 200 data set to be signed to be mapped directly onto the requirement for 201 creating a signature. So if there are three hosts and two must agree 202 to create a signature, three signature shares are created and with a 203 threshold of two. 205 2. Definitions 207 This section presents the related specifications and standard, the 208 terms that are used as terms of art within the documents and the 209 terms used as requirements language. 211 2.1. Requirements Language 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2.2. Defined Terms 219 See [draft-hallambaker-threshold]. 221 2.3. Related Specifications 223 This document extends the approach described in 224 [draft-hallambaker-threshold] to support threshold signatures. The 225 deterministic mechanism described in specification 226 [draft-hallambaker-mesh-udf] is used to generate the private keys 227 used in the test vectors. 229 2.4. Implementation Status 231 The implementation status of the reference code base is described in 232 the companion document [draft-hallambaker-mesh-developer]. 234 3. Principles 236 The threshold signatures created according to the algorithms 237 described in this document are compatible with but not identical to 238 the signatures created according to the scheme described in 239 [RFC8032]. In particular: 241 * The signature verification algorithm is unchanged. 243 * The unanimous threshold scheme produces values of _R_ and _S_ that 244 are deterministic but different from the values that would be 245 obtained by using the aggregate private key to sign the same 246 document. 248 * The deterministic quorate threshold scheme produces values of _R_ 249 and _S_ that are deterministic for a given set of signers but will 250 change for a different set of signers or if the aggregate private 251 key was used to sign the same document. 253 * ?The non-deterministic quorate threshold scheme produces values of 254 _R_ and _S_ that will be different each time the document is 255 signed. 257 Recall that a digital signature as specified by [RFC8032] consists of 258 a pair of values _S_, _R_ calculated as follows: 260 _R_ = _r.B_ 262 S = _r_ + _k.s_ mod _L_ 264 Where _B_ is the base point of the elliptic curve. 266 _r_ is an unique, unpredictable integer value such that 0 r L 268 _k_ is the result of applying a message digest function determined 269 by the curve (Ed25519, Ed448) to a set of parameters known to the 270 verifier which include the values _R_, _A_ and PH(_M_). 272 _A_ is the public key of the signer, _A_ = _s.B_ 274 PH(_M_) is the prehash function of the message value. 276 _s_ is the secret scalar value 277 _L_ is the order of the elliptic curve group. 279 To verify the signature, the verifier checks that: 281 _S.B_ = _R_ + _k.A_ 283 This equality must hold for a valid signature since: 285 _S.B_ = (_r_ + _k.s_)._B_ 287 = _r.B_ +_k_.(_s.B_) 289 = _R_ + _k.A_ 291 The value _r_ plays a critical role in the signature scheme as it 292 serves to prevent disclosure of the secret scalar. If the value _r_ 293 is known, _s_ can be calculated as _s_ = (_S-r_)._k_^(-1) mod _L_. It 294 is therefore essential that the value _r_ be unguessable. 296 Furthermore, if the same value of _r_ is used to sign two different 297 documents, this results two signatures with the same value _R_ and 298 different values of _k_ and _S_. Thus 300 _S_(1)_ = _r_ + _k_(1)_._s_ mod _L_ 302 S_(2) = _r_ + _k_(2).s mod L_ 304 s = (_S_(1)_ - _S_(2)_)(_k_(1)_ - _k_(2)_)^(-1) mod _L_ 306 The method of constructing _r_ MUST ensure that it is unique and 307 unguessable. 309 3.1. Direct shared threshold signature 311 A threshold signature R, S is constructed by summing a set of 312 signature contributions from two or more signers. For the case that 313 the composite private key is the sum of the key shares (_n_ = _t_), 314 each signer _i_ provides a contribution as follows: 316 A_(i) = s_(i).B 318 R_(i) = r_(i).B 320 S_(i) = r_(i) + k.s_(i) mod L 322 Where s_(i) and r_(i) are the secret scalar and unguessable value for 323 the individual signer. 325 The contributions of signers {1, 2, ... n} are then combined as 326 follows: 328 R = R_(1) + R_(2) + ... + R_(n) 330 S = S_(1) + S_(2) + ... + S_(n) 332 A = s.B 334 Where s = (s_(1) + s_(2) + ... + s_(n)) mod L 336 The threshold signature is verified in the same manner as before: 338 S.B = R + k.A 340 Substituting for S.B we get: 342 = (S_(1) + S_(2) + ... + S_(n)).B 344 = S_(1).B + S_(2).B + ... + S_(n).B 346 = (r_(1) + k.s_(1)).B + (r_(2) + k.s_(2)).B + ... + (r_(n) + 347 k.s_(n)).B 349 = (r_(1).B + k.s_(1).B) + (r_(2).B + k.s_(2).B) + ... + (r_(n).B + 350 k.s_(n).B) 352 = (R1 + k.A1) + (R1 + k.A1) + ... + (Rn + k.An) 354 Substituting for R + k.A we get: 356 = R_(1) + R_(2) + ... + R_(n) + k.(A_(1) + A_(2) + ... + A_(n)) 358 = R_(1) + R_(2) + ... + R_(n) + k.A_(1) + k.A_(2) + ... + k.A_(n) 360 = (R_(1) + k.A_(1)) + (R_(1) + k.A_(1)) + ... + (R_(n) + k.A_(n)) 362 As expected, the operation of threshold signature makes use of the 363 same approach as threshold key generation and threshold decryption as 364 described in [draft-hallambaker-threshold]. As with threshold 365 decryption it is not necessary for each key share holder to have a 366 public key corresponding to their key share. All that is required is 367 that the sum of the secret scalar values used in calculation of the 368 signature modulo the group order be the value of the aggregate secret 369 scalar corresponding to the aggregate secret key. 371 While verification of [RFC8032] signatures is unchanged, the use of 372 threshold signatures requires a different approach to signing. In 373 particular, the fact that the value k is bound to the value R means 374 that the participants in the threshold signature scheme must agree on 375 the value R before the value k can be calculated. Since k is 376 required to calculate the signature contributions S_(i) can be 377 calculated, it is thus necessary to calculate the values R_(i) and 378 S_(i) in separate phases. The process of using a threshold signature 379 to sign a document thus has the following stages orchestrated by a 380 dealer as follows: 382 0. The dealer determines the values F, C and PH(M) as specified in 383 [RFC8032] and transmits them to the signers {1, 2, ... n}. 385 1. Each signer generates a random value r_(i) such that 1 r_(i) L, 386 calculates the value R_(i) = r_(i).B and returns R to the dealer 387 . 389 2. The dealer calculates the value R = R_(1) + R_(2) + ... + R_(n) 390 and transmits R and A to the signers {1, 2, ... n}. 392 3. Each signer uses the suppled data to determine the value k and 393 hence S_(i) = r_(i) + k.s_(i) mod L and transmits it to the 394 dealer . 396 4. The dealer calculates the value S = S_(1) + S_(2) + ... + S_(n) 397 and verifies that the resulting signature R, S verifies according 398 to the mechanism specified in [RFC8032]. If the signature is 399 correct, the dealer publishes it. Otherwise, the dealer MAY 400 identify the signer(s) that provided incorrect contributions by 401 verifying the values R_(i) and S_(i) for each. 403 For clarity, the dealer role is presented here as being implemented 404 by a single party. 406 3.2. Shamir shared threshold signature 408 To construct a threshold signature using shares created using Shamir 409 Secret Sharing, each private key value _s_(i)_ is multiplied by the 410 Lagrange coefficient _l_(i)_ corresponding to the set of shares used 411 to construct the signature: 413 A_(i) = s_(i)l_(i).B 415 R_(i) = r_(i).B 417 _S_(i) = ri + klisi mod L_ 418 It is convenient to combine the derivation of _S_(i)_ for the 419 additive and Shamir shared threshold signatures by introducing a key 420 multiplier coefficient _c_(i)_: 422 _S_(i) = ri + kcisi mod L_ 424 Where _c_(i)_ = 1 for the additive shared threshold signature 426 _c_(i)_ = _l_(i)_ for the Shamir shared threshold signature 428 3.3. Stateless computation of final share 430 One of the chief drawbacks to the algorithm described above is that 431 it requires signers to perform two steps with state carried over from 432 the first to the second to avoid reuse of the value _r_(i)_. This 433 raises particular concern for implementations such as signature 434 services or HSMs where maintaining state imposes a significant cost. 436 Fortunately, it is possible to modify the algorithm so that the final 437 signer does not need to maintain state between steps: 439 0. All the signers except the final signer _F_ generate their value 440 _r_(i)_ and submit the corresponding value _R_(i)_ to the dealer 442 1. Dealer calculates the value _R_ - _R_(F)_ and sends it to the 443 final signer together with the all the other parameters required 444 to calculate _k_ and the final signer's key multiplier 445 coefficient _c_(F)_. 447 2. The final signer generates its value _r_(F)_ 449 3. The final signer calculates the value _R_(F)_ from which the 450 values _R_ and _k_ can now be determined. 452 4. The final signer calculates its key share contribution _S_(F) = 453 rF + kcFsF mod L._ 455 5. The final signer returns the values _S_(F)_ and _R_ to the 456 dealer. 458 6. The dealer reports the value R to the other signers and continues 459 the signature process as before. 461 While this approach to stateless computation of the signature 462 contributions is limited to the final share, this is sufficient to 463 cover the overwhelming majority of real-world applications where _n_ 464 = _t_ = 2. 466 Note that the final signer MAY calculate its value _r_(F)_ 467 deterministically provided that the parameters _R_ - _R_(F)_ and 468 _c_(F)_ are used in its determination. Other signers MUST NOT use a 469 deterministic means of generating their value _r_(i)_ since the 470 information known to them at the time this parameter is generated is 471 not sufficient to fix the value of _R_. 473 3.3.1. Side channel resistance 475 The use of Kocher side channel resistance as described in 476 [draft-hallambaker-threshold] entails randomly splitting the private 477 key into two shares and performing the private key operation 478 separately on each share to avoid repeated operations using the same 479 private key value at the cost of performing each operation twice. 481 This additional overhead MAY be eliminated when threshold approaches 482 are used by applying blinding factors whose sum is zero to each of 483 the threshold shares. 485 For example, if generation of the threshold signature is divided 486 between an application program A and an HSM B using the final share 487 approach to avoid maintaining state in the HSM, we might generate a 488 blinding factor thus: 490 0. A generates a random nonce _n_(A)_ and sends it to B with the 491 other parameters required to generate the signature. 493 1. B generates a random nonce _n_(B)_ 495 2. B calculates the blinding factor _x_ by calculating 496 _H_(_n_(A,)nB) where H is a strong cryptographic digest function 497 and converting the result to an integer in the range 1 x L._ 499 3. B calculates the signature parameters as before except that the 500 threshold signature contribution is now _S_(B) = rB + k(cBsB + x) 501 mod L._ 503 4. B returns the nonce _n_(B)_ to A with the other parameters. 505 5. A calculates the blinding factor _x_ using the same approach as B 507 6. A calculates the signature parameters as before except that the 508 threshold signature contribution is now _S_(A) = rA + k(cAsA - x) 509 mod L._ 511 This approach MAY be extended to the case that _t_ > 2 by 512 substituting a Key Derivation Function (e.g. [RFC5860]) for the 513 digest function. 515 3.4. Security Analysis 517 We consider a successful breach of the threshold signature scheme to 518 be any attack that allows the attacker to create a valid signature 519 for any message without the participation of the required threshold 520 of signers. 522 Potential breaches include: 524 * Disclosure of the signature key or signature key share. 526 * Modification of signature data relating to message M to allow 527 creation of a signature for message M'. 529 * Ability of one of the signers to choose the value of the aggregate 530 public key. 532 * Access control attacks inducing a signer to create a signature 533 contribution that was not properly authenticated or authorized. 535 We regard attacks on the access control channel to be out of scope 536 for the threshold signature algorithm, though they are certainly a 537 concern for any system in which a threshold signature algorithm is 538 employed. 540 We do not consider the ability of a signer to cause creation of an 541 invalid signature to represent a breach. 543 3.4.1. Calculation of r values 545 The method of constructing the values _r_(i)_ MUST ensure that each 546 is unique and unguessable both to external parties, the signers and 547 the dealer. The deterministic method specified in [RFC8032] cannot 548 be applied to generation of the values r_(i) as it allows the dealer 549 to cause signers to reveal their key shares by requesting multiple 550 signature contributions for the same message but with different 551 values of _k_. In particular, requesting signature contributions for 552 the same message: 554 With different Lagrange coefficients. 556 With a false value of _R_ 558 To avoid these attacks, the value r_(i) is generated using a secure 559 random number generator. This approach requires the signer to ensure 560 that values are never reused requiring that the signing API maintain 561 state between the first and second rounds of the algorithm. 563 While there are many approaches to deterministic generation of r_(i) 564 that appear to be sound, closer inspection has demonstrated these to 565 be vulnerable to rogue key and rogue contribution attacks. 567 3.4.2. Replay Attack 569 The most serious concern in the implementation of any Schnorr type 570 signature scheme is the need to ensure that the value r_(i) is never 571 revealed to any other party and is never used to create signatures 572 for two different values of k.s_(i). 574 Ensuring this does not occur imposes significant design constraints 575 as creating a correct signature contribution requires that the signer 576 use the same value of r_(i) to construct its value or R_(i) and 577 S_(i). 579 For example, a HSM device may be required to perform multiple 580 signature operations simultaneously. Since the storage capabilities 581 of an HSM device are typically constrained, it is tempting to attempt 582 to avoid the need to track the value of r_(i) within the device 583 itself using an appropriately authenticated and encrypted opaque 584 state token. Such mechanisms provide the HSM with the value of r_(i) 585 but do not and cannot provide protection against a replay attack in 586 which the same state token is presented with a request to sign 587 different values of k. 589 3.4.3. Malicious Contribution Attack 591 In a malicious contribution attack, one or more parties present a 592 signature contribution that does not meet the criteria R_(i) = 593 r_(i).B and S_(i) = r_(i) + ks_(i). 595 Such an attack is not considered to be a breach as it merely causes 596 the signature process to fail. 598 3.4.4. Rogue Key Attack 600 A threshold signature scheme that allows the participants to 'bring 601 their own key' may be vulnerable to a rogue key attack in which a 602 signer is able to select the value of the aggregate public signature 603 key by selecting a malicious public signature key value. 605 The scheme described in this document is a threshold signature scheme 606 and does not support this feature. Consequently, this attack is not 607 relevant. It is described here for illustrative purposes only. 609 This particular attack only applies when the individual signers 610 create their own signature shares. It is not a concern when the 611 signature shares are created by splitting a master signature private 612 key. 614 Consider the case where the aggregate public key signature is 615 calculated from the sum of public signature key share values 616 presented by the signers: 618 A = A_(1) + A_(2) + ... + A_(n) 620 If the public key values are presented in turn, the last signer 621 presenting their key share can force the selection of any value of A 622 that they choose by selecting A_(n) = A_(m) - (A_(1) + A_(2) + ... + 623 A_(n-1)) 625 The attacker can thus gain control of the aggregate signature key by 626 choosing A_(m) = s_(m).B where s_(m) is a secret scalar known only to 627 the attacker. But does so at the cost of not knowing the value s_(n) 628 and so the signer cannot participate in the signature protocol. 630 This attack allows the attacker and the attacker alone to create 631 signatures which are validated under the aggregate signature key. 633 The attack is a consequence of the mistaken assumption that a 634 signature created under the signature key A_(1) + A_(2) + ... + A_(n) 635 provides evidence of the individual participation of the 636 corresponding key holders without separate validation of the 637 aggregate key. 639 Enabling the use of threshold signature techniques by ad-hoc groups 640 of signers using their existing signature keys as signature key 641 shares presents serious technical challenges that are outside the 642 scope of this specification. 644 4. Ed2519 Signature 646 The means by which threshold shares are created is described in 647 [draft-hallambaker-threshold]. 649 The dealer selects the signers who are to construct the signature. 650 Each signer then computes the value R_(i): 652 0. Randomly generate an integer r_(i) such that 1 r_(i) L. 654 1. Compute the point R_(i) = r_(i)B. For efficiency, do this by 655 first reducing r_(i) modulo L, the group order of B. Let the 656 string R_(i) be the encoding of this point. 658 2. Transmit the value R_(i) to the dealer 660 3. At some later point, the dealer MAY complete the signature by 661 returning the values F, C, A and R as specified in [RFC8032] 662 together with the key multiplier coefficient c_(i). The signers 663 MAY then complete their signature contributions: 665 4. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 666 64-octet digest as a little-endian integer k. 668 5. Compute S_(i) = (r_(i) + kc_(i)s_(i)) mod L. For efficiency, 669 again reduce k modulo L first. 671 6. Return the values R_(i), S_(i) to the dealer . 673 The dealer then completes the signature by: 675 0. Computing the composite value S = S_(1) + S_(2) + ... + S_(n) 677 1. Verifying that the signature R, S is valid. 679 2. Publishing the signature. 681 5. Ed448 Signature 683 The means by which threshold shares are created is described in 684 [draft-hallambaker-threshold]. 686 The dealer selects the signers who are to construct the signature. 687 Each signer then computes the value R_(i): 689 0. Randomly generate an integer r_(i) such that 1 r_(i) L. 691 1. Compute the point R_(i) = r_(i)B. For efficiency, do this by 692 first reducing r_(i) modulo L, the group order of B. Let the 693 string R_(i) be the encoding of this point. 695 Transmit the value R_(i) to the dealer 697 0. At some later point, the dealer MAY complete the signature by 698 returning the values F, C, A and R as specified in [RFC8032] 699 together with the key multiplier coefficient c_(i). The signers 700 MAY then complete the signature contributions: 702 1. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and 703 interpret the 114-octet digest as a little-endian integer k. 705 2. Compute S_(i) = (r_(i) + kc_(i)s_(i)) mod L. For efficiency, 706 again reduce k modulo L first. 708 3. Return the values R_(i), S_(i) to the dealer. 710 The dealer then completes the signature by: 712 0. Computing the composite value S = S_(1) + S_(2) + ... + S_(n) 714 1. Verifying that the signature R, S is valid. 716 2. Publishing the signature. 718 6. Test Vectors 720 6.1. Direct Threshold Signature Ed25519 722 The signers are Alice and Bob's Threshold Signature Service 'Bob'. 723 Each creates a key pair: 725 ED25519Alice's Key (ED25519) 726 UDF: ZAAA-GTSI-GXED-255X-XALI-CEXS-XKEY 727 Scalar: 312191303806394376947696888962276115420485359001 728 34467943432016761653342335248 729 Encoded Private 730 10 AE C0 C2 16 65 9B 4F 7C 9D DE 82 3E 49 7F D4 731 9B 14 BB F8 2D 9F 0C 11 24 D7 15 E3 43 79 57 20 732 X: -13697699435406080999251131063344049965140553452 733 752305353714819106646919347160064793506327635954342719144289 734 2305566686088586980395284289746495530409889930 735 Y: 278793875610616080844162800185864399625503938157 736 569374174700414845758479331294424147393776831767266487579098 737 7675375777043504113387553916769515911310193558 738 Encoded Public 739 45 16 53 7C 26 50 CF DA F1 A4 DF 4C 45 DC 3D 95 740 4E B6 8E EB A6 5A 27 D6 CD 5B 43 C5 F4 06 53 ED 741 ED25519Bob's Key (ED25519) 742 UDF: ZAAA-GTSI-G2ED-255X-XBOB-XSXK-EY 743 Scalar: 567212843891509414800308620158891720685508995620 744 72140666211075925337851277632 745 Encoded Private 746 E5 CD 34 01 FD 8C 0E 27 81 4B 11 DD 12 68 50 A1 747 4B 5A D5 E1 E1 41 D7 68 5F 51 ED B4 3A 84 58 5C 748 X: -13809282472298084436735987888897423507149580966 749 952791761446670884044433963975178482398144657564565223270588 750 5322459642470946347570575475534141406285323257 751 Y: 263684226342871984706317411760423095947068088366 752 393546798602378437432707482089806653755881399592963068751759 753 9645362525866308283171284327931970404321458677 754 Encoded Public 755 F1 5F C0 78 F8 32 49 2C D9 64 CC 2B CF 90 5C 4F 756 23 EA BB F8 38 99 C5 FE F3 AA 67 BE AB EC D2 5E 758 The composite Signature Key A = A_(a) + A_(b) 759 Aggregate Key = Alice + Bob () 760 UDF: TBS 761 Scalar: 109634784180323260712231215560085272031403914964 762 7717337619681427565742601012 763 Encoded Private 764 34 33 AB 10 9A 09 A9 61 65 8B 3A EC 58 21 FB 2D 765 0D 45 74 49 45 BA E2 CF A8 98 C2 94 C9 82 6C 02 766 X: -83837675294300852842901121613445594296352372347 767 711317409367737761568353629718805151940195325485285476438422 768 923698718220652243749390297055882388709313280 769 Y: 160553422944358144751060009820735322036903773802 770 361117046457476895165059738086663330972263850675453249990301 771 0398473811263196653225446124160025082144761534 772 Encoded Public 773 48 1A 27 66 06 AF 4E 3C 20 A4 02 CD 8A 13 46 99 774 02 B7 75 F8 AC D4 7E 89 68 FB 68 EB D8 EF 4A C7 776 To sign the text "This is a test", Alice first generates her value r 777 and multiplies it by the base point to obtain the value R_(a): 779 Alice: 780 r_a: 505210734621497595393270784745614175113191664157 781 4177425600105798482114377785 782 R_a = 783 DF A3 D5 CC 9F 94 63 67 BB 3E C3 F7 88 4A 0D 52 784 00 20 A2 90 13 27 4E 47 03 19 DA EC BF 74 CB 14 786 Alice passes her value R_(A) to Bob along with the other parameters 787 required to calculate i. Bob then calculates his value R_(A) and 788 multiplies it by the base point to obtain the value R_(b): 790 Bob: 791 r_b: 677880217486034074720202546367410174561950677574 792 5309900070354323071886227867 793 R_b = 794 DD C8 79 2A BB D8 72 D5 9D F5 13 22 C2 F1 58 62 795 47 DC 19 39 C5 CE 02 FB 24 0B FA 64 D1 55 BC 3E 797 Bob can now calculate the composite value R = R_(a) + R_(b) and thus 798 the value k. 800 R = 801 5A D0 1C 17 95 ED 9B 99 B8 CD CE 7B EE 47 6E A5 802 0E A6 CF 51 DE DA 89 CB B5 F4 4C E2 D5 0D 58 FA 803 k: 625005044347993004605907480401547053627770740065 804 2040602450571600703428702758 806 Bob calculates his signature scalar contribution and returns the 807 value to Alice: 809 Bob: 810 S_b: 136373130884201209719904273113512997386754201427 811 8737070757184293024413450866 813 Alice can now calculate her signature scalar contribution and thus 814 the signature scalar S. 816 Alice: 817 S_a: 694422500722053719583170959521207108671468233956 818 3089821393557557357031271837 819 S: 107095073873028707905756576330420681972510799446 820 1919286148790912095990471714 822 Alice checks to see that the signature verifies: 824 S.B = R + kA = 825 X: 499652471325922372829034886924764341503336793855 826 86215130071277671241180454624 827 Y: 465061436809499600324596437786395684290405421559 828 11499262135862928788499885458 830 6.2. Direct Threshold Signature Ed448 832 The signers are Alice and Bob's Threshold Signature Service 'Bob'. 833 Each creates a key pair: 835 ED448Alice's Key (ED448) 836 UDF: ZAAA-ITSI-GXED-44XA-LICE-XSXK-EY 837 Scalar: 672286477331130983513039743350616227864346753924 838 962787860729757222511999618443513569403793186398096717924945 839 854846544396984088344823264 840 Encoded Private 841 6F 85 B1 91 9A 37 06 A6 B2 15 79 AD 5B 69 16 6A 842 5A CD C8 17 D4 14 1F 68 DA 97 C5 B4 44 79 CE EA 843 3C 17 7B E1 29 44 70 DF 41 C8 98 38 1E 7C 9B 3B 844 03 63 6F 85 E8 39 31 91 845 X: 526046019655043632868470952286947529492283092344 846 122476077151423645243648974512182548405702873560533846673262 847 767064019365470830861106049 848 Y: 145374550785380850812934424757986866673485237047 849 938554544492694946608060986459495807055455048208713991919477 850 720250115717234689256856152 851 Encoded Public 852 59 55 F4 7A 66 08 91 35 F8 15 63 F4 90 91 7F 38 853 12 E3 49 22 51 F8 BC 4A 41 C9 44 59 5A 64 9B 40 854 0B C5 7E 53 48 0F 32 12 90 32 69 38 47 28 94 BB 855 99 D1 16 6F 2D D5 3D 4F 80 856 ED448Bob's Key (ED448) 857 UDF: ZAAA-ITSI-G2ED-44XB-OBXS-XKEY 858 Scalar: 455052626698262385397736547727159423941520792904 859 908612603542850909167215987713902322619933929404455741806848 860 064294945283113799683261212 861 Encoded Private 862 CA 15 22 BD F4 0F 9E 0A EC A7 61 79 BE 9E E3 38 863 BF 93 D3 5B B3 E6 FC F0 A7 5B 7C F0 E7 B5 89 F6 864 2E F6 D1 0E 72 49 4D DF 34 5E 2F 7C 9E 42 1D 85 865 AB AB 30 BD 68 C6 3E 35 866 X: 752024108200272710832187535557164455078689734595 867 171189993383259892607253027500878543439908750525763880661232 868 171322059854852522782265 869 Y: 619329873102159676791326142073166790594683111409 870 729383584199833441028484525583699421181422168190856074786324 871 020492214873796495570056511 872 Encoded Public 873 76 2B FC F8 AC 96 79 DE 1C 72 07 65 DD 49 5B 28 874 C7 04 CB A8 A5 96 3D D9 9E 23 FA 05 83 15 33 95 875 85 82 F8 CF A3 7A 2F 24 F8 EB D6 AE 20 0A 25 D0 876 44 1A F9 C0 86 D7 87 B7 00 878 The composite Signature Key A = A_(a) + A_(b) 879 Aggregate Key = Alice + Bob () 880 UDF: TBS 881 Scalar: 370810175859830330867905792457688502754055057988 882 943100420373093608031918369199015948491953656482966798700316 883 64591515851455352870185802 884 Encoded Private 885 4A AB 7A BB 2D 95 72 75 B1 3A 1D 22 24 17 76 2D 886 A1 D5 55 94 67 35 8C E7 A1 A0 ED 0C E7 88 FF 9F 887 6E 2F 70 80 89 F5 01 2A C0 AD 4C 4E 7B 90 68 6C 888 F4 53 BA 32 9B 70 0F 0D 889 X: 583249553407699999284154112964835446252412293188 890 857058051552519639906663406776316984154017062023869075790536 891 30514579317017660114474427 892 Y: 518040437562811181169413740718290938351269168888 893 257124107164689245721852001077758864406412789756149699111633 894 051823234569886260996269341 895 Encoded Public 896 34 70 8D 08 DE 63 0B A6 49 2A 33 D8 B7 15 A9 84 897 A4 87 F6 B6 C7 4B 1C AE 5A 1F 7C 4B 12 70 FB CF 898 5A A9 3C 20 31 BA 9A 53 A0 FE 2A 43 24 97 06 F8 899 DA 40 0D 88 E3 D9 DE 2E 00 901 To sign the text "This is a test", Alice first generates her value r 902 and multiplies it by the base point to obtain the value R_(a): 904 Alice: 905 r_a: 154801816267240464546834446515456406651845314401 906 002977264905693500446669857879911189090126903643060098695902 907 159902668465952043665201729 908 R_a = 909 BF 60 68 8C 92 23 91 A7 92 65 D7 A9 3A 11 B6 25 910 91 CC 72 0D 83 F7 80 06 4C 7F 7B FA F5 60 CF FC 911 43 DA 5E 9F 71 09 6C 51 6E 28 E7 8D 50 2D 7A 4A 912 1F 00 17 FF 18 F5 65 F0 00 914 Alice passes her value R_(A) to Bob along with the other parameters 915 required to calculate i. Bob then calculates his value R_(A) and 916 multiplies it by the base point to obtain the value R_(b): 918 Bob: 919 r_b: 151741242222551333693536358753113477279079323953 920 405968709541531009609312639878485678278493044984250865569658 921 971735381320787025215934551 922 R_b = 923 E2 20 7A 34 5E E2 BE B0 EE DC 3D 7E 98 AB 00 5B 924 7E B5 4A 6D 9D 6B AE 00 C3 61 3C 0E BF 85 44 84 925 2D C2 46 BD 6A EB CF 60 52 A6 22 7F 3E 6D 52 D7 926 1B B5 A8 FB A2 6E D9 19 00 928 Bob can now calculate the composite value R = R_(a) + R_(b) and thus 929 the value k. 931 R = 932 7D E7 D1 AC 39 91 2D A1 64 82 A2 12 11 FD 48 2A 933 E4 C1 69 4F F1 DB 8C F4 B0 41 44 DB 81 9A 99 93 934 28 80 BD FC 4E 30 9A 0D 24 7C 2E 97 36 EB DA E9 935 78 83 08 B9 A5 1A 9F AF 80 936 k: 152478129684675943479409248843466240733035903267 937 926235089418642613018543821412858874657453613785631671228639 938 879208851203344161958472626 940 Bob calculates his signature scalar contribution and returns the 941 value to Alice: 943 Bob: 944 S_b: 483080257179106760967096112599711672595306939349 945 964976636926846127260138522913206826943834871540343367464674 946 04823679970210640505379249 948 Alice can now calculate her signature scalar contribution and thus 949 the signature scalar S. 951 Alice: 952 S_a: 929765386089729500539533802678644970120766195521 953 592545136047824546064521300569760854876125225246919399958779 954 43127262307963446226438525 955 S: 141284564326883626150662991527835664271607313487 956 155752177297467067332465982348296768181996009678726276742345 957 347950942278174086731817774 959 Alice checks to see that the signature verifies: 961 S.B = R + kA = 962 X: 438553256512884225923994157378894696848243269381 963 58786710000478625591080896686 964 Y: 100086885282402628787474925500974806696629978712 965 71442659795857672094353438094 967 6.3. Shamir Threshold Signature Ed25519 969 The administrator creates the composite key pair 970 ED25519Aggregate Key (ED25519) 971 UDF: ZAAA-GTSI-GQED-255X-XAGG-REGA-TEXK-EY 972 Scalar: 367238470592488326468789252109412889361910680229 973 03089760692844779165588879504 974 Encoded Private 975 FE 48 94 1F EB 3D 28 E1 61 81 E2 1E E1 CF F2 1E 976 1E 70 91 30 DF 98 9F 1C 34 EB BB 74 C5 C8 07 EB 977 X: 143576564277195758046684172284175869008525477709 978 640743490221115123376609940386394888392330104965579307772627 979 313244177612005636942740116142030215202393600 980 Y: 844838272625277895849027219595751726665225134917 981 547580682441821283235675507225396641352769322822815561632929 982 543097074319051436285787045255908364074589900 983 Encoded Public 984 DF E8 0A 2B E9 6C 53 C0 AB 9B BC BC 39 95 9A 61 985 9C 33 2E 22 24 A7 F7 F2 21 06 AC 6D 01 5D 0B E2 987 Three key shares are required for Alice, Bob and Carol with a 988 threshold of two. The parameters of the Shamir Secret Sharing 989 polynomial are: 991 a0 = 367238470592488326468789252109412889361910680229030897606928 992 44779165588879504 993 a1 = 699266283035359788689002485914571600271382111380710376847895 994 2287632180176739 996 The key share values for the participants are 998 xa = 1 999 ya = 294476425608857249929830691829039493762190980430747893160091 1000 437085043550309 1002 xb = 2 1003 yb = 501336786301929228466689879317612556188957348579440556370927 1004 86431769476059 1006 xc = 3 1007 yc = 704279650898379080973669384707747725833271684866504782411604 1008 5074063949652798 1010 Alice and Carol are selected to sign the message "This is another 1011 test" 1013 The Lagrange coefficients are: 1015 la = 361850278866613110698659328152149712042855817968995380300097 1016 5469142727125496 1017 lc = 361850278866613110698659328152149712042855817968995380300097 1018 5469142727125494 1020 Alice and Carol select their values ra, rc 1022 ra = 456116926701492705315133938623040527696276882295617965847376 1023 7682545245216294 1024 Ra = 1025 D4 45 96 7B EC 72 EF EB CE 64 45 4B F1 04 BE 89 1026 82 76 38 A9 C7 CD 49 D5 AC 89 89 15 A1 2C F9 ED 1028 rc = 482074679100753533345731495679776832764315286485235535312553 1029 5253541881347149 1030 Rc = 1031 84 2F BA 3B E3 BB 6B FD 1E A7 4A 9A F7 69 CB F2 1032 42 E0 40 37 72 CB 44 76 91 F3 78 4C 38 6A 55 70 1034 The composite value R = R_(a) + R_(c) 1036 R = 1037 86 D3 74 FB 11 A5 B0 02 0E C8 D8 47 81 F6 D3 0B 1038 2F 98 1A 78 A4 B6 29 8E CF 8F 1F BA C6 DF 9C CE 1040 The value k is 1042 k = 108571726585613745870710472121182543905966072176325240119429 1043 6512368686397102 1045 The values R and k (or the document to be signed) and the Lagrange 1046 coefficients are passed to Alice and Carol who use them to calculate 1047 their secret scalar values: 1049 sa = 406021742707941698188133931926505636107184465033607564274111 1050 2624770292450958 1051 sc = 371560732284036680910483963950425561169075793504738369394392 1052 8401253479424590 1054 The signature contributions can now be calulated: 1056 Sa = 392895418968963203512266836046291402317818369828942689298477 1057 2946200577969243 1058 Sc = 253752237332419145649601433321208219235347953185395225369356 1059 1893073151349028 1061 The dealer calculates the composite value S = S_(a) + S_(b) 1062 S = 646647656301382349161868269367499621553166323014337914667833 1063 4839273729318271 1065 The dealer checks to see that the signature verifies: 1067 S.B = R + kA = 1068 X: 226427714657102020025604838380148290637031902023 1069 61838906492538114789522304796 1070 X: 106130935431547011586457110809164124211743921447 1071 29537260912052744073378658652 1073 6.4. Shamir Threshold Signature Ed448 1075 The administrator creates the composite key pair 1077 ED448Aggregate Key (ED448) 1078 UDF: ZAAA-ITSI-GQED-44XA-GGRE-GATE-XKEY 1079 Scalar: 723088510822916843359337925516642493307623385482 1080 113107480846498794254549074097051759295396782499503452909258 1081 978468506553055366989547456 1082 Encoded Private 1083 59 DC 8A 5F 5E AF 8C FA 96 19 F8 EE 78 13 00 12 1084 33 0E 12 80 2D 25 E6 EF E8 E2 56 B5 83 6A 0C CF 1085 DC 11 96 A5 A5 D1 39 AA 34 25 0B 52 ED 9F 38 92 1086 5D 9F 7B BC B9 BC 86 45 1087 X: 600163199260212879671026282440221570752543874569 1088 276531213297382365938924845597497264583528185273760383031589 1089 25167107013312482098672476 1090 Y: 568007995844826855892481230051783440873263817862 1091 016100095069663100696528804467952219402043387612562057320585 1092 561865068046226655443122582 1093 Encoded Public 1094 ED C3 90 99 38 0B 8F CD 60 29 24 04 6C DE 52 33 1095 A2 07 3E 56 8D 27 B5 B9 21 60 CF E9 E7 9D D6 4A 1096 11 47 20 E6 9D FE 75 C7 04 14 70 18 B4 52 10 83 1097 D0 EC 98 BD F5 E6 E3 D5 80 1099 Three key shares are required for Alice, Bob and Carol with a 1100 threshold of two. The parameters of the Shamir Secret Sharing 1101 polynomial are: 1103 a0 = 723088510822916843359337925516642493307623385482113107480846 1104 49879425454907409705175929539678249950345290925897846850 1105 6553055366989547456 1106 a1 = 165663618071837435927824367225611232537435726800694979220111 1107 02522386453540608200774410212968582148967992226507570036 1108 4540659700713156444 1110 The key share values for the participants are 1112 xa = 1 1113 ya = 161913404599147388737838484854249191491417751595490026419467 1114 32483753506863402071663861450530155148927959034921780222 1115 1874620044264104784 1117 xb = 2 1118 yb = 145867341597083102028331900107859290440443138224355490569205 1119 80026625360007856313866652087969568060299620232058441092 1120 4110505989117611449 1122 xc = 3 1123 yc = 129821278595018815318825315361469389389468524853220954718944 1124 27569497213152310556069442725408980971671281429195101962 1125 6346391933971118114 1127 Alice and Carol are selected to sign the message "This is another 1128 test" 1130 The Lagrange coefficients are: 1132 la = 908548405369508613186654759860005667942051700859147575351862 1133 74897573001980769792858097877645846187981655146854545831 1134 152386877929824891 1135 lc = 908548405369508613186654759860005667942051700859147575351862 1136 74897573001980769792858097877645846187981655146854545831 1137 152386877929824889 1139 Alice and Carol select their values ra, rc 1141 ra = 103517366944050550717591081348710241163469949228538856371118 1142 47833970060549248948499739275675447160833072419041041347 1143 1187333803802632789 1144 Ra = 1145 86 8B B6 BF E1 FA 18 BB 5A D6 79 D2 6F 60 E9 7A 1146 B9 76 58 AA 96 3B 5E FD 83 E7 79 09 53 A2 AE 7B 1147 89 C6 30 72 31 13 C3 97 9D 0C 75 BB F2 DC 87 72 1148 46 CD F8 BF 6F 08 27 FF 00 1150 rc = 129544664690317775866810455605532383977152960638027121327286 1151 30462413505947371161103544570926395906833875655978561651 1152 9513959988103594270 1153 Rc = 1154 D6 0E 7A 4B C1 D1 A4 A4 09 A9 4E 2C 0C 11 E8 31 1155 E3 F7 0D C0 AD 7E 90 6D 53 63 6B D0 D0 5D 5F BD 1156 44 34 4F B9 1D 5C 05 7B A8 52 5D 39 00 8B 47 30 1157 46 15 B7 39 00 35 A6 8D 00 1159 The composite value R = R_(a) + R_(c) 1161 R = 1162 84 76 AE 71 96 E4 5B 2C 32 7A CE 8C 62 4E C5 C7 1163 56 90 58 7B 46 C1 99 87 95 72 E0 39 14 59 50 3A 1164 53 63 60 8A 2B 14 DD C2 99 AF 57 5D 7F 28 6C DC 1165 73 4E 72 6A 0A 67 B9 F0 80 1167 The value k is 1169 k = 846715492312861675786877637427593731664460324443667916137724 1170 03306404008461876775118415847980023413626823976377915241 1171 076018146143898434 1173 The values R and k (or the document to be signed) and the Lagrange 1174 coefficients are passed to Alice and Carol who use them to calculate 1175 their secret scalar values: 1177 sa = 611604258248193604694267753093726536487162872214055245588284 1178 37461156598989491489241726002660634857956075230117611670 1179 507156310536507397 1180 sc = 116799041776392314977918294291266438893676077745219037710900 1181 41194765993819998680536898212824678751760690314773358184 1182 9131577788874090722 1184 The signature contributions can now be calulated: 1186 Sa = 674398491172392582315391447961842592916627666141711533732986 1187 40302585673169645319736684479821824290746431281389532198 1188 884328704969312923 1189 Sc = 323501021094800816208302172187722789450985391108790119316146 1190 83012739259001534721728765613699056985895227578447593375 1191 275645256932691561 1193 The dealer calculates the composite value S = S_(a) + S_(b) 1195 S = 997899512267193398523693620149565382367613057250501653049133 1196 23315324932171180041465450093520881276641658859837125574 1197 159973961902004484 1199 The dealer checks to see that the signature verifies: 1201 S.B = R + kA = 1202 X: 310176585478125150718252258963045651393161473743 1203 3144189417665237106104024598 1204 X: 546975372341826393522134872750971962955374107574 1205 98782836263975525610781195547 1207 7. Security Considerations 1209 All the security considerations of [RFC7748], [RFC8032] and 1210 [draft-hallambaker-threshold] apply and are hereby incorporated by 1211 reference. 1213 7.1. Rogue Key attack 1215 The rogue key attack described in [draft-hallambaker-threshold] is of 1216 particular concern to generation of threshold signatures. 1218 If _A_ and _B_ are public keys, the intrinsic degree of trust in the 1219 composite keypair _A_ + _B_ is that of the lesser of _A_ and _B_. 1221 7.2. Disclosure or reuse of the value r 1223 As in any Schnorr signature scheme, compromise of the value _r_ 1224 results in compromise of the private key. The base signature 1225 specification [RFC8032] describes a deterministic construction of _r_ 1226 that ensures confidentiality and uniqueness for a given value of _k_. 1228 As described above, this approach is not applicable to the generation 1229 of values of _r_(i)_ to compute threshold signature contributions. 1230 Accordingly the requirements of [RFC4086] regarding requirements for 1231 randomness MUST be observed. 1233 Implementations MUST NOT use a deterministic generation of the value 1234 _r_(i)_ for any threshold contribution except for calculating the 1235 final contribution when all the other parameters required to 1236 calculate _k_ are known. 1238 7.3. Resource exhaustion attack 1240 Implementation of the general two stage signing algorithm requires 1241 that signers track generation and use of the values _r_(i)_ to avoid 1242 reuse for different values of _R_(i)_. Implementations MUST ensure 1243 that exhaustion of this resource by one party does not cause other 1244 parties to be denied service. 1246 7.4. Signature Uniqueness 1248 Signatures generated in strict conformance with [RFC8032] are 1249 guaranteed to be unique such that signing the same document with the 1250 same key will always result in the same signature value. 1252 The signature modes described in this document are computationally 1253 indistinguishable from those created in accordance with [RFC8032] but 1254 are not unique. 1256 Implementations MUST not use threshold signatures in applications 1257 where signature values are used in place of cryptographic digests as 1258 unique content identifiers. 1260 8. IANA Considerations 1262 This document requires no IANA actions. 1264 9. Acknowledgements 1266 [TBS] 1268 10. Normative References 1270 [draft-hallambaker-mesh-udf] 1271 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 1272 Data Fingerprint.", Work in Progress, Internet-Draft, 1273 draft-hallambaker-mesh-udf-11, 2 November 2020, 1274 . 1277 [draft-hallambaker-threshold] 1278 Hallam-Baker, P., "Threshold Modes in Elliptic Curves", 1279 Work in Progress, Internet-Draft, draft-hallambaker- 1280 threshold-04, 2 November 2020, 1281 . 1284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1285 Requirement Levels", BCP 14, RFC 2119, 1286 DOI 10.17487/RFC2119, March 1997, 1287 . 1289 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1290 "Randomness Requirements for Security", BCP 106, RFC 4086, 1291 DOI 10.17487/RFC4086, June 2005, 1292 . 1294 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1295 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1296 2016, . 1298 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1299 Signature Algorithm (EdDSA)", RFC 8032, 1300 DOI 10.17487/RFC8032, January 2017, 1301 . 1303 11. Informative References 1305 [draft-hallambaker-mesh-developer] 1306 Hallam-Baker, P., "Mathematical Mesh: Reference 1307 Implementation", Work in Progress, Internet-Draft, draft- 1308 hallambaker-mesh-developer-10, 27 July 2020, 1309 . 1312 [Komlo] Komlo, C. and I. Goldberg, "FROST: Flexible Round- 1313 Optimized Schnorr Threshold Signatures", 2020. 1315 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1316 Operations, Administration, and Maintenance (OAM) in MPLS 1317 Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 1318 2010, . 1320 [Shamir79] Shamir, A., "How to share a secret.", 1979.