Internet-Draft Threshold Signatures in Elliptic Curves July 2020
Hallam-Baker Expires 28 January 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-hallambaker-threshold-sigs
Published:
Intended Status:
Informational
Expires:
Author:
P. M. Hallam-Baker
ThresholdSecrets.com

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 non-deterministic. 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts 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 Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 January 2021.

▲

Table of Contents

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 multi-signatures, 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 multi-signatures or threshold signatures to be inherently superior, it is more useful to regard both as two points on a continuum of choices:

Multi-signatures

Multiple digital signatures on the same document. Multi-signatures 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.

Multi-party 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 [draft-hallambaker-threshold] 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 [draft-hallambaker-threshold].

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 multi-signatures.

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 [draft-hallambaker-mesh-developer].

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:

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:

S.B

= (r + k.s).B

= r.B +k.(s.B)

= R + k.A

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 = (S-r).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

S1 = r + k1.s mod L

S2 = r + k2.s mod L

s = (S1 - S2)(k1 - k2)-1 mod L

The method of constructing r MUST ensure that it is unique and unguessable.

3.1. Direct shared threshold signature

A threshold signature R, S is constructed by summing a set of signature contributions from two or more signers. For the case that the composite private key is the sum of the key shares (n = t), each signer i provides a contribution as follows:

Ai = si.B

Ri = ri.B

Si = ri + k.si mod L

Where si and ri are the secret scalar and unguessable value for the individual signer.

The contributions of signers {1, 2, ... n} are then combined as follows:

R = R1 + R2 + ... + Rn

S = S1 + S2 + ... + Sn

A = s.B

Where s = (s1 + s2 + ... + sn) mod L

The threshold signature is verified in the same manner as before:

S.B = R + k.A

Substituting for S.B we get:

= (S1 + S2 + ... + Sn).B

= S1.B + S2.B + ... + Sn.B

= (r1 + k.s1).B + (r2 + k.s2).B + ... + (rn + k.sn).B

= (r1.B + k.s1.B) + (r2.B + k.s2.B) + ... + (rn.B + k.sn.B)

= (R1 + k.A1) + (R1 + k.A1) + ... + (Rn + k.An)

Substituting for R + k.A we get:

= R1 + R2 + ... + Rn + k.(A1 + A2 + ... + An)

= R1 + R2 + ... + Rn + k.A1 + k.A2 + ... + k.An

= (R1 + k.A1) + (R1 + k.A1) + ... + (Rn + k.An)

As expected, the operation of threshold signature makes use of the same approach as threshold key generation and threshold decryption as described in [draft-hallambaker-threshold]. As with threshold decryption it is not necessary for each key share holder to have a public key corresponding to their key share. All that is required is that the sum of the secret scalar values used in calculation of the signature modulo the group order be the value of the aggregate secret scalar corresponding to the aggregate secret key.

While verification of [RFC8032] signatures is unchanged, the use of threshold signatures requires a different approach to signing. In particular, the fact that the value k is bound to the value R means that the participants in the threshold signature scheme must agree on the value R before the value k can be calculated. Since k is required to calculate the signature contributions Si can be calculated, it is thus necessary to calculate the values Ri and Si in separate phases. The process of using a threshold signature to sign a document thus has the following stages orchestrated by a dealer as follows:

  1. The dealer determines the values F, C and PH(M) as specified in [RFC8032] and transmits them to the signers {1, 2, ... n}.
  2. Each signer generates a random value ri such that 1 ri L, calculates the value Ri = ri.B and returns R to the dealer .
  3. The dealer calculates the value R = R1 + R2 + ... + Rn and transmits R and A to the signers {1, 2, ... n}.
  4. Each signer uses the suppled data to determine the value k and hence Si = ri + k.si mod L and transmits it to the dealer .
  5. The dealer calculates the value S = S1 + S2 + ... + Sn and verifies that the resulting signature R, S verifies according to the mechanism specified in [RFC8032]. If the signature is correct, the dealer publishes it. Otherwise, the dealer MAY identify the signer(s) that provided incorrect contributions by verifying the values Ri and Si for each.

