SHINE: Resilience via Practical Interoperability of Multi-party Schnorr

Signature Schemes

Antonin Dufka

, Vladimir Sedlacek

1,2

and Petr Svenda

Masaryk University, Czech Republic

Universit

e de Picardie Jules Verne, France

ﬁ

Keywords:

Cryptographic Hardware, Multi-party Computation, Nonce Agreement, Schnorr Signatures, Interoperability.

Abstract:

Secure multi-party cryptographic protocols divide the secret key among multiple devices and never reconstruct

it in a single place. Such a mechanism protects against malware, code vulnerabilities, and backdoors when

different implementations and devices are used. Still, a protocol-level issue may result in a compromise, and

up until now, it has been unknown how to combine different unmodiﬁed multi-party protocols.

We study the interoperability of different multi-party Schnorr signature schemes and classify them based on

their approach to the nonce agreement. We identify issues that could hinder in-class interoperability, and we

propose a trustless mediator that facilitates interoperability among different classes in certain cases. Besides

mitigating the risks, interoperability provides usability and performance beneﬁts, as protocols better suited for

special devices can be used together with more general protocols.

We make use of these advantages in our new multi-signature scheme SHINE, which is optimized for resource-

limited devices like cryptographic smartcards while being interoperable with popular schemes such as MSDL,

MuSig2, or Sp eedyMuSig.

1 INTRODUCTION

Since the expiry of Schnorr’s patent (Schnorr, 1991b),

Schnorr signatures are making a considerable come-

back, fueling digital signature speciﬁcations like Ed-

DSA (Bernstein et al., 2012) and BIP-Schnorr (Wuille

et al., 2020a). EdDSA is being gradually incorporated

in many protocols like TLS, SSH, Tor, and WireGuard

(IANIX, 2022), and BIP-Schnorr is now being used

in Bitcoin (Nakamoto, 2008) as a part of the Taproot

consensus upgrade (Wuille et al., 2020b).

The practical problems these applications face

have reignited research interest in the area of multi-

party Schnorr signatures. New schemes (Alper and

Burdges, 2021; Maxwell et al., 2019; Nick et al.,

2021; Syta et al., 2016; Crites et al., 2021) im-

proved the practicality of Schnorr multi-signatures,

e.g., decreased communication and achieved security

in the plain public-key model. However, none of the

schemes is suitable for all scenarios, and their ap-

proaches often differ in technical or design details,

rendering them partly or fully incompatible. This re-

sults in having multiple protocols that perform in prin-

ciple the same task yet cannot work together.

Good protocol interoperability would improve not

only usability and performance but also security. A

frequent weak point of any real-world cryptographic

system is its implementation. Multi-party computa-

tion can mitigate the impact of implementation vul-

nerabilities by having different implementations run-

ning on different devices, as long as at least one of

them remains secure (Mavroudis et al., 2017). Multi-

party scheme interoperability extends this idea fur-

ther: choosing different protocols limits the threat of

common implementation errors in all of them at once.

Unfortunately, it is unknown if and how we can

achieve interoperability of different Schnorr-based

multi-party schemes. To tackle this problem, we

study the scheme differences and classify them by

their approach to the nonce agreement – a key compo-

nent in signature computation. This allows us to in-

vestigate possible interoperability across classes and

identify obstacles to in-class interoperability. We dis-

cover that cross-class interoperability can be in cer-

tain cases achieved via an untrusted mediator that

translates communication among different protocols.

Based on these new insights, we design a new

multi-signature scheme, SHINE, which is interoper-

able with several other Schnorr-based schemes and is

optimized for computationally limited devices.

Dufka, A., Sedlacek, V. and Svenda, P.

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes.

DOI: 10.5220/0011145600003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 305-316

ISBN: 978-989-758-590-6; ISSN: 2184-7711

305

Main Contributions:

• We classify the current Schnorr-based multi-party

schemes by their approach to the nonce agree-

ment, and propose an untrusted mediation layer

that bridges class differences to achieve interoper-

ability.

• We design a two-round (one-round plus precom-

putation) Schnorr multi-signature scheme called

SHINE, which targets computationally limited de-

vices like smartcards, and is interoperable with

many pre-existing schemes. The scheme features

a novel approach to nonce caching that avoids the

previous attack on two-round schemes (Drijvers

et al., 2019).

• We provide an open-source implementation of

SHINE on the JavaCard platform, evaluate its per-

formance on ﬁve different smartcard models, and

demonstrate its interoperability with other scheme

classes via the proposed mediator.

After presenting the relevant background in Section 2,

we survey and compare different approaches to the

nonce agreement in Section 3. Building upon the

lessons learned, we propose our scheme SHINE in

Section 4 and draw conclusions in Section 5.

2 BACKGROUND

This section introduces the notation, recalls Schnorr

signatures, and presents relevant multi-party schemes.

2.1 Notation

A group description is a triplet (G,q,G), where q is

a λ-bit prime, G is a cyclic group of order q, and G

is a selected generator of G. We use the additive no-

tation for the group operation and denote group ele-

ments in upper-case. Conversely, we use lower-case

to denote elements of Z

. Sampling of an element e

from non-empty set S is denoted as e ← S. By A (x),

we denote the set of outputs of probabilistic algorithm

A given input x. We reserve n for the number of sign-

ing parties. Furthermore, with a secret s, we use the

following notation:

• PRF

– a pseudorandom function seeded with s;

• KDF

– a key derivation function seeded with s;

• Enc

– symmetric encryption with a key s;

• Dec

– symmetric decryption with a key s;

• Com – a commitment function.

2.2 Schnorr Signatures

The Schnorr signature scheme (Schnorr, 1991a) is de-

rived from the Schnorr identiﬁcation scheme using

the Fiat-Shamir transform (Fiat and Shamir, 1986),

and it relies on the hardness of the discrete loga-

rithm problem. The scheme outputs efﬁciently com-

putable and veriﬁable signatures of short length. It

has been proven existentially unforgeable under the

chosen message attack in the random oracle model

(Pointcheval and Stern, 2000). Various formulations

of Schnorr signature schemes have been proposed,

but in this paper, we choose the one typically used

in recent works (Bernstein et al., 2012; Wuille et al.,

2020a), as it supports efﬁcient batch veriﬁcation and

prevents related-key attacks (Morita et al., 2015).

Deﬁnition 2.1 (Schnorr Signature). Let (G,q,G) be

a group description and H : G

× Z

→ Z

be a

hash function. A Schnorr signature of a message

m ∈ Z

veriﬁable with public key X ∈ G is a pair

(R,s) ∈ G × Z

