InternetDraft  Threshold Signatures in Elliptic Curves  January 2021 
HallamBaker  Expires 17 July 2021  [Page] 
 Workgroup:
 Network Working Group
 InternetDraft:
 drafthallambakerthresholdsigs
 Published:
 Intended Status:
 Informational
 Expires:
Threshold Signatures in Elliptic Curves
Abstract
A Threshold signature scheme is described. The signatures created are computationally indistinguishable from those produced using the Ed25519 and Ed448 curves as specified in RFC8032 except in that they are nondeterministic. Threshold signatures are a form of digital signature whose creation requires two or more parties to interact but does not disclose the number or identities of the parties involved.¶
https://mailarchive.ietf.org/arch/browse/cfrg/Discussion of this draft should take place on the CFRG mailing list (cfrg@irtf.org), which is archived at .¶
Status of This Memo
This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current InternetDrafts is at https://datatracker.ietf.org/drafts/current/.¶
InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as "work in progress."¶
This InternetDraft will expire on 17 July 2021.¶
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
1. Introduction
Threshold encryption and key generation provide compelling advantages over single private key approaches because splitting the private key permits the use of that key to be divided between two or more roles.¶
All existing digital signatures allow the signer role to be divided between multiple parties by attaching multiple signatures to the signed document. This approach, known as multisignatures, is distinguished from a threshold signature scheme in that the identity and roles of the individual signers is exposed. In a threshold signature scheme, the creation of a single signature requires the participation of multiple signers and the signature itself does not reveal the means by which it was constructed.¶
Rather than considering multisignatures or threshold signatures to be inherently superior, it is more useful to regard both as two points on a continuum of choices:¶
 Multisignatures

Multiple digital signatures on the same document. Multisignatures are simple to create and provide the verifier with more information but require the acceptance criteria to be specified independently of the signature itself. This requires that the application logic or PKI provide some means of describing the criteria to be applied.¶
 Multiparty key release

A single signature created using a single private key stored in an encrypted form whose use requires participation of multiple key decryption shares.¶
 Threshold signatures

A single signature created using multiple signature key shares. Signature creation may be subject to complex criteria such as requiring an (n,t) quorum of signers but these criteria are fixed at the time the signature is created¶
 Aggregate Signatures

A single signature created using multiple signature key shares such that validation of the aggregate signature serves to validate the participation of each of the individual signers.¶
This document builds on the approach described in [drafthallambakerthreshold] to define a scheme that creates threshold signatures that are computationally indistinguishable from those produced according to the algorithm specified in [RFC8032]. The scheme does not support the creation of aggregate signatures.¶
The approach used is based on that developed in FROST [Komlo]. This document describes the signature scheme itself. The techniques used to generate keys are described separately in [drafthallambakerthreshold].¶
As in the base document, we first describe signature generation for the case that n = t using 'direct' coefficients, that is the secret scalar is the sum of the secret shares. We then show how the scheme is modified using Shamir secret sharing [Shamir79] and Lagrange coefficients for the case that n > t.¶
1.1. Applications
Threshold signatures have application in any situation where it is desired to have finer grain control of signing operations without this control structure being visible to external applications. It is of particular interest in situations where legacy applications do not support multisignatures.¶
1.1.1. HSM Binding
Hardware Security Modules (HSMs) prevent accidental disclosures of signature keys by binding private keys to a hardware device from which it cannot be extracted without substantial effort. This provides effective mitigation of the chief causes of key disclosure but requires the signer to rely on the trustworthiness of a device that represents a black box they have no means of auditing.¶
Threshold signatures allow the signer to take advantage of the key binding control provided by an HSM without trusting it. The HSM only contributes one of the key shares used to create the signature. The other is provided by the application code (or possibly an additional HSM).¶
1.1.2. Code Signing
Code signing is an important security control used to enable rapid detection of malware by demonstrating the source of authorized code distributions but places a critical reliance on the security of the signer's private key. Inadvertent disclosure of code signing keys is commonplace as they are typically stored in a form that allows them to be used in automatic build processes. Popular source code repositories are regularly scanned by attackers seeking to discover private signature keys and passwords embedded in scripts.¶
Threshold signatures allow the code signing operation to be divided between a developer key and an HSM held locally or by a signature service. The threshold shares required to create the signature can be mapped onto the process roles and personnel responsible for authorizing code release. This last concern might be of particular advantage in open source projects where the concentration of control embodied in a single code signing key has proved to be difficult to reconcile with community principles.¶
1.1.3. Signing by Redundant Services
Redundancy is as desirable for trusted services as for any other service. But in the case that multiple hosts are tasked with compiling a data set and signing the result, there is a risk of different hosts obtaining a different view of the data set due to timing or other concerns. This presents the risk of the hosts signing inconsistent views of the data set.¶
Use of threshold signatures allows the criteria for agreeing on the data set to be signed to be mapped directly onto the requirement for creating a signature. So if there are three hosts and two must agree to create a signature, three signature shares are created and with a threshold of two.¶
2. Definitions
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
2.4. Implementation Status
The implementation status of the reference code base is described in the companion document [drafthallambakermeshdeveloper].¶
3. Principles
The threshold signatures created according to the algorithms described in this document are compatible with but not identical to the signatures created according to the scheme described in [RFC8032]. In particular:¶
 The signature verification algorithm is unchanged.¶
 The unanimous threshold scheme produces values of R and S that are deterministic but different from the values that would be obtained by using the aggregate private key to sign the same document.¶
 The deterministic quorate threshold scheme produces values of R and S that are deterministic for a given set of signers but will change for a different set of signers or if the aggregate private key was used to sign the same document.¶
 ?The nondeterministic quorate threshold scheme produces values of R and S that will be different each time the document is signed.¶