For clarity, the dealer role is presented here as being implemented by a single party.

3.2. Shamir shared threshold signature

To construct a threshold signature using shares created using Shamir Secret Sharing, each private key value si is multiplied by the Lagrange coefficient li corresponding to the set of shares used to construct the signature:

Ai = sili.B

Ri = ri.B

Si = ri + klisi mod L

It is convenient to combine the derivation of Si for the additive and Shamir shared threshold signatures by introducing a key multiplier coefficient ci:

Si = ri + kcisi mod L

Where

ci = 1 for the additive shared threshold signature

ci = li for the Shamir shared threshold signature

3.3. Stateless computation of final share

One of the chief drawbacks to the algorithm described above is that it requires signers to perform two steps with state carried over from the first to the second to avoid reuse of the value ri. This raises particular concern for implementations such as signature services or HSMs where maintaining state imposes a significant cost.

Fortunately, it is possible to modify the algorithm so that the final signer does not need to maintain state between steps:

  1. All the signers except the final signer F generate their value ri and submit the corresponding value Ri to the dealer
  2. Dealer calculates the value R - RF and sends it to the final signer together with the all the other parameters required to calculate k and the final signer's key multiplier coefficient cF.
  3. The final signer generates its value rF
  4. The final signer calculates the value RF from which the values R and k can now be determined.
  5. The final signer calculates its key share contribution SF = rF + kcFsF mod L.
  6. The final signer returns the values SF and R to the dealer.
  7. The dealer reports the value R to the other signers and continues the signature process as before.

While this approach to stateless computation of the signature contributions is limited to the final share, this is sufficient to cover the overwhelming majority of real-world applications where n = t = 2.

Note that the final signer MAY calculate its value rF deterministically provided that the parameters R - RF and cF are used in its determination. Other signers MUST NOT use a deterministic means of generating their value ri since the information known to them at the time this parameter is generated is not sufficient to fix the value of R.

3.3.1. Side channel resistance

The use of Kocher side channel resistance as described in [draft-hallambaker-threshold] entails randomly splitting the private key into two shares and performing the private key operation separately on each share to avoid repeated operations using the same private key value at the cost of performing each operation twice.

This additional overhead MAY be eliminated when threshold approaches are used by applying blinding factors whose sum is zero to each of the threshold shares.

For example, if generation of the threshold signature is divided between an application program A and an HSM B using the final share approach to avoid maintaining state in the HSM, we might generate a blinding factor thus:

  1. A generates a random nonce nA and sends it to B with the other parameters required to generate the signature.
  2. B generates a random nonce nB
  3. B calculates the blinding factor x by calculating H(nA, nB) where H is a strong cryptographic digest function and converting the result to an integer in the range 1 x L.
  4. B calculates the signature parameters as before except that the threshold signature contribution is now SB = rB + k(cBsB + x) mod L.
  5. B returns the nonce nB to A with the other parameters.
  6. A calculates the blinding factor x using the same approach as B
  7. A calculates the signature parameters as before except that the threshold signature contribution is now SA = rA + k(cAsA - x) mod L.

This approach MAY be extended to the case that t > 2 by substituting a Key Derivation Function (e.g. [RFC5860]) for the digest function.

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 ri 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 ri 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 ri 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 ri 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 ri is never revealed to any other party and is never used to create signatures for two different values of k.si.

Ensuring this does not occur imposes significant design constraints as creating a correct signature contribution requires that the signer use the same value of ri to construct its value or Ri and Si.

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 ri within the device itself using an appropriately authenticated and encrypted opaque state token. Such mechanisms provide the HSM with the value of ri 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 Ri = ri.B and Si = ri + ksi.

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 = A1 + A2 + ... + An

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 An = Am - (A1 + A2 + ... + An-1)