satisfying the veriﬁcation equation

sG = R + H(R,X,m)X.

For a random nonce r ∈ Z

and a private key x ∈

such that xG = X, a valid Schnorr signature of a

message m is (R,s) = (rG,r + H(R,X , m)x).

For ﬁxed H(R,X,m), the signing equation is lin-

ear, which is useful for efﬁcient multi-party Schnorr

signature schemes. First, all n parties need to agree on

a collective nonce R, which is a linear combination of

their individual contributions R

= r

G. Subsequently,

they produce signature shares s

= r

+ H(R,X, m)x

which are summed up to obtain the resulting signature

s =

∑

i=1

, veriﬁable under the aggregate public key

X =

∑

i=1

The simple multi-signature scheme described in

the previous paragraph has a few caveats, which cause

it to be insecure in many use-cases, and these issues

are addressed by more complex designs. The two

main security obstacles are related to the group key

aggregation and the nonce agreement, both of which

can be attacked to perform a forgery.

The key aggregation is prone to rogue-key attacks,

where the adversary computes her key as a function of

the public keys of other parties and cancels out their

contribution. To illustrate the problem, assume the

attacker is the ﬁrst party. She can compute her key

as X

= x

′

G −

∑

i=2

for some x

′

∈ Z

. When this

rogue key is combined with the other keys, the result-

ing aggregate key is X = x

′

G, and the attacker can

create signatures on behalf of the group.

Rogue-key attacks can be prevented by distributed

key generation, which requires fresh key pairs like in

Myst (Mavroudis et al., 2017). Alternatively, pre-

existing keys can be reused when supplemented by

SECRYPT 2022 - 19th International Conference on Security and Cryptography

306

proof of knowledge of their private key, e.g., (Boneh

et al., 2018). Another method that supports key reuse

is the non-interactive key aggregation method pre-

sented in MuSig (Maxwell et al., 2019), which avoids

the attack by unpredictably altering the aggregate key

whenever any of the inputs changes.

If sequential signing can be enforced, the protocol

is secure, and the aggregate nonce does not even need

to be computed by the signer, as is the case in CoSi

(Syta et al., 2016). However, if the signing instances

with the same key can be executed concurrently (e.g.,

nonce contributions are shared in advance), the Dri-

jvers et al.’s attack can achieve signature forgery (Dri-

jvers et al., 2019). The attack relies on solving an

instance of the ROS problem (Schnorr, 2001), which

can be solved in subexponential (Wagner, 2002) or

polynomial time (Benhamouda et al., 2021), depend-

ing on the number of concurrent sessions.

2.3 Current Multi-party Schemes

In this subsection, we list and shortly describe all re-

cent Schnorr-based multi-party schemes that we con-

sider for the interoperability study.

CoSi (Syta et al., 2016) is a two-round Schnorr-

based multi-signature scheme designed for high-

speed signing by many parties organized into a tree

structure. The scheme has been proven secure only

for logarithmically many concurrent signing instances

in a later work (Drijvers et al., 2019).

Myst (Mavroudis et al., 2017) is a setup of a

large number of smartcards interconnected into a

grid performing multi-party computations to achieve

high guarantees of backdoor tolerance. Myst uses

a multi-signature scheme similar to CoSi, optimized

for limited devices. One of the optimizations (nonce

caching) was found vulnerable to an attack by Dri-

jvers et al. (Drijvers et al., 2019).

MuSig (Maxwell et al., 2019) was originally pre-

sented as a two-round scheme that was later found

vulnerable by Drijvers et al. (Drijvers et al., 2019).

Earlier MSDL (Boneh et al., 2018) used a preliminary

commitment round that avoided the problem, and the

same approach was also adopted to MuSig, resulting

in a three-round concurrently-secure scheme.

The ﬁrst concurrently-secure two-round multi-

signature scheme resulting in standard Schnorr signa-

tures was MuSig-DN (Nick et al., 2020), which avoids

the Drijvers et al.’s attack by generating the nonce de-

terministically. The nonce needs to be supplemented

with costly non-interactive zero-knowledge proofs of

its correct construction to achieve security.

MuSig2 (Nick et al., 2021) and DWMS (Alper and

Burdges, 2021) made advances in secure two-round

multi-signature schemes with unlimited concurrency

and, independently of each other, introduced a tech-

nique preventing the Drijvers et al.’s attack. This

approach is much more efﬁcient than deterministic

nonce derivation with zero-knowledge proofs but it

still presents a signiﬁcant computation overhead, lim-

iting its usefulness for constrained devices.

Crites et al. (Crites et al., 2021) combined

MuSig2 with proofs of possession similar to MSDL

to construct the latest Schnorr-based scheme called

SpeedyMuSig. This combination brings faster key

aggregation to the MuSig2 scheme, resulting in the

fastest two-round concurrently-secure Schnorr multi-

signature scheme.

FROST (Komlo and Goldberg, 2021) is a thresh-

old signature scheme that is secure for an arbitrary

threshold t ≤ n and, as such, provides great ﬂexibil-

ity to its applications. Its original version was also

vulnerable to the Drijvers et al.’s attack, but a later

version employed a variation of the technique used in

MuSig2 (Nick et al., 2021) and DWMS (Alper and

Burdges, 2021) to avoid the issue.

Garillot et al. (Garillot et al., 2021) presented

another deterministic scheme secure in the dishon-

est majority setting that has the beneﬁt of not re-

quiring additional randomness nor state. Its con-

struction is conceptually similar to the MuSig-DN

scheme, as it uses deterministic nonce derivation sup-

plemented by non-interactive zero-knowledge proofs.

The computation of the proof is more efﬁcient than in

MuSig-DN, but the proof size and thus communica-

tion requirements were signiﬁcantly increased.

3 INTEROPERABILITY OF

SCHNORR-BASED SCHEMES

The Schnorr-based schemes mentioned in Section 2.3

exhibit different trade-offs. Some schemes are opti-

mized for a low number of communication rounds;

others are better suited for limited devices where the

computation is costly; some use only standard op-

erations available on legacy systems or can utilize

dedicated co-processors, and some need to use non-

standard cryptographic primitives. As a result, none

of the schemes is ideally suitable for all platforms.

In this section, we attempt to address the prob-

lem of scheme heterogeneity. We surveyed current

multi-party Schnorr signature designs and classiﬁed

them based on their approach to the nonce agreement.

With this classiﬁcation, we specify what is required

of the schemes from the same class to be compati-

ble with each other. Furthermore, we inspect the dif-

ferences among the classes and bridge them using an

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes

307

untrusted third party without any changes to the un-