Recall that a digital signature as specified by [RFC8032] consists of a pair of values S, R calculated as follows:¶
R = r.B¶
S = r + k.s mod L¶
 Where

B is the base point of the elliptic curve.¶
r is an unique, unpredictable integer value such that 0 r L¶
k is the result of applying a message digest function determined by the curve (Ed25519, Ed448) to a set of parameters known to the verifier which include the values R, A and PH(M).¶
A is the public key of the signer, A = s.B¶
PH(M) is the prehash function of the message value.¶
s is the secret scalar value¶
L is the order of the elliptic curve group.¶
To verify the signature, the verifier checks that:¶
S.B = R + k.A¶
This equality must hold for a valid signature since:¶
The value r plays a critical role in the signature scheme as it serves to prevent disclosure of the secret scalar. If the value r is known, s can be calculated as s = (Sr).k^{1} mod L. It is therefore essential that the value r be unguessable.¶
Furthermore, if the same value of r is used to sign two different documents, this results two signatures with the same value R and different values of k and S. Thus¶
S_{1} = r + k_{1}.s mod L¶
S_{2} = r + k_{2}.s mod L¶
s = (S_{1}  S_{2})(k_{1}  k_{2})^{1} mod L¶
The method of constructing r MUST ensure that it is unique and unguessable.¶
3.4. Security Analysis
We consider a successful breach of the threshold signature scheme to be any attack that allows the attacker to create a valid signature for any message without the participation of the required threshold of signers.¶
Potential breaches include:¶
 Disclosure of the signature key or signature key share.¶
 Modification of signature data relating to message M to allow creation of a signature for message M'.¶
 Ability of one of the signers to choose the value of the aggregate public key.¶
 Access control attacks inducing a signer to create a signature contribution that was not properly authenticated or authorized.¶