The attacker can thus gain control of the aggregate signature key by choosing Am = sm.B where sm is a secret scalar known only to the attacker. But does so at the cost of not knowing the value sn 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 A1 + A2 + ... + An 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 ad-hoc 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 [draft-hallambaker-threshold].

The dealer selects the signers who are to construct the signature. Each signer then computes the value Ri:

  1. Randomly generate an integer ri such that 1 ri L.
  2. Compute the point Ri = riB. For efficiency, do this by first reducing ri modulo L, the group order of B. Let the string Ri be the encoding of this point.
  3. Transmit the value Ri to the dealer
  4. 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 ci. The signers MAY then complete their signature contributions:
  5. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 64-octet digest as a little-endian integer k.
  6. Compute Si = (ri + kcisi) mod L. For efficiency, again reduce k modulo L first.
  7. Return the values Ri, Si to the dealer .

The dealer then completes the signature by:

  1. Computing the composite value S = S1 + S2 + ... + Sn
  2. Verifying that the signature R, S is valid.
  3. Publishing the signature.

5. Ed448 Signature

The means by which threshold shares are created is described in [draft-hallambaker-threshold].

The dealer selects the signers who are to construct the signature. Each signer then computes the value Ri:

  1. Randomly generate an integer ri such that 1 ri L.
  2. Compute the point Ri = riB. For efficiency, do this by first reducing ri modulo L, the group order of B. Let the string Ri be the encoding of this point.

Transmit the value Ri to the dealer

  1. 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 ci. The signers MAY then complete the signature contributions:
  2. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret the 114-octet digest as a little-endian integer k.
  3. Compute Si = (ri + kcisi) mod L. For efficiency, again reduce k modulo L first.
  4. Return the values Ri, Si to the dealer.

The dealer then completes the signature by:

  1. Computing the composite value S = S1 + S2 + ... + Sn
  2. Verifying that the signature R, S is valid.
  3. Publishing the signature.

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:        ZAAA-GTSI-GXED-255X-XALI-CEXS-XKEY
    Scalar:     56271244081186130980636545017945156580516101894352492
        459594967614223399428880
    Encoded Private
  33 40 0E 22  D8 67 17 F4  8A 9F 6A 46  61 B4 0E AD
  8C D0 DD C3  79 CD 85 BD  95 5C 90 B9  6C CB 8C 23
    X: 11116793672970427161790264469280294507189044728140547954071022
        7976454124042406369344932655633664630560242213431409139866940
        284702002648469365756492647970
    Y: 61655404171611396573021808119108664749574235125343680206454285
        6299141386615046548323087409388548650272224487089895079970526
        0143544115364878870129761259200
    Encoded Public
  E2 AB 8F 37  62 C8 7B F9  E9 BC 59 0C  2E 99 A5 58
  0C C3 19 D5  CD DA 53 DF  3E C1 F0 C0  FE D3 55 5E
ED25519Bob's Key (ED25519)
    UDF:        ZAAA-GTSI-G2ED-255X-XBOB-XSXK-EY
    Scalar:     54940772670153459146152925564198105262971485730889818
        986727608573229799020168
    Encoded Private
  68 9A 68 92  8A 06 17 84  35 3C B7 08  F8 56 00 3F
  BA 31 8C 42  B0 42 FE 2D  18 F2 7F AB  CD 10 49 F1
    X: 14271495069349838216379540196263140964032393512903842206168182
        5518850827098876289800868735522232908519794251130907125878675
        6343411484065706313568410880015
    Y: 28094328948004112428189466223757440886388684291254605355859923
        6240968229706795825282419594219442074647093851302547452470435
        9438513477629978601366725015573
    Encoded Public
  32 E5 8D 5E  66 B2 F9 E9  14 79 08 71  96 3B 9A 75
  A2 31 59 4B  8E ED 18 EF  BD FF 11 D4  47 2A 8C F4