derlying schemes. If this mediation is possible, we

call the schemes interoperable.

More precisely, we deﬁne interoperability as the

ability of two or more multi-party protocols to execute

jointly via an untrusted mediator in a way that results

in a valid signature on behalf of all of the parties and

none of the parties can distinguish such an execution

from the execution with its own instances.

With this deﬁnition, the security of interoper-

ability can be reduced to the security of individual

schemes. Since all of the considered schemes were

proven secure in the dishonest majority setting, their

security does not rely on the actions of other partici-

pants. In particular, the mediator can be considered as

the adversary in the security proofs of the schemes.

Nonce Agreement. The method of nonce agree-

ment is the main part in computing multi-party

Schnorr signatures. All signing parties need to

contribute to the nonce agreement with their fresh

nonce, which they later reﬂect in signing. After the

nonce is known, the signatures can be computed non-

interactively.

We have identiﬁed four main approaches to the

nonce agreement: 1) nonce exchange, 2) nonce com-

mitment, 3) nonce delinearization, and 4) determin-

istic nonce derivation. These methods differ in

the number of communication rounds, computational

complexity, and security assumptions. In the follow-

ing subsections, we analyze the approaches and de-

scribe the mediator for each interoperable approach.

3.1 Nonce Exchange

Nonce exchange (NE) features two communication

rounds and is the simplest and most efﬁcient approach

to nonce agreement. It is used by applications focus-

ing on high performance (Syta et al., 2016; Mavroudis

et al., 2017), which utilize that its security does not

rely on a speciﬁc construction of the aggregate nonce.

Thus the signers do not even have to compute the ag-

gregate nonce themselves, allowing further decrease

of the computation requirements.

The disadvantage of this approach is that it is se-

cure only when executed sequentially, i.e., no concur-

rent signing sessions occur

. Otherwise, a practical

message forgery can be achieved by the Drijvers et

al.’s attack (Drijvers et al., 2019).

Or more precisely, only a logarithmic number of con-

current sessions occur.

Principle. Each signer i uniformly samples a ran-

dom nonce r

← Z

, computes the corresponding el-

ement R

= r

G, and transmits this element. The ele-

ments of all signers are then summed up into the ag-

gregate nonce R =

∑

i=1

used in the signing.

Interoperability. Since there are no constraints on

the construction of the aggregate nonce, NE schemes

are convenient for achieving interoperability with

other nonce agreement approaches that are more re-

strictive but concurrently-secure.

3.2 Nonce Commitment

Nonce commitment (NC) is a three-round approach

that has been used by MSDL (Boneh et al., 2018) and

MuSig (Maxwell et al., 2019). It provides concur-

rent security with only a minimal computation over-

head over NE. If the additional communication round

is not too costly, e.g., the devices are co-located,

this approach is also quite efﬁcient and suitable for

computationally-limited devices.

Principle. The Drijvers et al.’s attack requires the

attacker to be able to choose their nonce depending

on the nonces of other parties

. This precondition can

be broken by a preliminary communication round, in

which each signer i ﬁrst outputs a commitment to

its nonce element Com(R

), and only after receiving

commitments of all other parties reveals the nonce el-

ement R

. The provided nonce elements need to be

veriﬁed against the commitments, and if an inconsis-

tency is discovered, the protocol must be aborted.

Interoperability. The need for commitment limits

interoperability among different instances of NC. To

be able to work together, the schemes have to use the

same Com function, which is a consequence of the

commitment properties, preventing the commitment

from being readjusted by a third party.

Nonetheless, NC is interoperable with NE-based

schemes via a translation layer that simulates the

commitment round on behalf of the NE schemes as

follows (see Figure 1): First, the NE schemes share

their R

. The translation layer computes commitments

for these elements with an appropriate Com func-

tion and simulates the commitment round with NC

schemes. Afterward, the NC schemes and the trans-

lation layer (on behalf of NE schemes) reveal R

that

successfully verify against the commitments. Hence

no party aborts and they all arrive at the same aggre-

gate nonce.

Assuming other parts of the input are already ﬁxed.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

308

Figure 1: Interoperability mediation between NC and NE schemes (left), and half-ND and NE schemes (right).

3.3 Nonce Delinearization

Nonce delinearization (ND) is the most recent ap-

proach to the nonce agreement that is secure under

concurrent execution with just two communication

rounds, the ﬁrst of which can be precomputed. The

main downside of this approach is its high computa-

tional cost, as it requires each signer to generate mul-

tiple nonces and to perform multi-scalar multiplica-

tion in the second round. Nonetheless, the practical

beneﬁts in many applications outweigh the cost, and

this technique has been used in the design of the latest

schemes (Alper and Burdges, 2021; Komlo and Gold-

berg, 2021; Nick et al., 2021; Crites et al., 2021).

Principle. Each signer i uniformly samples ν

nonces r

i, j

and reveals the corresponding elements

i, j

= r

i, j

G (possibly in advance). When the message

to be signed is known, the nonce elements are used to

compute the aggregate nonce

R =

∑

i=1

∑

j=1

i, j

where β

i, j

are delinearization coefﬁcients. The delin-

earization coefﬁcients are non-linearly dependent on

all nonce elements and the message via a hash func-

tion, which causes the aggregate nonce to change un-

predictably whenever any of the inputs changes, and

thus thwarts the Drijvers et al.’s attack.

Interoperability. The requirement of speciﬁc

nonce aggregation based on pre-shared nonce ele-

ments and the message limits the interoperability

with other instances of ND schemes, as the same co-

efﬁcients β

i, j

and ν would need to be used. Schemes

using, e.g., a different hash function in the coefﬁcient

computation, do not arrive at the same aggregate

nonce.

Interoperability with NE schemes is a bit more nu-

anced and cannot be achieved in general. Equations

(1) and (2) show a signature by an NE scheme and an

ND scheme, respectively (ν = 2 for brevity).

s = r

+ ex

(1)

s = β

i,1

+ β

i,2

+ ex

(2)

The mediator cannot reconcile the difference between

(1) and (2) because it cannot multiply the nonce r

without also changing the ex

component. However,

if β

i,1

= 1, the interoperability is achievable via the

following mediation (see Figure 1).

First, all signers begin by sharing their nonce el-

ements. The single nonce element provided by NE

schemes is used as their ﬁrst nonce element, and the

mediator computes the other nonce elements instead

of the signers. These simulated nonce elements can be

sent to ND-based signers, who can now compute the

aggregate nonce. The aggregate nonce R is also com-

puted by the mediator who provides it to NE-based

signers, which reply with their signatures s

= r

+ex

The mediator then augments the signatures by the