We regard attacks on the access control channel to be out of scope for the threshold signature algorithm, though they are certainly a concern for any system in which a threshold signature algorithm is employed.¶
We do not consider the ability of a signer to cause creation of an invalid signature to represent a breach.¶
3.4.1. Calculation of r values
The method of constructing the values r_{i} MUST ensure that each is unique and unguessable both to external parties, the signers and the dealer. The deterministic method specified in [RFC8032] cannot be applied to generation of the values r_{i} as it allows the dealer to cause signers to reveal their key shares by requesting multiple signature contributions for the same message but with different values of k. In particular, requesting signature contributions for the same message:¶
With different Lagrange coefficients.¶
With a false value of R¶
To avoid these attacks, the value r_{i} is generated using a secure random number generator. This approach requires the signer to ensure that values are never reused requiring that the signing API maintain state between the first and second rounds of the algorithm.¶
While there are many approaches to deterministic generation of r_{i} that appear to be sound, closer inspection has demonstrated these to be vulnerable to rogue key and rogue contribution attacks.¶
3.4.2. Replay Attack
The most serious concern in the implementation of any Schnorr type signature scheme is the need to ensure that the value r_{i} is never revealed to any other party and is never used to create signatures for two different values of k.s_{i}.¶
Ensuring this does not occur imposes significant design constraints as creating a correct signature contribution requires that the signer use the same value of r_{i} to construct its value or R_{i} and S_{i}.¶
For example, a HSM device may be required to perform multiple signature operations simultaneously. Since the storage capabilities of an HSM device are typically constrained, it is tempting to attempt to avoid the need to track the value of r_{i} within the device itself using an appropriately authenticated and encrypted opaque state token. Such mechanisms provide the HSM with the value of r_{i} but do not and cannot provide protection against a replay attack in which the same state token is presented with a request to sign different values of k.¶
3.4.3. Malicious Contribution Attack
In a malicious contribution attack, one or more parties present a signature contribution that does not meet the criteria R_{i} = r_{i}.B and S_{i} = r_{i} + ks_{i}.¶
Such an attack is not considered to be a breach as it merely causes the signature process to fail.¶
3.4.4. Rogue Key Attack
A threshold signature scheme that allows the participants to 'bring their own key' may be vulnerable to a rogue key attack in which a signer is able to select the value of the aggregate public signature key by selecting a malicious public signature key value.¶
The scheme described in this document is a threshold signature scheme and does not support this feature. Consequently, this attack is not relevant. It is described here for illustrative purposes only.¶
This particular attack only applies when the individual signers create their own signature shares. It is not a concern when the signature shares are created by splitting a master signature private key.¶
Consider the case where the aggregate public key signature is calculated from the sum of public signature key share values presented by the signers:¶
A = A_{1} + A_{2} + ... + A_{n}¶
If the public key values are presented in turn, the last signer presenting their key share can force the selection of any value of A that they choose by selecting A_{n} = A_{m}  (A_{1} + A_{2} + ... + A_{n1})¶
The attacker can thus gain control of the aggregate signature key by choosing A_{m} = s_{m}.B where s_{m} is a secret scalar known only to the attacker. But does so at the cost of not knowing the value s_{n} and so the signer cannot participate in the signature protocol.¶
This attack allows the attacker and the attacker alone to create signatures which are validated under the aggregate signature key.¶
The attack is a consequence of the mistaken assumption that a signature created under the signature key A_{1} + A_{2} + ... + A_{n} provides evidence of the individual participation of the corresponding key holders without separate validation of the aggregate key.¶
Enabling the use of threshold signature techniques by adhoc groups of signers using their existing signature keys as signature key shares presents serious technical challenges that are outside the scope of this specification.¶
4. Ed2519 Signature
The means by which threshold shares are created is described in [drafthallambakerthreshold].¶
The dealer selects the signers who are to construct the signature. Each signer then computes the value R_{i}:¶
 Randomly generate an integer r_{i} such that 1 r_{i} L.¶
 Compute the point R_{i} = r_{i}B. For efficiency, do this by first reducing r_{i} modulo L, the group order of B. Let the string R_{i} be the encoding of this point.¶
 Transmit the value R_{i} to the dealer¶
 At some later point, the dealer MAY complete the signature by returning the values F, C, A and R as specified in [RFC8032] together with the key multiplier coefficient c_{i}. The signers MAY then complete their signature contributions:¶
 Compute SHA512(dom2(F, C)  R  A  PH(M)), and interpret the 64octet digest as a littleendian integer k.¶
 Compute S_{i} = (r_{i} + kc_{i}s_{i}) mod L. For efficiency, again reduce k modulo L first.¶
 Return the values R_{i}, S_{i} to the dealer .¶
The dealer then completes the signature by:¶
5. Ed448 Signature
The means by which threshold shares are created is described in [drafthallambakerthreshold].¶
The dealer selects the signers who are to construct the signature. Each signer then computes the value R_{i}:¶
 Randomly generate an integer r_{i} such that 1 r_{i} L.¶
 Compute the point R_{i} = r_{i}B. For efficiency, do this by first reducing r_{i} modulo L, the group order of B. Let the string R_{i} be the encoding of this point.¶
Transmit the value R_{i} to the dealer¶
 At some later point, the dealer MAY complete the signature by returning the values F, C, A and R as specified in [RFC8032] together with the key multiplier coefficient c_{i}. The signers MAY then complete the signature contributions:¶
 Compute SHAKE256(dom4(F, C)  R  A  PH(M), 114), and interpret the 114octet digest as a littleendian integer k.¶
 Compute S_{i} = (r_{i} + kc_{i}s_{i}) mod L. For efficiency, again reduce k modulo L first.¶
 Return the values R_{i}, S_{i} to the dealer.¶