The composite Signature Key A = Aa + Ab

Aggregate Key = Alice + Bob ()
    UDF:        TBS
    Scalar:     26569330913556569171916721364983482306308422345436973
        56293312113171384684213
    Encoded Private
  B5 CE 0E B3  9C CF 18 99  CF 8D 4C BB  AE 81 79 1F
  CE 13 AA 3E  63 59 5B AC  8D 2C EB A4  55 C5 DF 05
    X: 67872685043898469012456949773240814121645904736114813455820339
        8688906486811443744733724675994181258029547346985079901494367
        752381127781166234556148580090
    Y: 36481740058369645484420180976004932062085375941522344052907594
        0118552792158551197107484892204562290802810655253510302448455
        4128548992118101415797909250954
    Encoded Public
  29 65 63 86  4F FB 10 8D  BA 7A 0A 68  04 6D 00 DA
  9B 1D C3 A4  AF BA 95 B4  5D 27 B4 35  00 2F DF 32

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 Ra:

Alice:
r_a =  28252297832860951598280681978007925712134245112279765222970892
    78411772675279
R_a =
  DF F6 AE B9  4E E4 62 27  14 DC 6C 30  F8 10 2F 14
  5B 82 FA 66  5C AB 85 5B  F9 E1 4D F4  D9 9B 41 91

Alice passes her value RA to Bob along with the other parameters required to calculate i. Bob then calculates his value RA and multiplies it by the base point to obtain the value Rb:

Bob:
r_b =  86613263691944485847762993260062261656352423068967023596525906
    2756603651453
R_b =
  62 41 83 14  F6 F0 7C 00  7C DA 7D B4  8F 48 94 F9
  51 47 DE D4  5D CF 59 0A  2E B1 12 5C  3F 92 C6 B9

Bob can now calculate the composite value R = Ra + Rb and thus the value k.

R =
  16 42 B3 D1  E6 0B 28 70  BE 34 FD 96  A3 AE D1 D0
  E3 2C ED D9  7E 0F 0F 7C  49 66 81 07  14 15 F3 D2
k =  2797020107652734706165091555110249145614801643303197520413427535
    565755125156

Bob calculates his signature scalar contribution and returns the value to Alice:

Bob:
S_b =  48375856420930884440007193566362832409084415624159039861319760
    68167612384018

Alice can now calculate her signature scalar contribution and thus the signature scalar S.

Alice:
S_a =  15877329126883564721345149242175068179907537753005818280475248
    54623296146441
S =  6425318554781444916135234280853790058899195337716485814179500922
    790908530459

Alice checks to see that the signature verifies:

S.B = R + kA =
    X: 14048605832004776210986630920964015464097464636338510135087415
        397188796127602
    Y: 36173689597703967479067358832144051767352589412259808754236330
        46649747982388

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:        ZAAA-ITSI-GXED-44XA-LICE-XSXK-EY
    Scalar:     63495803583658817688110446314786076976347236361354035
        5597788771064742993095132758589292255654895141583596922516472
        738879360490167934280
    Encoded Private
  A0 53 4C 93  3C 34 00 76  AE 5D B5 4A  C2 71 5F 43
  E1 D6 63 2C  5C 56 53 C8  98 A0 8F 03  FF F5 22 96
  91 45 8C 2B  CF E3 FD 7E  2A 9E 0B D6  F4 CC 66 61
  43 62 72 7B  34 B4 79 92
    X: 24743197509267833262111449556527285120868167712209919570838426
        3466168536901525943558973091346360088759980994772668117646359
        614426660579
    Y: 21342899120576770537664462049685258390853729788303428349051130
        8752175233505795318243164692156369495328007220135137156078814
        081547431302
    Encoded Public
  0A 3B F3 27  E7 E1 67 63  2C 59 E2 1C  D1 84 C7 83
  E8 1E D1 68  9F 32 A1 16  99 00 5C DA  29 B9 6C 08
  E4 15 57 7E  E5 63 C2 32  08 23 41 68  5F 49 1F FF
  BC 4D CD 3A  4E A6 85 49  00