simulated nonces s

+ β

i,2

+ ··· + β

i,ν

, making

them compatible with signatures of ND schemes. Fi-

nally, the signatures can be combined into a valid sig-

nature without any change of the underlying schemes.

Having β

i,1

= 1 has been suggested as an opti-

mization of MuSig2 (Nick et al., 2021) that became

the default choice in a later revision of the scheme

and was since then adopted by other works (Komlo

and Goldberg, 2021; Crites et al., 2021). We call this

variation, where the ﬁrst nonce is not multiplied by

the coefﬁcient, half-nonce delinearization. This vari-

ant is not a mere performance optimization (as pre-

sented in the original paper), but importantly, it also

enables interoperability with NE schemes, as illus-

trated above. For this reason, we suggest preferring

the designs of schemes with half-ND. This choice still

allows for adding arbitrarily many nonces to tweak

the problem

while remaining interoperable with NE

schemes and incurring no additional cost to them.

Achieving interoperability is not possible with NC

schemes, as those schemes need to receive a commit-

A MuSig2 variant suggested four nonces.

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes

309

ment to the single nonce produced by each party be-

fore revealing their own nonce, but ND schemes use

multiple nonces and cannot combine them before all

other nonces are known.

3.4 Deterministic Nonce

Deterministic nonce (DN) derivation is another ap-

proach to concurrently-secure two-round scheme con-

struction. DN derivation has been used in standard

signature schemes, preventing attacks due to biased

randomness in the nonce generation. However, it can-

not be directly applied to a multi-party setting as a

malicious party that diverges from the correct compu-

tation could force an honest signer to reuse a nonce,

which would result in a key compromise. To deal

with this problem, MuSig-DN (Nick et al., 2020) and

a scheme by Garrilot et al. (Garillot et al., 2021)

use non-interactive zero-knowledge proofs. The dis-

advantage of this approach is its computational cost,

which is the highest among the presented approaches.

Principle. Each signer derives its nonce using a de-

terministic approach and computes a non-interactive

zero-knowledge proof of its correct construction. The

proof is output along with the nonce element, and

other protocol participants need to verify the proof.

If the veriﬁcation fails, the signing must be aborted.

Interoperability. The need for a zero-knowledge

proof severely limits the interoperability of the

scheme. Different implementations of DN schemes

require a consensus on the used derivation function

and the proof construction to work together. Interop-

erability with schemes using a different approach to

the nonce agreement is not possible, as it contradicts

the requirement of deterministic nonce derivation.

3.5 Summary

Table 1 displays the interoperability matrix of the

nonce agreement approaches. Schemes based on NE

stand out among others as the most ﬂexible ones due

to their ability to accept an externally provided nonce

without any knowledge of its construction and remain

secure with a sequential execution. Interactions of NE

and ND schemes are interoperable when the half-ND

method is used. Even though NE schemes are interop-

erable with NC schemes and half-ND schemes sepa-

rately, they cannot be used together since NC schemes

and ND schemes are not interoperable. DN is inter-

operable only with its own instances.

Based on the study of interoperability, we propose

to focus on three designs of Schnorr-based schemes:

Table 1: Interoperability of nonce agreement approaches.

The icons ✓, ✗, and ∼

∼

∼, denotes possible interoperability

always, never and under certain preconditions, respectively.

NE NC ND DN

NE ✓ ✓ ∼

∼

∼ ✗

NC ✓ ∼

∼

∼ ✗ ✗

ND ∼

∼

∼ ✗ ∼

∼

∼ ✗

DN ✗ ✗ ✗ ∼

∼

1. The sequentially constrained NE schemes for

computationally restricted devices, which beneﬁt

the most from the efﬁciency;

2. the half-ND schemes for devices where the com-

putation is not a limiting factor, and that could

beneﬁt from interoperability;

3. the DN schemes for the cases where the perfor-

mance is not an issue, determinism is crucial, and

a setup of homogenous instances is guaranteed.

We followed up on our ﬁrst recommendation and

used NE to design SHINE, a multi-signature scheme

optimized for cryptographic smartcards and similar

resource-constrained devices, which is interoperable

with other nonce agreement approaches. We present

the design in the next section.

Lastly, it remains to comment that the theoretical

interoperability does not automatically imply interop-

erability of corresponding implementations. For that,

the implementations need to use compatible group

key aggregation and produce compatible signatures

– not only Schnorr signatures but the same instance

of Schnorr signatures, e.g., Ed25519 (Bernstein et al.,

2012) or BIP-Schnorr (Wuille et al., 2020a).

4 MULTI-SIGNATURE SCHEME

SHINE

This section describes SHINE (Smartcard Highly-

Interoperable Nonce Encryption scheme) – a multi-

signature scheme optimized for computations on

cryptographic smartcards while being interopera-

ble with many pre-existing Schnorr multi-signature

schemes. The design includes a central party that me-

diates communication among individual signers. We

utilize this central party for the precomputation of in-

puts, data storage, and also for achieving interoper-

ability, as described in the previous section.

SHINE can create a signature in two communica-

tion rounds, the ﬁrst of which can be securely precom-

puted. The scheme uses a variant of NE that enables

interoperability with all classes except DN. But it also

requires sequential execution to be secure, which we

SECRYPT 2022 - 19th International Conference on Security and Cryptography

310

enforce by design. Additionally, to avoid random-

ness generation failure attacks and minimize storage

requirements, we derive nonce using a secret pseudo-

random function that depends on an internal counter.

Security proof is provided in the Appendix.

In the following subsections, we describe the at-

tacker model and the group establishment of SHINE.

Next, we introduce the technique of nonce caching

with encryption and discuss its differences from plain

nonce caching. Finally, in Section 4.4 we describe the

signing protocol. The last subsection presents an im-

plementation of SHINE on cryptographic smartcards

and an evaluation of its performance.

4.1 Attacker Model

We assume that the attacker is able to control the cen-

tral party and n − 1 of the signing parties. Since the

central party is under the control of the attacker, it can

drop or alter messages, and as a result, cause a denial

of service. We also make the standard assumptions

that the number of computation steps the attacker can

make is bound by a polynomial and that a variant of

the discrete logarithm problem is hard.

4.2 Group Establishment

Before SHINE can be used to sign messages, the sign-

ing group needs to be established. The signing group

consists of a set of signers, who generate their private

key shares, compute the group key, and initialize con-

text information. In this process, we assume that the

central party included all participants in the key ag-

gregation, i.e., did not ignore or simulate messages by

some parties. In practice, the validity of this assump-

tion can be later veriﬁed by querying participants for