The dealer then completes the signature by:¶
6. Test Vectors
6.1. Direct Threshold Signature Ed25519
The signers are Alice and Bob's Threshold Signature Service 'Bob'. Each creates a key pair:¶
ED25519Alice's Key (ED25519) UDF: ZAAAGTSIGXED255XXALICEXSXKEY Scalar: 312191303806394376947696888962276115420485359001 34467943432016761653342335248 Encoded Private 10 AE C0 C2 16 65 9B 4F 7C 9D DE 82 3E 49 7F D4 9B 14 BB F8 2D 9F 0C 11 24 D7 15 E3 43 79 57 20 X: 13697699435406080999251131063344049965140553452 752305353714819106646919347160064793506327635954342719144289 2305566686088586980395284289746495530409889930 Y: 278793875610616080844162800185864399625503938157 569374174700414845758479331294424147393776831767266487579098 7675375777043504113387553916769515911310193558 Encoded Public 45 16 53 7C 26 50 CF DA F1 A4 DF 4C 45 DC 3D 95 4E B6 8E EB A6 5A 27 D6 CD 5B 43 C5 F4 06 53 ED ED25519Bob's Key (ED25519) UDF: ZAAAGTSIG2ED255XXBOBXSXKEY Scalar: 567212843891509414800308620158891720685508995620 72140666211075925337851277632 Encoded Private E5 CD 34 01 FD 8C 0E 27 81 4B 11 DD 12 68 50 A1 4B 5A D5 E1 E1 41 D7 68 5F 51 ED B4 3A 84 58 5C X: 13809282472298084436735987888897423507149580966 952791761446670884044433963975178482398144657564565223270588 5322459642470946347570575475534141406285323257 Y: 263684226342871984706317411760423095947068088366 393546798602378437432707482089806653755881399592963068751759 9645362525866308283171284327931970404321458677 Encoded Public F1 5F C0 78 F8 32 49 2C D9 64 CC 2B CF 90 5C 4F 23 EA BB F8 38 99 C5 FE F3 AA 67 BE AB EC D2 5E¶
The composite Signature Key A = A_{a} + A_{b}¶
Aggregate Key = Alice + Bob () UDF: TBS Scalar: 109634784180323260712231215560085272031403914964 7717337619681427565742601012 Encoded Private 34 33 AB 10 9A 09 A9 61 65 8B 3A EC 58 21 FB 2D 0D 45 74 49 45 BA E2 CF A8 98 C2 94 C9 82 6C 02 X: 83837675294300852842901121613445594296352372347 711317409367737761568353629718805151940195325485285476438422 923698718220652243749390297055882388709313280 Y: 160553422944358144751060009820735322036903773802 361117046457476895165059738086663330972263850675453249990301 0398473811263196653225446124160025082144761534 Encoded Public 48 1A 27 66 06 AF 4E 3C 20 A4 02 CD 8A 13 46 99 02 B7 75 F8 AC D4 7E 89 68 FB 68 EB D8 EF 4A C7¶
To sign the text "This is a test", Alice first generates her value r and multiplies it by the base point to obtain the value R_{a}:¶
Alice: r_a: 505210734621497595393270784745614175113191664157 4177425600105798482114377785 R_a = DF A3 D5 CC 9F 94 63 67 BB 3E C3 F7 88 4A 0D 52 00 20 A2 90 13 27 4E 47 03 19 DA EC BF 74 CB 14¶
Alice passes her value R_{A} to Bob along with the other parameters required to calculate i. Bob then calculates his value R_{A} and multiplies it by the base point to obtain the value R_{b}:¶
Bob: r_b: 677880217486034074720202546367410174561950677574 5309900070354323071886227867 R_b = DD C8 79 2A BB D8 72 D5 9D F5 13 22 C2 F1 58 62 47 DC 19 39 C5 CE 02 FB 24 0B FA 64 D1 55 BC 3E¶
Bob can now calculate the composite value R = R_{a} + R_{b} and thus the value k.¶
R = 5A D0 1C 17 95 ED 9B 99 B8 CD CE 7B EE 47 6E A5 0E A6 CF 51 DE DA 89 CB B5 F4 4C E2 D5 0D 58 FA k: 625005044347993004605907480401547053627770740065 2040602450571600703428702758¶
Bob calculates his signature scalar contribution and returns the value to Alice:¶
Bob: S_b: 136373130884201209719904273113512997386754201427 8737070757184293024413450866¶
Alice can now calculate her signature scalar contribution and thus the signature scalar S.¶
Alice: S_a: 694422500722053719583170959521207108671468233956 3089821393557557357031271837 S: 107095073873028707905756576330420681972510799446 1919286148790912095990471714¶
Alice checks to see that the signature verifies:¶
S.B = R + kA = X: 499652471325922372829034886924764341503336793855 86215130071277671241180454624 Y: 465061436809499600324596437786395684290405421559 11499262135862928788499885458¶
6.2. Direct Threshold Signature Ed448
The signers are Alice and Bob's Threshold Signature Service 'Bob'. Each creates a key pair:¶
ED448Alice's Key (ED448) UDF: ZAAAITSIGXED44XALICEXSXKEY Scalar: 672286477331130983513039743350616227864346753924 962787860729757222511999618443513569403793186398096717924945 854846544396984088344823264 Encoded Private 6F 85 B1 91 9A 37 06 A6 B2 15 79 AD 5B 69 16 6A 5A CD C8 17 D4 14 1F 68 DA 97 C5 B4 44 79 CE EA 3C 17 7B E1 29 44 70 DF 41 C8 98 38 1E 7C 9B 3B 03 63 6F 85 E8 39 31 91 X: 526046019655043632868470952286947529492283092344 122476077151423645243648974512182548405702873560533846673262 767064019365470830861106049 Y: 145374550785380850812934424757986866673485237047 938554544492694946608060986459495807055455048208713991919477 720250115717234689256856152 Encoded Public 59 55 F4 7A 66 08 91 35 F8 15 63 F4 90 91 7F 38 12 E3 49 22 51 F8 BC 4A 41 C9 44 59 5A 64 9B 40 0B C5 7E 53 48 0F 32 12 90 32 69 38 47 28 94 BB 99 D1 16 6F 2D D5 3D 4F 80 ED448Bob's Key (ED448) UDF: ZAAAITSIG2ED44XBOBXSXKEY Scalar: 455052626698262385397736547727159423941520792904 908612603542850909167215987713902322619933929404455741806848 064294945283113799683261212 Encoded Private CA 15 22 BD F4 0F 9E 0A EC A7 61 79 BE 9E E3 38 BF 93 D3 5B B3 E6 FC F0 A7 5B 7C F0 E7 B5 89 F6 2E F6 D1 0E 72 49 4D DF 34 5E 2F 7C 9E 42 1D 85 AB AB 30 BD 68 C6 3E 35 X: 752024108200272710832187535557164455078689734595 171189993383259892607253027500878543439908750525763880661232 171322059854852522782265 Y: 619329873102159676791326142073166790594683111409 729383584199833441028484525583699421181422168190856074786324 020492214873796495570056511 Encoded Public 76 2B FC F8 AC 96 79 DE 1C 72 07 65 DD 49 5B 28 C7 04 CB A8 A5 96 3D D9 9E 23 FA 05 83 15 33 95 85 82 F8 CF A3 7A 2F 24 F8 EB D6 AE 20 0A 25 D0 44 1A F9 C0 86 D7 87 B7 00¶
The composite Signature Key A = A_{a} + A_{b}¶
Aggregate Key = Alice + Bob () UDF: TBS Scalar: 370810175859830330867905792457688502754055057988 943100420373093608031918369199015948491953656482966798700316 64591515851455352870185802 Encoded Private 4A AB 7A BB 2D 95 72 75 B1 3A 1D 22 24 17 76 2D A1 D5 55 94 67 35 8C E7 A1 A0 ED 0C E7 88 FF 9F 6E 2F 70 80 89 F5 01 2A C0 AD 4C 4E 7B 90 68 6C F4 53 BA 32 9B 70 0F 0D X: 583249553407699999284154112964835446252412293188 857058051552519639906663406776316984154017062023869075790536 30514579317017660114474427 Y: 518040437562811181169413740718290938351269168888 257124107164689245721852001077758864406412789756149699111633 051823234569886260996269341 Encoded Public 34 70 8D 08 DE 63 0B A6 49 2A 33 D8 B7 15 A9 84 A4 87 F6 B6 C7 4B 1C AE 5A 1F 7C 4B 12 70 FB CF 5A A9 3C 20 31 BA 9A 53 A0 FE 2A 43 24 97 06 F8 DA 40 0D 88 E3 D9 DE 2E 00¶
To sign the text "This is a test", Alice first generates her value r and multiplies it by the base point to obtain the value R_{a}:¶
Alice: r_a: 154801816267240464546834446515456406651845314401 002977264905693500446669857879911189090126903643060098695902 159902668465952043665201729 R_a = BF 60 68 8C 92 23 91 A7 92 65 D7 A9 3A 11 B6 25 91 CC 72 0D 83 F7 80 06 4C 7F 7B FA F5 60 CF FC 43 DA 5E 9F 71 09 6C 51 6E 28 E7 8D 50 2D 7A 4A 1F 00 17 FF 18 F5 65 F0 00¶
Alice passes her value R_{A} to Bob along with the other parameters required to calculate i. Bob then calculates his value R_{A} and multiplies it by the base point to obtain the value R_{b}:¶
Bob: r_b: 151741242222551333693536358753113477279079323953 405968709541531009609312639878485678278493044984250865569658 971735381320787025215934551 R_b = E2 20 7A 34 5E E2 BE B0 EE DC 3D 7E 98 AB 00 5B 7E B5 4A 6D 9D 6B AE 00 C3 61 3C 0E BF 85 44 84 2D C2 46 BD 6A EB CF 60 52 A6 22 7F 3E 6D 52 D7 1B B5 A8 FB A2 6E D9 19 00¶
Bob can now calculate the composite value R = R_{a} + R_{b} and thus the value k.¶
R = 7D E7 D1 AC 39 91 2D A1 64 82 A2 12 11 FD 48 2A E4 C1 69 4F F1 DB 8C F4 B0 41 44 DB 81 9A 99 93 28 80 BD FC 4E 30 9A 0D 24 7C 2E 97 36 EB DA E9 78 83 08 B9 A5 1A 9F AF 80 k: 152478129684675943479409248843466240733035903267 926235089418642613018543821412858874657453613785631671228639 879208851203344161958472626¶
Bob calculates his signature scalar contribution and returns the value to Alice:¶
Bob: S_b: 483080257179106760967096112599711672595306939349 964976636926846127260138522913206826943834871540343367464674 04823679970210640505379249¶
Alice can now calculate her signature scalar contribution and thus the signature scalar S.¶
Alice: S_a: 929765386089729500539533802678644970120766195521 592545136047824546064521300569760854876125225246919399958779 43127262307963446226438525 S: 141284564326883626150662991527835664271607313487 155752177297467067332465982348296768181996009678726276742345 347950942278174086731817774¶
Alice checks to see that the signature verifies:¶
S.B = R + kA = X: 438553256512884225923994157378894696848243269381 58786710000478625591080896686 Y: 100086885282402628787474925500974806696629978712 71442659795857672094353438094¶
6.3. Shamir Threshold Signature Ed25519
The administrator creates the composite key pair¶
ED25519Aggregate Key (ED25519) UDF: ZAAAGTSIGQED255XXAGGREGATEXKEY Scalar: 367238470592488326468789252109412889361910680229 03089760692844779165588879504 Encoded Private FE 48 94 1F EB 3D 28 E1 61 81 E2 1E E1 CF F2 1E 1E 70 91 30 DF 98 9F 1C 34 EB BB 74 C5 C8 07 EB X: 143576564277195758046684172284175869008525477709 640743490221115123376609940386394888392330104965579307772627 313244177612005636942740116142030215202393600 Y: 844838272625277895849027219595751726665225134917 547580682441821283235675507225396641352769322822815561632929 543097074319051436285787045255908364074589900 Encoded Public DF E8 0A 2B E9 6C 53 C0 AB 9B BC BC 39 95 9A 61 9C 33 2E 22 24 A7 F7 F2 21 06 AC 6D 01 5D 0B E2¶
Three key shares are required for Alice, Bob and Carol with a threshold of two. The parameters of the Shamir Secret Sharing polynomial are:¶
a0 = 367238470592488326468789252109412889361910680229030897606928 44779165588879504 a1 = 699266283035359788689002485914571600271382111380710376847895 2287632180176739¶
The key share values for the participants are¶
xa = 1 ya = 294476425608857249929830691829039493762190980430747893160091 437085043550309 xb = 2 yb = 501336786301929228466689879317612556188957348579440556370927 86431769476059 xc = 3 yc = 704279650898379080973669384707747725833271684866504782411604 5074063949652798¶
Alice and Carol are selected to sign the message "This is another test"¶
The Lagrange coefficients are:¶
la = 361850278866613110698659328152149712042855817968995380300097 5469142727125496 lc = 361850278866613110698659328152149712042855817968995380300097 5469142727125494¶
Alice and Carol select their values ra, rc¶
ra = 456116926701492705315133938623040527696276882295617965847376 7682545245216294 Ra = D4 45 96 7B EC 72 EF EB CE 64 45 4B F1 04 BE 89 82 76 38 A9 C7 CD 49 D5 AC 89 89 15 A1 2C F9 ED rc = 482074679100753533345731495679776832764315286485235535312553 5253541881347149 Rc = 84 2F BA 3B E3 BB 6B FD 1E A7 4A 9A F7 69 CB F2 42 E0 40 37 72 CB 44 76 91 F3 78 4C 38 6A 55 70¶
The composite value R = R_{a} + R_{c}¶
R = 86 D3 74 FB 11 A5 B0 02 0E C8 D8 47 81 F6 D3 0B 2F 98 1A 78 A4 B6 29 8E CF 8F 1F BA C6 DF 9C CE¶
The value k is¶
k = 108571726585613745870710472121182543905966072176325240119429 6512368686397102¶
The values R and k (or the document to be signed) and the Lagrange coefficients are passed to Alice and Carol who use them to calculate their secret scalar values:¶
sa = 406021742707941698188133931926505636107184465033607564274111 2624770292450958 sc = 371560732284036680910483963950425561169075793504738369394392 8401253479424590¶
The signature contributions can now be calulated:¶
Sa = 392895418968963203512266836046291402317818369828942689298477 2946200577969243 Sc = 253752237332419145649601433321208219235347953185395225369356 1893073151349028¶
The dealer calculates the composite value S = S_{a} + S_{b}¶
S = 646647656301382349161868269367499621553166323014337914667833 4839273729318271¶
The dealer checks to see that the signature verifies:¶
S.B = R + kA = X: 226427714657102020025604838380148290637031902023 61838906492538114789522304796 X: 106130935431547011586457110809164124211743921447 29537260912052744073378658652¶
6.4. Shamir Threshold Signature Ed448
The administrator creates the composite key pair¶
ED448Aggregate Key (ED448) UDF: ZAAAITSIGQED44XAGGREGATEXKEY Scalar: 723088510822916843359337925516642493307623385482 113107480846498794254549074097051759295396782499503452909258 978468506553055366989547456 Encoded Private 59 DC 8A 5F 5E AF 8C FA 96 19 F8 EE 78 13 00 12 33 0E 12 80 2D 25 E6 EF E8 E2 56 B5 83 6A 0C CF DC 11 96 A5 A5 D1 39 AA 34 25 0B 52 ED 9F 38 92 5D 9F 7B BC B9 BC 86 45 X: 600163199260212879671026282440221570752543874569 276531213297382365938924845597497264583528185273760383031589 25167107013312482098672476 Y: 568007995844826855892481230051783440873263817862 016100095069663100696528804467952219402043387612562057320585 561865068046226655443122582 Encoded Public ED C3 90 99 38 0B 8F CD 60 29 24 04 6C DE 52 33 A2 07 3E 56 8D 27 B5 B9 21 60 CF E9 E7 9D D6 4A 11 47 20 E6 9D FE 75 C7 04 14 70 18 B4 52 10 83 D0 EC 98 BD F5 E6 E3 D5 80¶
Three key shares are required for Alice, Bob and Carol with a threshold of two. The parameters of the Shamir Secret Sharing polynomial are:¶
a0 = 723088510822916843359337925516642493307623385482113107480846 49879425454907409705175929539678249950345290925897846850 6553055366989547456 a1 = 165663618071837435927824367225611232537435726800694979220111 02522386453540608200774410212968582148967992226507570036 4540659700713156444¶
The key share values for the participants are¶
xa = 1 ya = 161913404599147388737838484854249191491417751595490026419467 32483753506863402071663861450530155148927959034921780222 1874620044264104784 xb = 2 yb = 145867341597083102028331900107859290440443138224355490569205 80026625360007856313866652087969568060299620232058441092 4110505989117611449 xc = 3 yc = 129821278595018815318825315361469389389468524853220954718944 27569497213152310556069442725408980971671281429195101962 6346391933971118114¶
Alice and Carol are selected to sign the message "This is another test"¶
The Lagrange coefficients are:¶
la = 908548405369508613186654759860005667942051700859147575351862 74897573001980769792858097877645846187981655146854545831 152386877929824891 lc = 908548405369508613186654759860005667942051700859147575351862 74897573001980769792858097877645846187981655146854545831 152386877929824889¶
Alice and Carol select their values ra, rc¶
ra = 103517366944050550717591081348710241163469949228538856371118 47833970060549248948499739275675447160833072419041041347 1187333803802632789 Ra = 86 8B B6 BF E1 FA 18 BB 5A D6 79 D2 6F 60 E9 7A B9 76 58 AA 96 3B 5E FD 83 E7 79 09 53 A2 AE 7B 89 C6 30 72 31 13 C3 97 9D 0C 75 BB F2 DC 87 72 46 CD F8 BF 6F 08 27 FF 00 rc = 129544664690317775866810455605532383977152960638027121327286 30462413505947371161103544570926395906833875655978561651 9513959988103594270 Rc = D6 0E 7A 4B C1 D1 A4 A4 09 A9 4E 2C 0C 11 E8 31 E3 F7 0D C0 AD 7E 90 6D 53 63 6B D0 D0 5D 5F BD 44 34 4F B9 1D 5C 05 7B A8 52 5D 39 00 8B 47 30 46 15 B7 39 00 35 A6 8D 00¶
The composite value R = R_{a} + R_{c}¶
R = 84 76 AE 71 96 E4 5B 2C 32 7A CE 8C 62 4E C5 C7 56 90 58 7B 46 C1 99 87 95 72 E0 39 14 59 50 3A 53 63 60 8A 2B 14 DD C2 99 AF 57 5D 7F 28 6C DC 73 4E 72 6A 0A 67 B9 F0 80¶
The value k is¶
k = 846715492312861675786877637427593731664460324443667916137724 03306404008461876775118415847980023413626823976377915241 076018146143898434¶
The values R and k (or the document to be signed) and the Lagrange coefficients are passed to Alice and Carol who use them to calculate their secret scalar values:¶
sa = 611604258248193604694267753093726536487162872214055245588284 37461156598989491489241726002660634857956075230117611670 507156310536507397 sc = 116799041776392314977918294291266438893676077745219037710900 41194765993819998680536898212824678751760690314773358184 9131577788874090722¶
The signature contributions can now be calulated:¶
Sa = 674398491172392582315391447961842592916627666141711533732986 40302585673169645319736684479821824290746431281389532198 884328704969312923 Sc = 323501021094800816208302172187722789450985391108790119316146 83012739259001534721728765613699056985895227578447593375 275645256932691561¶
The dealer calculates the composite value S = S_{a} + S_{b}¶
S = 997899512267193398523693620149565382367613057250501653049133 23315324932171180041465450093520881276641658859837125574 159973961902004484¶
The dealer checks to see that the signature verifies:¶
S.B = R + kA = X: 310176585478125150718252258963045651393161473743 3144189417665237106104024598 X: 546975372341826393522134872750971962955374107574 98782836263975525610781195547¶
7. Security Considerations
All the security considerations of [RFC7748], [RFC8032] and [drafthallambakerthreshold] apply and are hereby incorporated by reference.¶
7.1. Rogue Key attack
The rogue key attack described in [drafthallambakerthreshold] is of particular concern to generation of threshold signatures.¶
If A and B are public keys, the intrinsic degree of trust in the composite keypair A + B is that of the lesser of A and B.¶
7.2. Disclosure or reuse of the value r
As in any Schnorr signature scheme, compromise of the value r results in compromise of the private key. The base signature specification [RFC8032] describes a deterministic construction of r that ensures confidentiality and uniqueness for a given value of k.¶
As described above, this approach is not applicable to the generation of values of r_{i} to compute threshold signature contributions. Accordingly the requirements of [RFC4086] regarding requirements for randomness MUST be observed.¶
Implementations MUST NOT use a deterministic generation of the value r_{i} for any threshold contribution except for calculating the final contribution when all the other parameters required to calculate k are known.¶
7.3. Resource exhaustion attack
Implementation of the general two stage signing algorithm requires that signers track generation and use of the values r_{i} to avoid reuse for different values of R_{i}. Implementations MUST ensure that exhaustion of this resource by one party does not cause other parties to be denied service.¶
7.4. Signature Uniqueness
Signatures generated in strict conformance with [RFC8032] are guaranteed to be unique such that signing the same document with the same key will always result in the same signature value.¶
The signature modes described in this document are computationally indistinguishable from those created in accordance with [RFC8032] but are not unique.¶
Implementations MUST not use threshold signatures in applications where signature values are used in place of cryptographic digests as unique content identifiers.¶
8. IANA Considerations
This document requires no IANA actions.¶
9. Acknowledgements
[TBS]¶
10. Normative References
 [drafthallambakermeshudf]
 HallamBaker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, InternetDraft, drafthallambakermeshudf11, , <https://tools.ietf.org/html/drafthallambakermeshudf11>.
 [drafthallambakerthreshold]
 HallamBaker, P., "Threshold Modes in Elliptic Curves", Work in Progress, InternetDraft, drafthallambakerthreshold04, , <https://tools.ietf.org/html/drafthallambakerthreshold04>.
 [RFC2119]
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfceditor.org/rfc/rfc2119>.
 [RFC4086]
 Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, , <https://www.rfceditor.org/rfc/rfc4086>.
 [RFC7748]
 Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfceditor.org/rfc/rfc7748>.
 [RFC8032]
 Josefsson, S. and I. Liusvaara, "EdwardsCurve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfceditor.org/rfc/rfc8032>.
11. Informative References
 [drafthallambakermeshdeveloper]
 HallamBaker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, InternetDraft, drafthallambakermeshdeveloper10, , <https://tools.ietf.org/html/drafthallambakermeshdeveloper10>.
 [Komlo]
 Komlo, C. and I. Goldberg, "FROST: Flexible RoundOptimized Schnorr Threshold Signatures", .
 [RFC5860]
 Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, , <https://www.rfceditor.org/rfc/rfc5860>.
 [Shamir79]
 Shamir, A., "How to share a secret.", .