ED448Bob's Key (ED448)
    UDF:        ZAAA-ITSI-G2ED-44XB-OBXS-XKEY
    Scalar:     72649803773199751564998543891898904839718409312910780
        0262041941160989643727331987658132182181970054245587322070535
        846720571414845714224
    Encoded Private
  BC 53 B4 74  3E A7 A7 FA  9F 05 9A BC  8C 22 26 15
  A1 4E BB 10  0E B5 59 6B  DE 9C 1B E9  F2 3C 65 42
  E7 B4 47 18  60 AC 18 A6  D2 78 B8 BC  CE F5 F4 28
  B2 3A FF 08  61 EF 6B 7C
    X: 58235851934808640621920816872959059172692411187640950432203039
        8116748997750134460231406698091317008063030408798536634284207
        667468558264
    Y: 34390767697909283892495761259186538632120422458392131201372282
        6056455656591826216381185634080685718154852726725624178995827
        091591132128
    Encoded Public
  93 63 5A 45  2D 4C 94 32  45 23 CD E2  A8 46 E4 78
  A0 80 59 DA  36 CB 6B 0C  06 64 6F BE  51 AB C0 BF
  1E DB A8 3F  2B 3B 80 0F  BF 00 E6 78  DD E0 83 E9
  AC 20 02 55  87 07 39 38  00

The composite Signature Key A = Aa + Ab

Aggregate Key = Alice + Bob ()
    UDF:        TBS
    Scalar:     89488306051273634069773238262841883041784075539841550
        3672228636597106090916876462340541507950185640860121886233669
        49466515613996100051
    Encoded Private
  D3 29 DD AB  F6 0D 99 8B  75 65 B8 06  36 C9 3A 2C
  D4 08 C3 9B  7C F9 77 8C  68 29 0E 3D  5D C7 3E 00
  92 8B DC AE  26 FB 16 39  CD 25 1B 23  4A 5A 05 61
  1D 5C C4 70  0A C9 84 1F
    X: 17985659098670117617173315763082238685735647626871251468000984
        2080317111091696183607307614171726960576308774975742249260532
        199160570999
    Y: 31506323224859159594386181995639405170623657273945727288760063
        1624406694682617334725040181287905351066763414658543828623841
        509161975864
    Encoded Public
  9B 3E DF 49  55 40 9F 7B  EA 0B AA 40  B7 3D 15 82
  60 9F 7C 40  CF 67 DE 56  56 0D 03 87  63 3B 15 F2
  45 33 FE 48  BD 2D A0 A2  8B CC 74 DA  94 0F 39 00
  AC 39 CB 0A  9F A4 EB B0  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 Ra:

Alice:
r_a =  15684829983275288995320186153682315307036276400872486386606140
    20721663995281251069957266441881719429669411819710530972409821299
    94391377
R_a =
  86 2D FF 0D  34 FF 93 A2  99 C1 DA 53  7D DE 10 6E
  D6 9D C6 AC  2A 81 F5 AF  EC 41 6B 7E  38 E3 22 1D
  6F C1 55 37  5A 05 87 68  44 76 57 5E  DC 04 8F 93
  72 D7 A8 AD  E8 4D FB F0  00

Alice passes her value RA to Bob along with the other parameters required to calculate i. Bob then calculates his value RA and multiplies it by the base point to obtain the value Rb:

Bob:
r_b =  79056431214191269155192383976412419075049008490046667820100793
    84788895637438670178724156135351810277821722098608373467015988487
    1882910