their key contributions by secondary channels.

SHINE can use different key aggregation ap-

proaches depending on which schemes it should be

interoperable with. As the default option, we have

selected proofs of possession like in (Crites et al.,

2021), as it allows efﬁcient group key aggregation and

low communication. Alternatively, MuSig key aggre-

gation (Maxwell et al., 2019) or some form of dis-

tributed key generation can be used instead.

After a new group key is successfully computed,

each party i ﬁnalizes the group establishment process

by initializing its signing context. The signing con-

text consist of a λ-bit secret p

that is used for deter-

ministic nonce and encryption key derivation, and an

increase-only counter c

that tracks the index of the

most recently used nonce. The former value is uni-

formly sampled, and the latter is initially set to zero.

These values are later used in the signing protocol.

4.3 Nonce Caching with Encryption

Nonce caching is a technique used in Myst

(Mavroudis et al., 2017) for a setup of smartcards. It

optimizes the signing speed by generating nonces in

advance, computing the corresponding elements, and

storing them at a server. Thus the costly scalar mul-

tiplication can be performed during downtime when

there are no signing requests, and the precomputed

nonce can be provided to signers when needed.

This approach was later shown to be vulnerable

to the Drijvers et al.’s attack (Drijvers et al., 2019).

Since the properties of nonce caching are beneﬁcial

for resource-limited devices like smartcards, we de-

signed a technique called nonce caching with en-

cryption or nonce encryption for short, which avoids

the Drijvers et al.’s attack and still allows for nonce

caching with some restrictions.

The vulnerability to the Drijvers et al.’s attack oc-

curs only if the scheme is used concurrently, e.g., an

adversary can open multiple signing sessions in par-

allel or cache multiple nonces before they are used

for signing. Nonce encryption leverages this property

and enforces sequential execution to ensure at most a

single cached nonce is revealed at a time while still

being usable for signing.

Nonce encryption consists of two phases – Cache

(Figure 2) and Reveal (Figure 3). The smartcard com-

putes the nonce element during the caching phase and

sends it encrypted

using a fresh key to the central

party. The reveal phase is then used to reveal the cor-

responding decryption key and thus reveal the cached

nonce while invalidating previous nonces.

The Cache phase is initiated by the central party,

which sends a signing instance identiﬁer j. The

smartcard i uses a pseudorandom function, keyed

with a secret p

(generated during the group estab-

lishment), to derive a nonce r

i, j

corresponding to the

signing instance j. Then the smartcard computes

i, j

← r

i, j

G, the demanding operation that would be

the bottleneck during the signing.

In the standard nonce caching, R

i, j

would be sim-

ply transmitted to the central party; however, if this

step was repeated, it would lead to the vulnerability

to the Drijvers et al.’s attack. With nonce encryption,

the nonce is not transmitted in plaintext but rather en-

crypted with symmetric key k

i, j

derived from the sign-

ing instance identiﬁer j using a key derivation func-

tion known only to the signer i. The central party

stores the received value for future use.

We use encryption only to securely store the cached el-

ement on the central party to minimize storage requirements

on the signing device (as memory on smartcards is limited).

We do not want the signer to bind to the encrypted value.

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes

311

Algorithm 1: Cache

Input: Session index j

Output: Encrypted nonce E

i, j

← PRF

( j)

i, j

← r

i, j

← KDF

( j)

i, j

← Enc

i, j

)

return E

i, j

Figure 2: SHINE nonce caching algorithm.

Algorithm 2: Reveal

Input: Session index j

Output: Decryption key k

i, j

if j ≥ c

then c

← j ﬁ

i, j

← KDF

)

return k

i, j

Figure 3: SHINE nonce revealing algorithm.

The Reveal phase uses the smartcard internal

increase-only counter c

to track which nonce ele-

ments were already revealed. When prompted by the

central party to send k

i, j

for a signing instance j ≥ c

the smartcard derives k

i, j

and sends it back, but at the

same time increases its inner counter c

← j. With the

knowledge of k

i, j

, the central party can decrypt the

cached nonce R

i, j

, possibly combine it with nonces of

other parties, and use it in a subsequent signing.

So far, the counter c

did not limit the attacker in

any way. It plays a role only during the signing, where

the smartcard must not produce a signature for a sign-

ing instance j < c

. This restriction ensures that only

the signing instance j = c

can succeed since nonces

for j > c

are not known yet. The technique already

enforces the signing of non-decreasing sequences,

and it only remains to avoid nonce reuse, which is

achieved by incrementing the internal counter c

when

producing a signature.

Comparison to Plain Nonce Caching

Just as in plain nonce caching, we manage to avoid

costly group operations during the signing. In this

subsection, we highlight the differences.

Storage-wise, nonce encryption still requires only

constant memory on smartcards, but the central party

cannot pre-aggregate nonces anymore as only a sin-

gle nonce is known at a time. Therefore, the space

required by the central party grows linearly in n.

Communication-wise, nonce encryption seem-

ingly needs one additional round to transmit the de-

cryption key. However, this transmission can be au-

Algorithm 3: Sign

Input: Aggregate nonce R

, message m,

session index j

Output: Partial signature s

i, j

if j < c

then abort ﬁ

← j + 1

i, j

← PRF

( j)

i, j

← r

i, j

+ H(R

,X, m)x

return s

i, j

Figure 4: SHINE signing algorithm.

tomatically piggybacked with the previous signing,

where the decryption key for c

+ 1 can be revealed,

as c

was already invalidated. As a result, the number

of communication rounds can remain the same; only

the additional decryption key is transmitted.

Finally, computation-wise, symmetric encryption

can be realized efﬁciently, minimizing the additional

demands on the smartcards. The only new concern is

the aggregate nonce computation by the central party

– which cannot be precomputed, as only a single de-

cryption key is known at a time. In the case of burst

signing requests, the overall solution would result in

a performance decrease compared to the vulnerable

nonce caching. But assuming the central party is sig-

niﬁcantly more capable than the smartcards (which in

practice is), the aggregation can be performed rela-

tively quickly and is not a limiting factor.

4.4 Signing Protocol

Figure 4 shows the signing algorithm. The central

party initiates the signing of a message m by com-

puting the aggregate nonce. If it already has all ap-

propriate decryption keys, it sums the cached nonces

as R

∑

i=1

i, j

. Otherwise, the central party might

need to exchange an additional Cache or Reveal mes-

sage with some smartcard(s) prior to the aggregation.

When the aggregate nonce is computed, the central

party sends a signature request to every participating

smartcard with the given signing index j, the aggre-

gate nonce R

, and the message m.

When a smartcard receives a signing request, it