R_b =
  E1 0A 96 F3  0E F2 E2 C8  36 E2 8F 35  15 86 9C 91
  AD 9F 1D D0  2D FC 96 F2  D8 E2 C9 BE  13 3B FA 9E
  A1 21 98 28  A0 41 79 B0  E1 EC 2B EE  15 B2 B2 9D
  75 4B 2A 6B  86 68 A9 C2  80

Bob can now calculate the composite value R = Ra + Rb and thus the value k.

R =
  2B E8 C1 E1  FA DF 1B 50  27 F4 4C 84  6C B7 4D A9
  C4 EB 4C D0  F6 04 C0 BC  97 53 D6 3F  83 DE EE 36
  13 55 28 07  DA 2B 3A 61  A7 2C 0D 2E  78 23 5C 3F
  A9 4C BD B1  B4 5B 14 B6  80
k =  3104035016894745258020556693559708903901753754395101160443709988
    20544389791880657510893817184395739335438837168474541892332730355
    38436

Bob calculates his signature scalar contribution and returns the value to Alice:

Bob:
S_b =  83856930905971738123555179921528993630455764976428992230589064
    17912080930849738775369776320958057030801275126927029493866362083
    0803528

Alice can now calculate her signature scalar contribution and thus the signature scalar S.

Alice:
S_a =  43099647027479929480177407938099579737460614404521488090665877
    65441595355573833427013292472637983265478823380629687922844240279
    3663249
S =  1269565779334516676037325878596285733679163793809504803212549418
    33536762864235722023830687935960402962800985075567174167106023624
    466777

Alice checks to see that the signature verifies:

S.B = R + kA =
    X: 27540371650181561163208672964900973729470420238728950478919811
        969738134199870
    Y: 19755386299771259710738338973799913362714785991218934682176080
        685883211400359

6.3. Shamir Threshold Signature Ed25519

The administrator creates the composite key pair

ED25519Aggregate Key (ED25519)
    UDF:        ZAAA-GTSI-GQED-255X-XAGG-REGA-TEXK-EY
    Scalar:     39348647608109113656999806950437958090469802387424444
        589375066079861075223816
    Encoded Private
  37 39 5E 7A  8B A5 A0 19  46 4B 58 22  EA 24 A5 71
  45 2C 2A AC  7A 3E FB CA  CE 3F D4 12  9A BA EB 70
    X: 14198837758377867455716504277518729070915183249890461230792115
        9904969716778427995951234766002164511738587575257530388758374
        7824906047250057721855068523970
    Y: 20211025649802071998810413948266748565975140520947927724517956
        2067625505077751598018629551746824533726709810990193455662385
        6152736116303441031851305458040
    Encoded Public
  6E 13 79 B4  39 DA 97 9C  5A 34 CE 79  CD 1B 50 DF
  A0 76 AD 49  81 6D 52 59  A4 2C DB CE  44 FF 3E F5

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 = 3934864760810911365699980695043795809046980238742444458937506607
    9861075223816
a1 = 4798362372766583098538153346773251746668866286832200720618642047
    331470895827

The key share values for the participants are

xa = 1
ya = 7249765168821234716988409189532443919959705179771996739820024974
    79820613709

xb = 2
yb = 5523338889648706570236994265726496138664836804809400394600644544
    811291509536

xc = 3
yc = 3084695685083027454801961049456753644476586732261693509217335653
    857308154374

Alice and Carol are selected to sign the message "This is another test"

The Lagrange coefficients are:

la = 3618502788666131106986593281521497120428558179689953803000975469
    142727125496
lc = 3618502788666131106986593281521497120428558179689953803000975469
    142727125494

Alice and Carol select their values ra, rc

ra = 6406776677070753991363579376151421775148434886279361733741879781
    662225472462
Ra =
  7A 88 15 75  B9 99 00 3E  A8 8D D9 4F  CE 64 67 C0
  71 F6 1A B1  EE 1F 55 A3  71 07 31 BC  FC 5A 49 F1

rc = 5958533895226827077410644846357897216892759391052774026998871424
    715495190152
Rc =
  00 89 C9 D9  B8 1C 6B 1D  44 A1 00 9C  16 99 CD AC
  BD FB 0C 0B  F8 65 5C 4A  FE 69 06 2D  58 17 19 A0

The composite value R = Ra + Rc

R =
  DC 61 8E 8B  C6 A5 1D 2A  31 C0 19 E4  38 E0 C9 D2
  82 E4 E4 B2  53 06 0E A8  0B CE 4C FA  05 2B 74 FB

The value k is

k = 50907340692780523985686744123999692109367179795397994397880222656
    41762483896

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 = 4705967563989316314534854659951363708422513956655753313973979215
    362458046058;
sc = 5694657734790748486572206038314617418618822993249060851393283111
    356800173802

The signature contributions can now be calulated:

Sa = 4584986261294035801359294763213012962375140035136167784561957449
    592014170956
Sc = 5308862698539411268940165555902442973527213832481365138518280072
    090984937511

The dealer calculates the composite value S = Sa + Sb

S =  2656843382501184856326273756072461695045237508237625317078286583
    397544857478

The dealer checks to see that the signature verifies:

S.B = R + kA =
    X: 52723037549461607880395142365273697010074587609494537256541757
        983023705100003
    Y: 28519485444057715694172079072425502571337622066597069911947223
        402551723626936

6.4. Shamir Threshold Signature Ed448

The administrator creates the composite key pair

ED448Aggregate Key (ED448)
    UDF:        ZAAA-ITSI-GQED-44XA-GGRE-GATE-XKEY
    Scalar:     50890460656419721531273587958284096015810982760541575
        4207268050539683337837216003977228732536078674802149039736292
        653681850024283019712
    Encoded Private
  78 22 7E 3B  89 95 80 5D  04 19 DC 27  F1 7F 9B E4
  86 2B 0B DD  55 64 EE 04  19 49 4D DE  B9 04 3B 9E
  8B 7D DC EC  EC 8F DD 1D  E7 88 86 FD  11 FD 78 EF
  1A 8B 84 8F  77 00 73 65
    X: 44109173355278142669484438370724914685176368933547176239809629
        7503768465595321590690311221269514682222687386378631457535068
        446135118173
    Y: 53219402718535721212460981200104434180077825188675868294070079
        5084662920552823356888138706016038637934794839496624474125511
        419755284720
    Encoded Public
  43 61 20 A0  B1 DF AA BD  6B 55 00 97  A3 BE CB B8
  09 57 20 88  16 69 E4 B9  E1 7E 9C 13  C0 41 5B CB
  4D 3E E4 99  2E 2D 48 89  1C C0 FB 26  58 C2 DD 5C
  C1 DC 17 82  D7 A0 43 EE  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 = 5089046065641972153127358795828409601581098276054157542072680505
    39683337837216003977228732536078674802149039736292653681850024283
    019712
a1 = 8176364036263260978124518440703915999792418973860004542252802998
    84194581658067779192269206677888489486997873906818021287228059824
    83024

The key share values for the participants are

xa = 1
ya = 4553920370512465718198820807387671939080299682852725441867843114
    26647841184040247478683873287903958609179459996994688962515626865
    53399

xb = 2
yb = 1273028440677572669632333924809158793887271865671272998412064611
    31084242284210802667095307996579244809617733390381271024974368669
    036423

xc = 3
yc = 2735680335648815410714762491595390579824103613389783019336194132
    43576964884779948701264733726757177950072270719714108489234187918
    69668

Alice and Carol are selected to sign the message "This is another test"

The Lagrange coefficients are:

la = 9085484053695086131866547598600056679420517008591475753518627489
    75730019807697928580978776458461879816551468545458311523868779298
    24891
lc = 9085484053695086131866547598600056679420517008591475753518627489
    75730019807697928580978776458461879816551468545458311523868779298
    24889