ﬁrst checks whether the signing index is greater or

equal to its internal counter. If not, it aborts the

protocol. Otherwise, the smartcard sets its internal

counter c

← j + 1 and continues with the signing.

It derives its nonce r

i, j

and computes its signature

i, j

← r

i, j

+ H(R

,X, m)x

, which it outputs. Option-

ally, the decryption key for index j +1 can be revealed

together with the signature. Finally, the central party

sums the signatures to obtain the resulting (R

SECRYPT 2022 - 19th International Conference on Security and Cryptography

312

4.5 Implementation and Evaluation

We implemented SHINE for the JavaCard platform

using a modiﬁed version of the JCMathLib library

(Mavroudis and Svenda, 2020) that provides the nec-

essary low-level operations without relying on propri-

etary smartcard API and thus enables our results to be

reproduced on a wide variety of supported smartcards.

While the solution achieves a decent speed with JC-

MathLib, using proprietary API calls would signiﬁ-

cantly increase its performance in practice, especially

for nonce computation and caching operations.

We tested and evaluated our implementation on

ﬁve JavaCards: (1) NXP J2E145G, (2) NXP J3H145,

(3) GD SmartCafe 6.0, (4) GD SmartCafe 7.0,

and (5) NXP J3R180. We measured the time required

to compute each phase of the protocol and also their

counterparts in a variant without nonce caching so

that we would be able to assess its impact. We re-

peated each measurement 100 times and averaged the

results. Table 2 presents a summary of the results.

The implementation achieves an average signing

speed of around 700 ms, comparable to the perfor-

mance of the Myst implementation from (Mavroudis

et al., 2017). The signing slowdown caused by key

derivation for piggybacking did not exceed 45 ms for

any of the cards and thus increased signing latency by

6% at most. Encryption operation added to the nonce

caching resulted in less than 36 ms slowdown, which

was at most 23% (but mostly only 1%) of the time

required to perform the nonce computation.

The differences in time required to compute

the nonce are caused by different native algo-

rithm support. JavaCards (2) and (5) supported

ALG EC SVDP DH PLAIN XY algorithm, which made

the nonce computation quite close to the native per-

Table 2: Time (ms) required to compute steps of SHINE on

different JavaCards.

(1) (2) (3) (4) (5)

Compute 2826 194 2764 1962 60

+ Cache 2854 217 2801 1984 74

Overhead 28 24 36 23 14

(%) 1 12 1 1 23

Sign 802 737 768 637 457

+ Reveal 842 756 813 660 472

Overhead 28 19 45 23 15

(%) 5 3 6 4 3

W/O cache 3627 931 3532 2599 518

W/ cache 842 756 813 660 472

Speedup 2785 175 2719 1938 46

(%) 77 19 77 75 9

formance of the hardware, while on other cards, addi-

tional transformations had to be made. This compu-

tation is the precomputed part; thus, it inﬂuences the

speedup over signing without caching the most.

We estimate that implementing the signing part

using native low-level operations instead of slower

software emulation via JCMathLib would achieve

performance comparable to ECDSA on a given plat-

form, e.g., around 200 ms for common smartcards

(Dzurenda et al., 2017). Nonce caching with encryp-

tion would provide an overall speedup of around 50%

in such implementations.

Our implementation of SHINE uses a central party

(written in Rust), which mediates communication

among different devices and serves as a storage of

the cached nonces. It contains NE, NC, and ND

schemes, which can be used by themselves or jointly

with the SHINE applet, demonstrating its interoper-

ability. Both open-source implementations are avail-

able in GitHub repositories

5 CONCLUSION

We studied the possibility of interoperability of

Schnorr-based multi-party signature schemes and

classiﬁed the existing schemes based on their ap-

proach to the nonce agreement – a key component

in signature computation. We identiﬁed four classes

of nonce agreement approaches – nonce exchange

(NE), nonce commitment (NC), nonce delinearization

(ND), and deterministic nonce derivation (DN).

NE-based schemes are secure only with limited

concurrency, but they are the most efﬁcient and the

most interoperable. For these reasons, we suggest

that schemes of this class should be considered for the

use-cases where computation is costly and sequential

execution is acceptable. One such case includes cryp-

tographic smartcards, for which we designed a new

multi-signature scheme called SHINE.

Schemes based on DN are the most rigid, the least

interoperable, and the most computationally demand-

ing. However, in return for these downsides, they

gain the beneﬁts of stateless execution and no need

for additional randomness. Therefore, these schemes

should be considered for the scenarios where compu-

tation is not a limiting factor, the sources of random-

ness are limited, and a setup of homogeneous imple-

mentations can be guaranteed.

ND schemes schemes lie in the middle between

NE and DN with regard to both their computational

https://github.com/crocs-muni/SHINE/

https://github.com/crocs-muni/SHINE-mediator/

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes

313

complexity and their interoperability. In the half-

ND variant, these schemes are interoperable with NE

schemes without compromising their concurrent se-

curity. We thus propose the half-ND schemes to

be considered in the most common scenario featur-

ing reasonably fast devices like smartphones, which

could beneﬁt from interoperability with more con-

strained devices, while enjoying the beneﬁts of secu-

rity under concurrent execution.

The class of NC-based schemes is the only one

that currently does not display any apparent addi-

tional utility. It provides concurrent security achiev-

able even for computationally restricted devices, but

such devices could easily rely on the more efﬁcient

NE, which would also allow them to be interoperable

with half-ND schemes.

We designed the scheme SHINE to beneﬁt from

interoperability while being efﬁciently executable on

cryptographic smartcards. The scheme is based on

NE complemented by a novel approach to nonce

caching – featuring encryption and avoiding the pre-

vious attack by Drijvers et al. (Drijvers et al., 2019).

We implemented SHINE as an applet for the

JavaCard platform and evaluated its performance on

ﬁve different smartcard models. The experiments em-

pirically conﬁrmed the performance improvement of

nonce caching on computationally restricted devices

over a variant without caching. Furthermore, we

provided a Rust implementation of the central party

that practically demonstrates the interoperability of

SHINE with NE, NC, and half-ND schemes.

We view the interoperability of multi-party pro-

tocols as a meaningful and practical way to increase

resilience and ﬂexibility of multi-party systems. Fol-

lowing this path, future research could investigate

the possibility of interoperability among other types

of multi-party protocols, e.g., the recent designs of

threshold ECDSA signatures.

ACKNOWLEDGEMENTS

Authors were supported by Czech Science Founda-

tion project GA20-03426S. V. Sedlacek was also sup-

ported by the Ph.D. Talent Scholarship – funded by

the Brno City Municipality.

REFERENCES

Alper, H. K. and Burdges, J. (2021). Two-round trip schnorr

multi-signatures via delinearized witnesses. In Annual

International Cryptology Conference. Springer.

Bagherzandi, A., Cheon, J.-H., and Jarecki, S. (2008). Mul-

tisignatures secure under the discrete logarithm as-

sumption and a generalized forking lemma. In Pro-

ceedings of the 15th ACM conference on Computer

and communications security, pages 449–458.

Bellare, M., Namprempre, C., Pointcheval, D., and Se-

manko, M. (2003). The one-more-rsa-inversion prob-

lems and the security of chaum’s blind signature

scheme. Journal of Cryptology, 16(3).

Benhamouda, F., Lepoint, T., Loss, J., Orru, M., and

Raykova, M. (2021). On the (in) security of ros. In

Annual International Conference on the Theory and

Applications of Cryptographic Techniques, pages 33–

53. Springer.

Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and Yang,

B.-Y. (2012). High-speed high-security signatures.

Journal of Cryptographic Engineering, 2(2):77–89.

Boneh, D., Drijvers, M., and Neven, G. (2018). Compact

multi-signatures for smaller blockchains. In Interna-

tional Conference on the Theory and Application of

Cryptology and Information Security, pages 435–464.

Springer.

Crites, E., Komlo, C., and Maller, M. (2021). How to

prove schnorr assuming schnorr: Security of multi-

and threshold signatures. Cryptology ePrint Archive.

Drijvers, M., Edalatnejad, K., Ford, B., Kiltz, E., Loss, J.,

Neven, G., and Stepanovs, I. (2019). On the security

of two-round multi-signatures. In IEEE Symposium

on Security and Privacy, pages 1084–1101.

Dzurenda, P., Ricci, S., Hajny, J., and Malina, L. (2017).

Performance analysis and comparison of different el-

liptic curves on smart cards. In 2017 15th Annual Con-

ference on Privacy, Security and Trust (PST), pages

365–374. IEEE.

Fiat, A. and Shamir, A. (1986). How to prove your-

self: Practical solutions to identiﬁcation and signature

problems. In Conference on the theory and appli-

cation of cryptographic techniques, pages 186–194.

Springer.

Garillot, F., Kondi, Y., Mohassel, P., and Nikolaenko, V.

(2021). Threshold schnorr with stateless determin-

istic signing from standard assumptions. In Annual

International Cryptology Conference, pages 127–156.

Springer.

IANIX (2022). Things that use Ed25519. https://ianix.com/

pub/ed25519-deployment.html. Accessed: 2022-02-

01.

Komlo, C. and Goldberg, I. (2021). Frost: Flexible round-

optimized schnorr threshold signatures. In Dunkel-

man, O., Jacobson, Jr., M. J., and O’Flynn, C., editors,

Selected Areas in Cryptography, pages 34–65, Cham.

Springer International Publishing.

Mavroudis, V., Cerulli, A., Svenda, P., Cvrcek, D.,

Klinec, D., and Danezis, G. (2017). A touch of

evil: High-assurance cryptographic hardware from

untrusted components. In Proceedings of the 2017

ACM SIGSAC Conference on Computer and Commu-

nications Security, pages 1583–1600.

Mavroudis, V. and Svenda, P. (2020). Jcmathlib: Wrap-

per cryptographic library for transparent and certiﬁ-

SECRYPT 2022 - 19th International Conference on Security and Cryptography

314

able javacard applets. IEEE European Symposium on

Security and Privacy Workshops, pages 89–96.

Maxwell, G., Poelstra, A., Seurin, Y., and Wuille, P.

(2019). Simple Schnorr multi-signatures with appli-

cations to Bitcoin. Designs, Codes and Cryptography,

87(9):2139–2164.

Morita, H., Schuldt, J. C., Matsuda, T., Hanaoka, G., and

Iwata, T. (2015). On the security of the schnorr sig-

nature scheme and dsa against related-key attacks. In

Information Security and Cryptology - ICISC 2015,

pages 20–35. Springer.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system. https://bitcoin.org/bitcoin.pdf. Ac-

cessed: 2022-02-01.

Nick, J., Rufﬁng, T., and Seurin, Y. (2021). Musig2: Sim-

ple two-round schnorr multi-signatures. In CRYPTO,

pages 189–221. Springer.

Nick, J., Rufﬁng, T., Seurin, Y., and Wuille, P. (2020).

Musig-dn: Schnorr multi-signatures with veriﬁably

deterministic nonces. In 27th ACM CCS, pages 1717–

1731.

Pointcheval, D. and Stern, J. (2000). Security arguments

for digital signatures and blind signatures. Journal of

cryptology, 13(3):361–396.

Schnorr, C. P. (1991a). Efﬁcient signature generation by

smart cards. Journal of Cryptology, 4(3):161–174.

Schnorr, C. P. (1991b). Method for identifying subscribers

and for generating and verifying electronic signatures

in a data exchange system. US Patent 4,995,082.

Schnorr, C. P. (2001). Security of blind discrete log signa-

tures against interactive attacks. In International Con-

ference on Information and Communications Security,

pages 1–12. Springer.

Syta, E., Tamas, I., Visher, D., Wolinsky, D. I., Jovanovic,

P., Gasser, L., Gailly, N., Khofﬁ, I., and Ford, B.

(2016). Keeping authorities ”honest or bust” with de-

centralized witness cosigning. In IEEE Symposium on

Security and Privacy, pages 526–545.

Wagner, D. (2002). A generalized birthday problem. In

Annual International Cryptology Conference, pages

288–304. Springer.

Wuille, P., Nick, J., and Towns, A. (2020a). Schnorr signa-

tures for secp256k1. https://github.com/bitcoin/bips/

blob/master/bip-0340.mediawiki. Accessed: 2022-

02-01.

Wuille, P., Nick, J., and Towns, A. (2020b). Taproot:

Segwit version 1 spending rules. https://github.com/

bitcoin/bips/blob/master/bip-0341.mediawiki. Ac-

cessed: 2022-02-01.

APPENDIX

The Security of SHINE

We aim to reduce the security of SHINE (Figure 5) to

the OMDL problem; we use the following algorithms:

• GrGen that outputs a group description (G,q,G)

for a given security parameter λ,

• KeyGen that outputs a standard, uniformly sam-

pled key pair (x

G),

• KeyAgg that performs key aggregation according

to the selected group establishment method,

• Verify that performs standard Schnorr signature

veriﬁcation.

The security reduction relies on the one-more

discrete logarithm (OMDL) problem (Bellare et al.,

2003): the adversary has access to an oracle O

DLog

providing them with up to q

discrete logarithms,

while the goal is presenting discrete logarithms of

+ 1 challenges received from the O

Chall

oracle.

Theorem 1. If a polynomial adversary A against the

SHINE unforgeability game (Fig. 5) wins with prob-

ability ε while making q

reveal oracle queries and

−q

random oracle queries, then the OMDL prob-

lem can be solved in polynomial time with probability

′

in the ROM with the KOSK assumption, such that:

′

≥

−

max

where k

max

= 8q

/ε · ln(8n/ε).

Proof. The proof adapts the main idea of the reduc-

tion given by Drijvers et al. (Drijvers et al., 2019)

for the restricted version of CoSi. Given the adver-

sary A from the theorem statement, we construct an

algorithm B that simulates the SHINE unforgeability

game for A , and succeeds when it does not abort and

A succeeds. The algorithm B is constructed in a way

compatible with the forking lemma, which we then

apply to B to solve the OMDL problem.

The algorithm B is started with elements from

for the random oracle outputs (h

,. .. ,h

) and is

given access to oracles O

Chall

and O

DLog

. We sequen-

tially order the O

Reveal

and O

oracle queries made

by A . If the k-th query is a random oracle query, B

replies with h

. If k-th query is a reveal query, we set

= k, where j is the input to the query. We also mod-

ify O

Chall

to accept an input element from Z

. When

the oracle is queried on a previously unseen element,

it invokes its inner O

Chall

oracle; otherwise, it outputs

the previously output value. Without loss of general-

ity, we assume that A makes all random oracle queries

needed to verify the produced signatures.

First, B makes a minor modiﬁcation of nonce

caching in the simulation, allowing us to defer nonce

sampling to the time when the corresponding decryp-

tion key should be revealed – as per SHINE’s sequen-

tial nature. The change is sampling a random string

SHINE: Resilience via Practical Interoperability of Multi-party Schnorr Signature Schemes

315

Game

EUF−CMA

(λ)

(G,q,G) ← GrGen(1

)

← Z

; c ← 0; Q ← {}

) ← KeyGen()