Alice and Carol select their values ra, rc

ra = 1406020955597999230792020434504725588018212159057738301447013526
    92279040495252484937852810444924482680594152694241752895011658904
    370203
Ra =
  6A B9 49 CA  C0 02 64 DA  7B 1F 8A D4  DA 60 C2 90
  82 6C 6D E7  A3 86 9A 7C  5A 7E BF 40  36 A9 9B 1B
  93 10 63 FE  78 66 AC 25  D7 7A 39 F6  AA D4 9A 7F
  0A B7 0F 74  1F 71 C5 82  00

rc = 1657160535446222712418185017637185228755988992580148926426850137
    95902852868485411394534732568482310440218957473271958755451433805
    499840
Rc =
  D8 60 C2 5E  80 7C 2F 72  9F CB 44 A5  8F 0E C5 21
  0E 3B 8F 2B  45 FE F4 EA  82 10 A1 BC  0F 76 B2 F7
  C9 FA F4 6C  FB DC A2 E3  30 1E 32 60  B5 C3 14 21
  B8 64 17 53  AD 69 CF 78  00

The composite value R = Ra + Rc

R =
  69 61 D0 FE  4A 16 2A C5  27 A2 43 8A  3B C8 FD 74
  E7 5E 59 F3  BA 81 2C 19  C7 1A 06 D3  B1 67 23 56
  20 D5 47 B5  B7 29 32 C3  2A 46 B3 FE  69 F1 0F 68
  B4 96 1D 17  62 28 4F 85  00

The value k is

k = 69669457160685458826819431046668880610248418313436871579951643706
    87428998653334157671223922229268032785360988536670152839567146484
    0010

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 = 1591636460946378470916477880968156458804096653287056391632039216
    11570178158375829979900458639031781773032065854095034496764221959
    654988;
sc = 1680312793956576455837571395140241806892898221048805999736915791
    32967155717300588281132518605354517065806680173105956880312046463
    714945

The signature contributions can now be calulated:

Sa = 9928219157021149797850638214827218628611422799637875708448381284
    73183695639473962863821812127819770907733759351605911566901954334
    93947
Sc = 6640358383958298095120552660187311644053796876752842670539038404
    09627584460022216403829061328436171105691165755548848346660523435
    12296

The dealer calculates the composite value S = Sa + Sb

S =  1656857754097944789297119087501453027266521967639071837898741968
    88281128009949617926765087345625594201342492510715475991356247777
    006243

The dealer checks to see that the signature verifies:

S.B = R + kA =
    X: 30591501150335992421374326582040572679060605290754973521167789
        337999057647193
    Y: 89954215422050636822521538137029911178152388194062857884972047
        91173545074494

7. Security Considerations

All the security considerations of [RFC7748], [RFC8032] and [draft-hallambaker-threshold] apply and are hereby incorporated by reference.

7.1. Rogue Key attack

The rogue key attack described in [draft-hallambaker-threshold] 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 ri 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 ri 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 ri to avoid reuse for different values of Ri. 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

[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-09, , <https://tools.ietf.org/html/draft-hallambaker-mesh-udf-09>.
[draft-hallambaker-threshold]
Hallam-Baker, P., "Threshold Modes in Elliptic Curves", Work in Progress, Internet-Draft, draft-hallambaker-threshold-02, , <https://tools.ietf.org/html/draft-hallambaker-threshold-02>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.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.rfc-editor.org/rfc/rfc4086>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/rfc/rfc8032>.

11. Informative References

[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft-hallambaker-mesh-developer-09, , <https://tools.ietf.org/html/draft-hallambaker-mesh-developer-09>.
[Komlo]
Komlo, C. and I. Goldberg, "FROST: Flexible Round-Optimized 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.rfc-editor.org/rfc/rfc5860>.
[Shamir79]
Shamir, A., "How to share a secret.", .