,... , X

← A (X

)

X ← KeyAgg(X

,... , X

)

∗

,σ

∗

) ← A

Cache,Reveal,Sign,H

)

return m

∗

/∈ Q ∧ Verify(X, m

∗

,σ

∗

)

Cache

( j)

1, j

← PRF

( j)

1, j

← r

1, j

← KDF

( j)

1, j

← Enc

, j

1, j

)

return E

1, j

Reveal

( j)

if j ≥ c then

c ← j

ﬁ

1, j

← KDF

(c)

return k

1, j

Sign

(R,m, j)

if j < c then

abort

ﬁ

c ← j + 1

1, j

← PRF

( j)

1, j

← r

1, j

+ H(R,X, m)x

Q ← Q ∪ {m}

return s

1, j

Figure 5: The SHINE unforgeability game. O

is the random oracle.

1, j

in the O

Cache

oracle instead of computing and en-

crypting R

1, j

. The value R

1, j

is computed only when

the corresponding decryption key should be revealed,

i.e., in the corresponding O

Reveal

call, and the decryp-

tion key is chosen so that the decrypted value corre-

sponds to the sampled R

1, j

. For that, we need the en-

cryption to be non-binding. This change is indistin-

guishable by A , does not introduce additional aborts,

and B succeeds whenever A succeeds.

Another change that B makes is setting an out-

put of O

Chall

as X

, instead of using the KeyGen algo-

rithm. Because of this change, x

is not known any-

more, but we still need to be able to correctly simulate

the signing queries, which we do as follows.

Before running A , B tosses a biased coin coin

that turns out 1 with probability 1/q

for every sign-

ing instance j ∈ {1,. .., q

}. Whenever coin

= 1, B

samples g

∈ {1,. .., q

}. The simulation of O

Reveal

and O

Sign

oracles for session j then depends on coin

If coin

= 0, B invokes O

Chall

) to get the el-

ement R

1, j

when revealing the decryption key. To

successfully answer a signing query, the simulator

queries its O

DLog

oracle with R

1, j

+ H(R, X,m)X

If coin

= 1, B samples a random s

1, j

from Z

and computes R

1, j

= s

1, j

G − h

X when revealing the

decryption key. The signing query might not always

succeed in this case. If H(R,X, m) ̸= h

for the input

provided in the signing query, B aborts. Otherwise, it

outputs s

1, j

in the corresponding O

Sign

call.

Due to SHINE’s design, at most one correspond-

ing O

Sign

query has not been made, nor has the ses-

sion been invalidated by querying O

Sign

with a higher

index. If a session was open when the query for the

forgery was made and coin

= 0, B aborts.

When B does not abort, the changes are indistin-

guishable by A, and B succeeds whenever A suc-

ceeds. B does not abort when the session index

is guessed correctly, which happens with probabil-

ity 1/q

, and the corresponding hash oracle query is

also guessed correctly, which happens with probabil-

ity 1/q

. Furthermore, B does not abort when no ses-

sion was open when the fork occurred. From that, we

get that the success probability of B is at least ε/q

Now, we apply the Generalized Forking Lemma

(Bagherzandi et al., 2008) to B. By the construction

of B , no challenge that is still being usable for sign-

ing is known at the time of the fork; thus, the applica-

tion of the forking lemma does not result in multiple

DLog

queries for the same challenge. If the forking

of B succeeds and it outputs two forgeries s and s

′

for

hashes h and h

′

, respectively, we use them to solve

the OMDL problem in the following way. First, we

compute the discrete logarithm of the group key X as

x = (s − s

′

)/(h − h

′

). In the KOSK model, we can

compute the discrete logarithm of X

directly from x,

as A has to output its private keys (x

,. .. ,x

), and x is

a linear combination of (x

,. .. ,x

). To compute an-

swers to the other challenges, we use x

to solve linear

equations in the form r

1, j

= s

1, j

− H(R

,X, m)x

; if

some outputs of O

Chall

were not used during signing,

we apply O

DLog

on them.

The probability of solving the OMDL is the prob-

ability that the forking succeeded and no collisions

occurred among any of the q

values that B submits

to its O

Chall

in any of its runs. Thus, we have

′

≥

−

max

We needed the KOSK model only at the end of

the proof – to extract the private key x

. The KOSK

model can be avoided in settings with a separate group

establishment where the group key is ﬁxed prior to

issuing signatures; and the proof can be extended to

MuSig-like and proof of possession group key aggre-

gation by extracting the key correspondingly.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

316