Preprint
Article

This version is not peer-reviewed.

A Shoup-Aligned Post-Finalization Single-Round Threshold Schnorr Prototype for UAV Swarms

Submitted:

20 August 2026

Posted:

21 August 2026

You are already at the latest version

Abstract
Unmanned Aerial Vehicle (UAV) swarms are an essential asset in mission-critical and tactical environments due to their low cost, mass production, portability, and mobility compared to other assets. Their low-resource nature may lead to unstable computation and network delays in contested areas, making the UAV nodes unresponsive. Thus, ensuring secure, low-latency collective communication and authentication is of main interest. More importantly, ensuring decentralised and autonomous swarms model requires lightweight cryptographic protocols, which are one of the critical barriers to the widespread adoption. Threshold signature schemes, such as FROST, typically necessitate multiple rounds of communication to coordinate ephemeral nonces, introducing prohibitive latency and high energy consumption in bandwidth-limited UAV networks. In this work, we specify and evaluate SRTS, a Shoup-aligned, batch-extracted threshold Schnorr composition whose online signing stage requires one signature-share round after a presignature slot has been irrevocably assigned and a unique finalization certificate is available. We compare SRTS with FROST, tBLS, and MuSig2.
Keywords: 
;  ;  ;  ;  ;  

1. Introduction

The low cost, portability, and mobility of Unmanned Aerial Vehicle UAV swarms make them convenient and effective across fields, particularly in high-risk and contested areas. These low-resource vehicles are capable of inspecting and monitoring infrastructure, performing tactical reconnaissance, and making independent or collective decisions based on collected data, following a command-and-control architecture. However, achieving secure decentralized decision-making is challenging and a critical barrier to adopting this architecture, due to UAVs’ hardware constraints and to unstable and limited connectivity. In this context, cryptographic schemes that enable agreement on commands received from a Ground Control Station (GCS) and on autonomous decisions are required under distributed trust. To this end, threshold signature schemes let a quorum of t out of n nodes to cooperate to produce a valid group signature, preventing any single compromised node from authorising a decision. On the one hand, based on bilinear pairings [1], BLS achieves a single-round signing phase, in which each node emits one partial signature, aggregated, and the result is verifiable against the group public key using the pairing equation. This non-interactive structure makes BLS resilient to network degradation, whereas pairing-based verification is computationally expensive and requires careful consideration when selecting a Pairing-friendly curve. On the other hand, The Flexible Round-Optimized Schnorr Threshold (FROST) protocol [2] leverages the standard Schnorr signature to achieve faster verification. The signature shares are aggregated and the result is verifiable against the group public key. However, FROST signing phase requires two interactive rounds, a nonce commitment broadcast followed by a signature-share broadcast, making it sensitive to network degradation. Thus, for a decentralized low-hardware UAV swarm network to be practical, signing must be resilient in contested low-bandwidth environments that may incur packet delays or loss, and verification must be fast.
Given this context, we implement and evaluate the SRTS scheme. This scheme follows Shoup’s modular threshold-Schnorr framework in the random-oracle and Elliptic-Curve Generic-Group (EC-GGM) model [3]. It moves interactive cryptographic preparation to an offline phase and generates P one-time presignature slots from the verifiable contributions of Q UAVs. Batch preprocessing amortizes communication costs across multiple commands and eliminates repeated distributed preparation. After command finalization, the scheme requires a single round to collect locally computed signature shares. Consensus binds each command to a unique unused slot before revealing the rerandomization shift, thereby preventing reuse and adaptive selection. Finally, the scheme produces a compact Schnorr signature with constant size and verification cost, independent of the number of participating UAVs.

1.1. Contributions

This work implements and evaluates a batched, post-finalization, single-round threshold Schnorr construction for command authorization in decentralised UAV swarms. The construction is a Shoup-aligned threshold Schnorr [3] composed to improve resilience under unstable connectivity, limited bandwidth, and constrained computation. Its main contributions are as follows:
  • Resilience to network degradation: The construction moves interactive cryptographic preparation to an offline phase. During this phase, Q UAVs contribute verifiable shared ephemeral inputs, which are transformed through public linear extraction into P one-time presignature slots. Hence, preparing these slots in batches amortizes the communication cost across multiple future commands and avoids repeating distributed preprocessing.
  • Low-latency online authorization: When a command is finalized, each selected UAV computes its response share locally from an assigned presignature slot. Only one signature-share round is required after finalization, with no further interaction among UAVs. This reduces online communication, limits exposure to packet loss and link delays, and makes authorization more suitable for low-bandwidth or intermittently connected UAV networks.
  • Secure presignature-slot assignment: Consensus binds each command to exactly one unused presignature slot before the finalization certificate and its associated rerandomization shift are revealed. This ordering prevents presignature reuse and stops an adversary from adaptively selecting or influencing a slot after observing the shift.
  • Efficient verification: The distributed signing process produces a compact Schnorr signature whose size and verification cost are independent of the number of participating UAVs. Then, the verifier checks one final aggregate signature rather than individual response shares or the distributed signing transcript, enabling efficient command verification.

1.2. Organization of This Paper

The remainder of this paper is organized as follows. Section 2 reviews related UAV security and threshold signature schemes. Section 3 introduces the notation, cryptographic foundations, system model, and assumptions. Section 4 presents the SRTS long-term key generation, batch presignature extraction, post-finalization signing, and public verification procedures. Section 5 summarizes the main scheme properties and operational requirements. Section 6 defines the security model and analyzes unforgeability, share confidentiality, one-use state, and malformed-share handling. Section 7 describes the experimental methodology and compares SRTS with FROST, tBLS, and MuSig2. Finally, Section 8 discusses the results, limitations, and future work, while Section 9 concludes the paper.

3. Preliminaries

In this section, we introduce the notations and the required definitions and assumptions, communication and evaluation model we adopt throughout this work.

3.1. Notations

Table 1 summarizes the notation. The security parameter is λ N , and negl ( λ ) denotes a negligible function. We write x $ S for uniform sampling from a finite set S, x $ D for sampling from a distribution, and y A ( x ) for one execution of a probabilistic algorithm with fresh randomness.
The parameter constraints enforced by the prototype are
0 f < t n f , n > 3 f , Q = n f , P = n 2 f .
The direct Shoup-style sharing profile maps Shoup’s corruption parameter to our f and therefore uses t = f + 1 . The implementation additionally evaluates a majority profile t = n / 2 . Measurements at thresholds other than f + 1 are sensitivity experiments: their distributed-security interpretation remains conditional on a VSS/MPC realization secure for the chosen ( f , t , n ) . In both beacon integration modes, the prototype sets the finalization threshold to the high value
t β = Q = n f .

3.2. Public Parameters, State, and Transcript Binding

The public parameters pp is defined by:
pp = ( G , N , G , n , f , t , Q , P , t β , W , H batch , H assignment , H beacon , H δ , H c )
such that we set W k , j = x j k 1 mod N , x j = j , k [ P ] , j [ Q ] , so every P-column square submatrix is a nonsingular Vandermonde matrix.
All five functions are domain-separated SHA-256 hashes with length-prefixed inputs. H batch takes ( n , t , f , D , I , { R ¯ k } ) and outputs batchID to identify and bind the batch, H assignment takes ( requestID , m , batchID , k ) and outputs a to bind the command to its slot, H beacon takes a and outputs the beacon-signed digest μ β , H δ takes ( σ β , D , batchID , k , requestID , m ) and outputs δ Z N to rerandomize the slot, and H c takes ( D , R , m ) and outputs the Schnorr challenge h Z N .
Let enc 4 and enc 8 be unsigned big-endian encodings of four and eight bytes. Matching the implementation, the public transcript is bound by
batchID = H batch enc 4 ( n ) , enc 4 ( t ) , enc 4 ( f ) , D , enc 4 ( i 1 ) , , enc 4 ( i Q ) , R ¯ 1 , , R ¯ P , a = H assignment requestID , m , batchID , enc 8 ( k ) , μ β = H beacon ( a ) , δ = H δ σ β , D , batchID , enc 8 ( k ) , requestID , m mod N , R = R ¯ k + [ δ ] G , h = H c ( D , R , m ) mod N .
Here σ β denotes the unique signature component of the verified certificate. The certificate is accepted only if it signs μ β , has at least t β distinct valid signer identifiers, and verifies under the public beacon key.
Table 2 classifies the construction state according to its lifetime, visibility, and required protection. In particular, epoch state is reusable only while the committee and its long-term keys remain unchanged, whereas each batch supplies one-use presignature state. The request state binds one slot to one message, and the persistent state transition prevents that slot’s secret share from being released or used more than once.

3.3. System and Trust Model

We consider a fixed mission epoch with a known signing committee P = { P 1 , , P n } . A change in committee membership starts a new epoch, with a new distributed key-generation execution and a new presignature inventory. The roles in one epoch are:
  • Signing UAVs: UAV P i holds a long-term signing share d i and one secret share r ¯ k , i for every available presignature slot k. A selected set S of t UAVs produces signature shares.
  • Requester: A GCS, mission service, or autonomous UAV may submit ( requestID , m ) . This input is not trusted merely because it originated at the GCS; authorization results from consensus assignment followed by threshold signing.
  • Consensus/finalization service: This assumed service orders requests, irrevocably binds one globally unused slot to one request, and supplies a unique publicly verifiable finalization certificate. It may be run by the same UAV committee, but it is a separate interface in the security and performance models.
  • Combiner: A UAV, GCS process, or other service verifies signature shares and aggregates t valid shares. The combiner is not trusted with any long-term or presignature scalar, and malformed output is rejected by public verification.
  • Verifier: Any UAV, GCS, recipient, or auditor knowing only ( D , m , σ ) verifies the final ordinary Schnorr equation.
It is worth noting that the GCS role may coordinate the pre-mission process. It may authenticate the mission committee, provide network connectivity, distribute public parameters, record the agreed public key and qualified set, and confirm that provisioning is complete. In addition, we use the term dealer to refer to the construction participants’ UAVs and GCS and its depends on the context. It refers to every committee UAV P i distributing a verifiable sharing of its private contribution to the long-term key during the Long-Term DKG Section 4.1, and the same during the Offline Presignature-Batch Generation Section 4.2 to distribute A verifiable sharing of one ephemeral scalar r i , or to the GCS who may play the complete key sharing, assuming the the GCS the the trusted dealer or party.

3.4. Elliptic Curve Groups

Definition 1
(Elliptic curve group). Anelliptic curve group G = E ( F p ) is the set of affine points satisfying y 2 = x 3 + a x + b ( mod p ) (together with the point at infinity O ), equipped with the chord-and-tangent group law. When | G | = N is a large prime, G is cyclic and every non-identity element is a generator.
We instantiate G as the secp256k1 elliptic curve, defined over F p with
p = 2 256 2 32 2 9 2 8 2 7 2 6 2 4 1 ,
and group order
N = 0 xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBA AEDCE 6 AF 48 A 03 BBFD 25 E 8 CD 0364141 .
This curve is also used by Bitcoin and Ethereum and is supported by production-level libraries (libsecp256k1, coincurve).

3.5. Hardness and Idealized-Model Assumptions

Definition 2
(Discrete Logarithm Problem — DLP). Let G be a cyclic group of prime order N with generator G. Thediscrete logarithm problemis: given Y = [ x ] G for a uniformly random x $ Z N , compute x. We say the DLP is ( T , ε ) -hardin G if every probabilistic algorithm A running in time T satisfies Pr [ A ( G , Y ) = x ] ε .

3.6. Schnorr Signatures

Definition 3
(Schnorr signature scheme). ASchnorr signature schemeover group G = G of order N is a triple ( KeyGen , Sign , Verify ) :
  • KeyGen ( 1 λ ) : sample d $ Z N , output ( d , D ) = ( d , [ d ] G ) .
  • Sign ( d , m ) : sample r $ Z N ; let R = [ r ] G , h = H ( D R m ) , z = r + h · d mod N ; output ( R , z ) .
  • Verify ( D , m , σ ) : parse σ = ( R , z ) ; let h = H ( D R m ) ; accept iff [ z ] G = R + [ h ] D .
Schnorr signatures are existentially unforgeable under chosen-message attack (EUF-CMA) in the random oracle model under the DLP assumption [20]. The verification equation [ z ] G = R + [ h ] D is the algebraic identity underlying the correctness proof of SRTS (Proposition 1).

3.7. Secret Sharing and Distributed Key Generation

Definition 4
( ( t , n ) -Shamir secret sharing). A ( t , n ) -Shamir secret sharingof s Z N samples a uniformly random polynomial ϕ ( X ) = a = 0 t 1 ϕ a X a Z N [ X ] with ϕ ( 0 ) = s , and gives s i = ϕ ( i ) to P i . Any t shares determine s; any set of fewer than t shares is statistically independent of s. The symbol ϕ avoids overloading the corruption bound f.
Definition 5
(Lagrange interpolation in Z N ). For S [ n ] , | S | = t , and evaluations { ( i , s i ) } i S of ϕ,
ϕ ( 0 ) = i S λ i , S s i mod N , λ i , S = j S j i j j i mod N .
Applying the formula to the constant polynomial 1 gives i S λ i , S = 1 mod N .
Definition 6 (Verifiable Secret Sharing —VSS)A VSS protocol augments secret sharing with commitments, verification, and complaint/disqualification rules so honest parties either retain shares consistent with one committed polynomial or reject the dealer. Whether verification evidence is public, privately checked, or revealed during complaints depends on the concrete VSS scheme. In this paper VSS is a required interface; the centralized Feldman in the prototype is not a deployed maliciously secure VSS service.

3.8. Threshold Signature Schemes

Definition 7
( ( t , n ) -threshold signature scheme). A ( t , n ) -threshold signature scheme distributes one signing key among n parties and provides setup/key-generation, share generation, share verification/combination, and public verification algorithms. It satisfies:
(i)
Correctness: when at least t valid shares are generated for an authorized request, combination yields a publicly valid signature.
(ii)
Threshold unforgeability: under the stated corruption and signing-query experiment, an adversary controlling fewer than t shares cannot produce a valid signature on an unrequested message.
(iii)
Threshold privacy, when claimed: fewer than t shares reveal no signing scalar beyond the prescribed public outputs.
Producing the same signature format as an ordinary single-party scheme is a construction-specific property. SRTS has this property because its output is an ordinary Schnorr pair ( R , z ) ; it is not part of the generic definition of threshold unforgeability.

3.9. Adversary and Operational Assumptions

The adversary statically selects C , with | C | f < t , before setup. It learns corrupted parties’ long-term and ephemeral shares, controls their protocol messages and scheduling, and may choose corrupted dealers’ ephemeral inputs after observing honest public inputs. It may equivocate where an assumed broadcast/consensus service does not prevent equivocation, withhold shares, trigger aborts, and attempt replay or slot reuse. The cryptographic claim assumes:
(A1)
authenticated private channels and an authenticated reliable-broadcast mechanism for the chosen DKG/VSS realization;
(A2)
a secure VSS/MPC interface supporting verifiable input sharing, local linear operations, and the openings required by the construction;
(A3)
agreement on one ordered set I of Q = n f completed ephemeral inputs;
(A4)
consensus safety and persistence for a globally unique assignment A, committed while slot k is available and before β is revealed;
(A5)
a unique publicly verifiable certificate with threshold t β = n f , unpredictable before the assignment is fixed;
(A6)
secure random-number generation, authenticated persistent state, atomic slot transitions, rollback protection, and rejection of every previously assigned or consumed slot.
Adaptive or mobile corruption, accumulation of shares across epochs, side channels, physical capture, secure hardware erasure, storage rollback, compromised random-number generators, and radio-frequency jamming are not covered. A Byzantine party may always deny its own share; the signature layer alone does not guarantee progress. Liveness additionally requires enough responsive parties and terminating realizations of the assumed services.

3.10. Communication and Evaluation Model

We deliberately separate three layers:
(i)
Security-service layer: DKG/VSS, common-subset, and consensus/finality are assumed interfaces. They may be instantiated by asynchronous or partially synchronous protocols. The condition n > 3 f is inherited from the selected common-subset/finality resilience target not derived from a synchronously bounded UAV radio channel.
(ii)
Post-finalization signing layer: After consensus has committed A and supplied a verified β , selected UAVs compute and transmit signature shares independently in one response transmission stage. Cryptographic safety does not require a known delivery bound Δ , although unavailable shares may prevent completion.
(iii)
Evaluation layer: The reported network results use a deterministic discrete-event model with configured latency, jitter, bandwidth, independent packet loss, and profile-specific retries. This layer estimates behavior under those inputs; it is not a physical UAV channel measurement and supplies no cryptographic security assumption.

4. Construction: Shoup-Aligned Post-Finalization Single-Round Threshold Schnorr

This section specifies the phases and the cryptographic algorithms that this construction implements. In general, this construction has four epochs. First, a long-term key-generation algorithm gives each UAV a signing share and establishes the group public key. Second, the offline presignature-batch generation algorithm that verifiably shares ephemeral inputs, agrees on an ordered qualified set, and extracts a batch of one-time presignature slots. Third, consensus assigns one unused slot to one request and reveals a qualifying finalization certificate; the selected UAVs then send one stage of signature shares. Finally, any party verifies the resulting ordinary Schnorr signature. Thus, “post-finalization single round” refers to a single signature-share response stage; it does not include long-term setup, presignature generation, request agreement, or finalization.

4.1. Long-Term Key-Generation

On success, KeyGen t , n allows every UAV party P i to obtain d i privately, while all parties obtain the same D, public verification shares { D i } , a qualified set, and an epoch identifier. On failure, honest UAV parties abort, with no party receiving d or another honest party’s share. The term long-term only distinguishes the reusable signing shares d i , which authorize many signatures, from the one-time presignature shares r ¯ k , i , and it does not mean that the key is permanent.
D , { ( d i , D i ) } i = 1 n KeyGen t , n ( pp , P ) , D i = [ d i ] G .
For every signer set S P containing t distinct parties with valid shares, the Lagrange coefficients at zero satisfy
i S λ i , S d i = d ( mod N ) , i S λ i , S D i = D .
The first equality expresses reconstruction of the shared signing scalar, although the protocol never needs to reconstruct d explicitly. The second follows by linearity of scalar multiplication and ensures that the public verification shares are consistent with the group public key. The present prototype realizes the corresponding Feldman/Pedersen algebra centrally. Authenticated communication, complaint resolution, agreement on qualified parties, and maliciously secure distributed execution remain requirements of the external DKG realization. Once this phase succeeds, D, D i , and d i remain fixed while the parties repeatedly generate the offline presignature batches described next.

4.2. Offline Presignature-Batch Generation

Long-term key generation and ephemeral presignature generation have different security roles. For the latter, our scheme uses Shoup’s InputKey , ACS, and batch-randomness-extraction  [3]. Honest UAVs choose uniform ephemeral inputs, while corrupted dealers may choose theirs after observing honest public inputs. The resulting points are therefore called biased presignatures; security relies on the full-rank linear-bias model and the later request-specific rerandomization, not on an independence claim.
No ephemeral scalar r i , extracted scalar r ¯ k , or long-term scalar d is opened by Algorithm 1. The matrix W Z N P × Q is the deterministic Vandermonde matrix defined in Section 3.2. Because I contains Q = n f UAVs and at most f are corrupted, it contains at least P = n 2 f honest contributions. Every set of P columns of W is linearly independent, which provides the full-rank honest component required by Shoup’s bias model. The prototype performs the VSS checks, deterministic selection of the first Q valid UAVs, and all matrix operations centrally. Accordingly, its VSS and ACS timings are algebraic/model timings rather than measurements of deployed distributed services.
Algorithm 1: SRTS Offline Presignature Batch via Assumed VSS/MPC and ACS
Require: 
Public parameters pp , group key D; secure VSS/MPC input-sharing interface; ACS interface
Ensure: 
Public Batch = ( batchID , I , { R ¯ k } k = 1 P ) ; at each P , secret shares { r ¯ k , } k = 1 P and verification shares { R ¯ k , } k = 1 P
 
Verifiably shared ephemeral inputs
1:
for each dealer P i , i [ n ]  do
2:
    Sample r i $ Z N and invoke the assumed input-sharing interface
3:
    On successful completion, publish R i = [ r i ] G ; each P retains a verified share r i and the coefficient commitments { C i , a } a = 0 t 1
4:
end for
4:
Agreement and share-local extraction
5:
Invoke ACS to agree on one ordered set I = ( i 1 , , i Q ) of Q = n f completed inputs
6:
for each extraction row k [ P ]  do
7:
    for each coefficient a = 0 , , t 1  do
8:
        Compute the public combined commitment C ¯ k , a = j = 1 Q W k , j C i j , a
9:
    end for
10:
    Each P locally computes r ¯ k , = j = 1 Q W k , j r i j mod N
11:
    Set R ¯ k = C ¯ k , 0 and derive R ¯ k , = a = 0 t 1 a C ¯ k , a
12:
    Check [ r ¯ k , ] G = R ¯ k ,
13:
end for
13:
Batch binding and one-use state
14:
Compute batchID with H batch over the exact transcript specified in Section 3.2
15:
Publish Batch ; initialize every slot as AVAILABLE

4.3. Post-Finalization Signature-Share Stage

For an available slot k, consensus first commits A = ( requestID , m , batchID , k ) and changes its persistent state from AVAILABLE to ASSIGNED in one atomic action. Afterward, the finalization service may reveal a certificate β = ( μ β , σ β , S β ) . Then, every signer checks that β verifies the digest of this exact assignment, contains at least t β = n f distinct valid certificate signers, and is bound to the same epoch and batch. The online signature-share computation is then as follows.
An assigned slot never returns to X, even if too few responses arrive or the combination fails. Once a share is released, the slot must be deleted before permitting recovery or retry. Moreover, the signer-to-combiner responses in Algorithm 2 constitute the post-finalization online communication measured as the primary the construction path.
Algorithm 2:SRTS Post-Finalization Signing—One Signature-Share Stage
Require: 
Committed assignment A = ( requestID , m , batchID , k ) ; verified certificate β = ( μ β , σ β , S β ) ; public D , R ¯ k , { D i , R ¯ k , i } ; at P i , secrets d i , r ¯ k , i
Ensure: 
Ordinary Schnorr signature σ = ( R , z )
1:
Reject unless A is the unique committed assignment for slot k, the local slot state is ASSIGNED , and β verifies for A
2:
Compute
δ = H δ ( σ β , D , batchID , enc 8 ( k ) , requestID , m ) mod N
3:
Compute R = R ¯ k + [ δ ] G and h = H c ( D , R , m ) mod N
3:
Independent signer responses
4:
for each responding signer P i  do
5:
    Compute z i = r ¯ k , i + δ + h d i mod N
6:
    Check [ z i ] G = R ¯ k , i + [ δ ] G + [ h ] D i
7:
    Atomically record release for A, delete the stored r ¯ k , i , and never serve another assignment with slot k
8:
    Send ( i , z i ) to the untrusted combiner
9:
end for
9:
Public share checking and combination
10:
Let S be the identifiers of the first t distinct responses satisfying [ z i ] G = R ¯ k , i + [ δ ] G + [ h ] D i
11:
Compute z = i S λ i , S z i mod N
12:
Reject unless [ z ] G = R + [ h ] D ; otherwise output σ = ( R , z )
13:
Finalize the persistent transition ASSIGNED CONSUMED at every honest node
Proposition 1
(Correctness of SRTS signing). If the combiner accepts t shares consistent with the committed long-term and presignature shares, Algorithm 2 outputs a signature satisfying [ z ] G = R + [ h ] D .
Proof. 
For the accepted set S , Shamir reconstruction and the constant polynomial identity give
i S λ i , S r ¯ k , i = r ¯ k , i S λ i , S d i = d , i S λ i , S = 1 .
Hence
z = i S λ i , S ( r ¯ k , i + δ + h d i ) = r ¯ k + δ + h d ( mod N ) ,
and therefore [ z ] G = R ¯ k + [ δ ] G + [ h ] D = R + [ h ] D .    □

4.4. Public Signature Verification

After the combiner aggregates t valid signature shares, it publishes the ordinary Schnorr signature σ = ( R , z ) G × Z N . Any UAV, GCS, mission service, or external auditor that possesses the authenticated group public key D can verify the signature without interacting with the signers or the combiner. Unlike signature-share verification, public verification does not require the verification shares D i , presignature verification shares R ¯ k , i , signer identifiers, assignment, or finalization certificate. Algorithm 3 describes this public verification procedure.
For an honestly generated signature, z = r ¯ k + δ + h d mod N and R = R ¯ k + [ δ ] G . Therefore,
[ z ] G = [ r ¯ k + δ + h d ] G = R ¯ k + [ δ ] G + [ h ] D = R + [ h ] D
so Algorithm 3 returns Accept .
Algorithm 3: SRTS Public Schnorr Signature Verification
Require: 
Authenticated group public key D, message m, and signature σ = ( R , z )
Ensure: 
Accept or Reject
1:
Reject unless D and R are valid canonically encoded elements of G and z is a canonical element of Z N
2:
Compute h = H c ( D , R , m ) mod N
3:
if [ z ] G = R + [ h ] D then
4:
    return  Accept
5:
else
6:
    return  Reject
7:
end if
The published signature contains only the Schnorr pair ( R , z ) . Neither the signature nor the public verification input encodes the reconstruction threshold t, signer set S , presignature batch or slot, finalization certificate β , or individual shares. Acceptance establishes that σ is a valid Schnorr signature on m under D; by itself, it does not prove to an external verifier which UAVs participated, which presignature slot was consumed, or whether the internal assignment and one-use state transitions were executed correctly. Those properties are enforced during threshold signature generation and by the assumed consensus and persistent-state services.

5. Scheme Properties

This section gives the properties of the SRTS scheme against the three other constructions, FROST  [2], tBLS [17], and MuSig  [18]. Table 3 highlights that the four approaches provide different functionality and use different interaction boundaries. SRTS, FROST, and tBLS support a flexible t-of-n signer model, whereas ordinary MuSig2 requires all n registered signers. SRTS has one signer-to-combiner response stage only after consensus has assigned a presignature slot and supplied a qualifying finalization certificate. tBLS likewise requires one signature-share response stage once the message is fixed, and its final verification is pairing-based. FROST and MuSig2 require per-signature nonce material and additional signing interaction, although part of their nonce generation can be moved to preprocessing. SRTS, FROST, and MuSig2 produce Schnorr-family outputs whose final verification cost is independent of the committee size, while tBLS produces a BLS signature. Finally, the setup rows are not equivalent trust models: SRTS assumes the secure long-term key-generation interface specified in Section 4.1, FROST and tBLS require an external sharing or DKG realization, and MuSig2 aggregates independently generated public keys.

5.1. Post-Finalization Signature-Share Stage

Once the consensus/finalization service has supplied a verified certificate β after committing
A = ( requestID , m , batchID , k ) ,
each selected signer independently computes one share z i and sends it to a combiner. Thus, the SRTS claim is one post-finalization signer-response stage. It excludes request dissemination, assignment agreement, certificate production, long-term setup, and offline inventory generation. A standalone beacon adds its own protocol stages and is reported as a separate integration mode. This is an interaction-structure claim, not unconditional one-round liveness. Withholding parties may force the system to contact additional UAVs or prevent completion, and the assumed services must themselves terminate.

5.2. Presignature Inventory and Amortization

For the fixed conservative parameters used by SRTS, one accepted set of Q = n f verifiably shared inputs produces P = n 2 f one-use slots. If the corresponding offline execution costs C off ( n , f ) , the accounting identity is
C off , slot ( n , f ) = C off ( n , f ) n 2 f .
This identity does not make preprocessing O ( 1 ) , and it does not include inventory persistence, replenishment, or distributed VSS/ACS communication.
The combiner needs t accepted shares. If a known responsive set of exactly t UAVs is selected, the response stage uses O ( t ) point-to-point transmissions. A fallback that solicits the full committee can cause up to O ( n ) attempted responses; all-to-all dissemination would instead cause quadratic transmission growth. These are transmission counts, not additional claims about consensus rounds or radio delivery.

5.3. One-Use State and Nonce-Reuse Safety

Public rerandomization does not make reuse of r ¯ k safe. For two responses z j = r ¯ k + δ j + h j d , j { 1 , 2 } , with h 1 h 2 , the public transcripts reveal
d = ( z 1 z 2 δ 1 + δ 2 ) ( h 1 h 2 ) 1 mod N .
Consequently, durable non-reuse is a safety invariant: an assigned slot never returns to AVAILABLE , and release of any signature share must be preceded by a persistent burn record that survives retry, crash, and rollback.
The prototype tests assignment-before-certificate, rejects reassignment and successful-path reuse, detects malformed shares, clears the in-process share dictionary after a successful aggregate, and moves the slot to CONSUMED . It does not implement a replicated crash-safe store, consume-before-release across processes, rollback-resistant hardware, or physical memory erasure. Physical erasure limits later compromise exposure, but the formal static-corruption claim below relies first on irrevocable one-time protocol state.

5.4. Ordinary Schnorr Output

The output ( R , z ) satisfies [ z ] G = R + [ h ] D under the group public key. Public verification therefore needs no knowledge of the threshold, signer set, presignature batch, assignment certificate, or individual shares. This algebraic format statement does not establish distributional indistinguishability under every side channel, nor interoperability with a particular external encoding such as BIP340. Byte sizes in the evaluation refer to the concrete encodings used by the compared implementations rather than universal scheme constants.

5.5. Assumed Long-Term Key Generation

SRTS requires the secure long-term key-generation interface of Section 4.1. The construction deliberately leaves its DKG or VSS realization modular and does not present the prototype’s centralized Feldman or Pedersen algebra as malicious-secure distributed key generation. Accordingly, setup availability, latency, and dealer-freedom depend on the external realization selected for deployment.

5.6. Static Security Within a Fixed Mission Epoch

The inherited argument permits at most f < t parties to be corrupted before setup and assumes the corrupted set remains fixed for the epoch. This is a well-defined baseline for a fixed committee and bounded mission epoch, but it does not model an adversary that captures different UAVs over time and accumulates their shares. A membership change starts a new epoch with fresh long-term material and a fresh presignature inventory; shortening epochs can limit exposure but does not itself prove adaptive security.
Long-duration deployment under cumulative physical compromise would require a separately analyzed mechanism such as proactive share refresh, adaptively secure VSS/MPC, forward-secure state evolution, or protected hardware erasure. These mechanisms introduce communication, storage, recovery, and proof obligations and are neither implemented nor claimed here.

5.7. Public Verification and the Safety–Liveness Boundary

Verification of the final SRTS signature is constant in n and t and uses the pairing-free Schnorr equation. This describes final-output verification only: a standalone threshold-BLS beacon or BLS-backed consensus service still incurs BLS12-381 operations before SRTS signing begins.
Public verification shares allow a combiner to reject malformed responses and the final equation prevents acceptance of an invalid aggregate. These are safety properties. They do not guarantee progress: liveness additionally requires at least t responsive valid signers, consistent persistent state, and terminating DKG/VSS/ACS and consensus/finalization services.

6. Security Analysis

In this section we identify the signature-level attack game inherited from Shoup [3].

6.1. Security Model

The adversary statically corrupts a set C of at most f parties before setup, where f < t , n > 3 f , Q = n f , and P = n 2 f . It learns the corrupted long-term and ephemeral shares, controls corrupted messages and scheduling, may withhold responses, and may choose corrupted dealers’ ephemeral inputs after observing the honest public inputs.
The conditional distributed interpretation assumes the following ideal or securely realized services:
(i)
the long-term key-generation interface of Section 4.1, with a uniformly distributed group signing scalar as required by Shoup’s attack game;
(ii)
verifiable input sharing and local linear operations over consistent shares, together with agreement on a single ordered set I = ( i 1 , , i Q ) ;
(iii)
Consensus safety and persistence for one assignment is fixed while the slot is available and before certificate revelation A = ( requestID , m , batchID , k ) ;
(iv)
A unique, unpredictable, publicly verifiable certificate with a reconstruction threshold t β = n f ; and
(v)
durable one-use state that never releases shares for two assignments of the same slot.
For the inherited signature-level argument, the domain-separated functions H δ and H c are modeled as independent random oracles with range Z N . The transcript functions H batch , H assignment , and H beacon are treated as collision-resistant canonical transcript bindings; alternatively, all five may be represented as independent domain-separated random oracles. The concrete implementation uses SHA-256 with length-prefixed inputs and reduction modulo N; treating this as a random oracle into Z N abstracts the small modulo-reduction bias and the usual concrete hash assumption, both of which must be included in a concrete instantiation analysis.

6.2. Existential Unforgeability Under Chosen-Message Attacks

We formalize here the signature security of SRTS as existential unforgeability under chosen-message attacks (EUF-CMA). The experiment extends the standard EUF-CMA game to include static corruption, batch-extracted biased presignatures, certificate-derived rerandomization, and one-use presignature slots.
Definition 8 
(SRTS EUF-CMA experiment).
Let Ch denote the challenger and let A be a probabilistic polynomial-time adversary.
Setup.Before setup, A statically selects a corrupted set
C P , | C | f < t .
The challenger executes the long-term threshold key-generation interface
D , { ( d i , D i ) } i = 1 n KeyGen t , n ( pp , P ) , D i = [ d i ] G .
It gives A the public state
st pub = pp , D , { D i } i = 1 n , vk β
and the long-term shares of the corrupted parties,
st C = { d i : P i C } .
The signing scalar d satisfying D = [ d ] G is never given to A or reconstructed by the protocol.
Presignature-batch queries.The adversary may make many presignature-batch queries. For batch number b, the challenger executes Algorithm 1 and obtains
Batch ( b ) = batchID ( b ) , I ( b ) , { R ¯ k ( b ) } k = 1 P ,
where
I ( b ) = ( i 1 ( b ) , , i Q ( b ) ) , Q = n f .
The challenger gives A the public batch state
st batch ( b ) = Batch ( b ) , { R ¯ k , i ( b ) } k [ P ] i [ n ]
and the extracted shares held by corrupted parties,
r ¯ k , i ( b ) : k [ P ] , P i C .
During generation of batch b, A observes the honest public ephemeral inputs
R i ( b ) = [ r i ( b ) ] G
and may choose the inputs of corrupted dealers after observing these values. Let
r ¯ ( b ) = ( r ¯ 1 ( b ) , , r ¯ P ( b ) ) T
denote the extracted presignature-scalar vector. Its adversarial bias must admit the representation
r ¯ ( b ) = U ( b ) r H ( b ) + u ( b ) ( mod N ) ,
where r H ( b ) contains the selected honest ephemeral inputs, U ( b ) has full row rank P, and u ( b ) is the affine offset induced by corrupted inputs. This is the full-rank bias condition used in Shoup’s combined game.
Signing queries.The adversary may also make many signing queries. A signing query has the form
A = requestID , m , batchID ( b ) , k ,
where slot k of batch b is in state AVAILABLE . The ideal assignment service first irrevocably commits A and changes the slot state to ASSIGNED . It computes
a = H assignment requestID , m , batchID ( b ) , enc 8 ( k )
and
μ β = H beacon ( a ) .
Only after the assignment is committed does the finalization service reveal the unique certificate
β = ( μ β , σ β , S β ) , | S β | t β = n f ,
which verifies under vk β . The challenger then derives
δ = H δ σ β , D , batchID ( b ) , enc 8 ( k ) , requestID , m mod N ,
sets
R = R ¯ k ( b ) + [ δ ] G , h = H c ( D , R , m ) mod N ,
and returns the resulting Schnorr signature
σ = ( R , z ) , z = r ¯ k ( b ) + δ + h d ( mod N ) .
The slot is then permanently marked CONSUMED and cannot be used in another signing query.
Forgery.Finally, A outputs
( m , σ ) , σ = ( R , z ) .
The adversary wins if
Verify ( D , m , σ ) = Accept ,
equivalently, if, for h = H c ( D , R , m ) mod N ,
[ z ] G = R + [ h ] D ,
and m was not the message of any previous successful signing query.
For a probabilistic polynomial-time adversary A , define its SRTS EUF-CMA advantage by
Adv SRTS euf cma ( A ) : = Pr Exp SRTS euf cma ( A ) = 1 ,
where the probability is taken over the randomness of the challenger, the honest parties, the assumed ideal services, and the random oracles. We say that SRTS is conditionally EUF-CMA secure in the rerandomized biased-presignature model if this advantage is negligible for every probabilistic polynomial-time adversary satisfying the corruption bound in Section 6.1.
Corollary 1 
(Conditional EUF-CMA security of SRTS). Assume that:
(i)
at most f < t parties are statically corrupted;
(ii)
the long-term DKG, verifiable input-sharing, ACS, consensus, finalization, and one-use-state services satisfy the requirements of Section 6.1;
(iii)
for every batch b, the honest-column submatrix U ( b ) of the extraction matrix has row rank P;
(iv)
every assignment A is irrevocably committed before its unique certificate β becomes predictable;
(v)
every presignature slot is used at most once; and
(vi)
H c , H δ : { 0 , 1 } * Z N are independent random oracles.
Then the experiment of Definition 8 maps to Shoup’s enhanced attack game for batch randomness extraction with rerandomized presignatures. Consequently, in the EC-GGM and the random-oracle model,
Adv SRTS euf cma ( A ) = O q qry 2 N + q qry M c ,
where q qry bounds the adversary’s total relevant query budget and M c = | Range ( H c ) | . When Range ( H c ) = Z N , this simplifies to O ( q qry 2 / N ) .
Proof 
(Mapping to Shoup’s enhanced attack game). The agreed honest ephemeral inputs are uniform, while corrupted inputs may depend on their public values. Because every P-column submatrix of W is nonsingular and I contains at least Q f = P honest inputs, let H ( b ) denote the positions of the honest dealers in I ( b ) and set U ( b ) = W [ : , H ( b ) ] . This matrix has row rank P and gives the honest linear component required by Shoup’s bias model; corrupted columns contribute the adversarial affine offset u ( b ) . Algorithm 1 therefore realizes the fixed-P instance of the batch-bias interface in Shoup’s Section 4.1.
For a signing request, A and its unused slot are fixed before the unique certificate signature becomes predictable. On the corresponding fresh H δ input, the derived δ has the ideal random-shift distribution, and R = R ¯ k + [ δ ] G . The slot is then removed permanently, and H c ( D , R , m ) supplies the Schnorr challenge. These are precisely the full-rank bias, fresh random-beacon rerandomization, and one-use conditions of the enhanced attack game. SRTS uses a distinct shift for each assigned request and is therefore a special case of that game.
Shoup’s Section 4.2 gives the random-oracle reduction for this combined mode, while the EC-GGM analysis summarized in Section 4.3.1 inherits the concrete bound of Shoup’s Theorem 2. Appendix C.3 describes its threshold realization using a random beacon, and Appendix C.3.1 gives the consensus-piggybacked unique-threshold-signature interpretation used by the primary SRTS scenario. Therefore a successful adversary in Definition 8 induces an adversary in Shoup’s game with the stated EC-GGM+ROM bound.
The mapping is conditional on the ideal services. Replacing them by real protocols adds their distinguishing advantages or failure probabilities.    □
For bookkeeping, if ε ext denotes the sum of the failure or distinguishing terms of the selected key-generation, VSS/MPC, ACS, finalization, one-use storage, transcript-binding, and hash-to-scalar realizations, a real-system statement can only have the schematic form
Adv SRTS , real euf Adv Shoup CMA - BRE + ε ext .
No concrete value for ε ext is claimed until those services are instantiated and analyzed.

6.3. Conditional Share Confidentiality

Share confidentiality is inherited from the assumed long-term DKG and ephemeral input-sharing functionalities; it is not a separate security property proved by the SRTS signing layer. For a fixed corrupted set C with | C | < t , degree- ( t 1 ) Shamir shares held by C reveal no additional information about the shared scalar beyond the prescribed public transcript and outputs of the sharing functionality. Local linear extraction preserves the sharing degree and therefore does not lower the reconstruction threshold.
This statement is information-theoretic only for the Shamir shares considered without public scalar commitments. In the complete construction, the public points D = [ d ] G , D i = [ d i ] G , R ¯ k = [ r ¯ k ] G , and the Feldman-style coefficient commitments hide their corresponding scalars computationally under the discrete-logarithm assumption. The statement also assumes protected honest-party storage and does not cover mobile corruption, side-channel leakage, rollback, or the accumulation of t shares over time.

6.4. Security-Critical Rerandomization and One-Use

The following results isolate the ordering and persistent-state assumptions used in Corollary 1.
Lemma 1 
(Conditional fresh-shift property). Suppose an unused slot and its complete assignment are irrevocably fixed before the unique certificate signature is predictable. If the resulting input to the independent random oracle H δ has not previously been queried, then δ is fresh in Z N from the adversary’s view at assignment time and R = R ¯ k + [ δ ] G has the shifted distribution required by Shoup’s game.
Ordering alone is insufficient: naming a public hash a beacon does not make its input unpredictable. Certificate prediction, equivocal assignments, transcript collisions, or pre-querying the eventual H δ input must be excluded or charged to the corresponding external failure term.
Proposition 2 
(Nonce reuse remains fatal). If the same presignature scalar r ¯ is used in two accepted transcripts with distinct challenges h 1 h 2 , then public rerandomization does not protect the signing key. From z j = r ¯ + δ j + h j d , j { 1 , 2 } , one computes
d = ( z 1 z 2 δ 1 + δ 2 ) ( h 1 h 2 ) 1 mod N .
Therefore, persistent non-reuse is mandatory.

6.5. Malformed-Share Detection and Liveness Limitations

Given authenticated signer identities and the verification shares D i = [ d i ] G and R ¯ k , i = [ r ¯ k , i ] G , the combiner rejects a response ( i , z i ) unless
[ z i ] G = R ¯ k , i + [ δ ] G + [ h ] D i .
It aggregates only t distinct responses satisfying this equation and accepts the aggregate only if the final Schnorr verification equation holds. This provides malformed-share detection and prevents an invalid response from corrupting an accepted aggregate. Within an authenticated protocol, the failed check also identifies the signer index associated with the rejected response, but it does not by itself provide public nonrepudiation or a punishment mechanism.
These checks do not guarantee availability. Corrupted or unavailable parties may withhold responses, and signing cannot complete unless at least t valid responses arrive. A responsive selected set uses O ( t ) signer-to-combiner transmissions, while committee-wide fallback may solicit up to O ( n ) responses. If fewer than t valid shares arrive, or an assumed service fails to terminate, the safe outcome is to abort while keeping the assigned slot permanently unavailable for reuse.

7. Performance Evaluation

This section evaluates SRTS prototype with respect to cryptographic computation, modeled network behavior, analytical message accounting, and external service assumptions. Only cryptographic computation is measured directly on the recorded host. Network delay and completion status are outputs of the deterministic simulator, whereas rounds, transmissions, and encoded byte counts are derived from analytical protocol traces. The consensus assignment and unique finalization certificate required by the primary SRTS view are treated as external assumptions and therefore contribute neither measured computation nor modeled network delay to that view. Consequently, results from these components must not be combined or interpreted as measurements of end-to-end latency, availability, or energy consumption in a deployed UAV system.

7.1. Implementation, Boundaries, and Experimental Design

SRTS, FROST, and MuSig2 use secp256k1 through coincurve, which invokes native libsecp256k1 operations. tBLS and the optional SRTS beacon use BLS12-381 through the pure-Python py-ecc backend. The SRTS code centrally executes share creation and checking, qualification, batch extraction, slot transitions, and signing in one Python process. It does not implement mutually distrustful executions of malicious-secure DKG/VSS/MPC, ACS, Byzantine consensus, or crash-safe persistent storage. Experiments ran under Python 3.11.15 on the recorded arm64 macOS host.
We evaluate n { 3 , 5 , 10 , 20 , 50 , 100 } , set f = ( n 1 ) / 3 , and use Q = n f completed inputs and P = n 2 f one-use SRTS slots. Flexible-threshold protocols are tested with strict-Shoup t = f + 1 , majority t = ( n + 1 ) / 2 , and high t = n f profiles. Ordinary MuSig2 is evaluated only at t = n . Each cryptographic cell has five excluded warmups followed by 30 measurements with secure, unseeded cryptographic randomness.
For a signer stage, participants are modeled as executing in parallel, so that stage contributes the slowest measured signer rather than the sum of all signers. The estimated distributed critical path sums these slowest-signer stages and sequential coordinator stages. Total work instead sums every measured signer and coordinator operation. This accounting avoids equating serial Python execution with distributed latency, but it cannot capture scheduling, contention, or heterogeneous UAV processors.
More precisely, let S and C be the ordered signer and coordinator phases, and let T ϕ , i be signer i’s measured time in signer phase ϕ . The two reported computation views are
W = ϕ S i I ϕ T ϕ , i + ϕ C T ϕ , C = ϕ S max i I ϕ T ϕ , i + ϕ C T ϕ ,
where W is total work and C is the estimated distributed critical path. For a selected quorum of size t, the SRTS online signer work is O ( 1 ) per selected UAV, coordinator share checking and aggregation are O ( t ) , final Schnorr verification is O ( 1 ) , and the response payload and number of response transmissions are O ( t ) . These bounds describe the post-finalization cryptographic path, not the excluded agreement services or offline construction.
Because the evaluated schemes do not begin from identical lifecycle states, Table 4 records the exact start of each reported online timing and the material excluded from it. In the “Signers” column, x / y means that x responses are required from a committee of y parties

7.2. Post-Finalization Online Computation

In Figure 1, the left panel sums all measured participant and coordinator work, whereas the right panel estimates the distributed critical path by treating signer computations within a stage as parallel. Both panels use a logarithmic vertical scale. Under the stated boundaries, all implementations require more computation as n increases; SRTS remains below the native FROST and MuSig2 paths, while the much higher tBLS curve primarily reflects the evaluated pure-Python py-ecc backend.
As Table 5 shows, at n = 100 , where f = 33 , t = 51 , and P = 34 , the post-finalization SRTS median is 34.89% below preprocessed FROST. It is 59.01% below ordinary 100-of-100 MuSig2. Thirty observations permit reporting an empirical p95 but are insufficient for a credible p99 estimate or a deadline guarantee.
The separately retained tBLS diagnostic has a median critical path of 27 , 143.428396  ms, p95 of 27 , 422.522510  ms, median total work of 34 , 998.476313  ms, one induced response round, and 51 transmissions. This result characterizes the selected pure-Python py-ecc adapter. It is not used to claim that SRTS is faster than an optimized tBLS implementation. Such a comparison requires a native BLS12-381 threshold implementation measured on the same host and with the same accounting rules.
Figure 2 compares the measured signer critical path as the reconstruction threshold changes from the strict-Shoup setting t = f + 1 , through the majority setting t = ( n + 1 ) / 2 , to the high setting t = n f . The comparison applies only to implementations with a configurable threshold t-of-n (not including MuSig2). Thus, higher t increases signer and coordinator verification work for all three flexible-threshold implementations. Changing t does not change the SRTS corruption constraint f < n / 3 or its batch size P = n 2 f .

7.3. Centralized Setup and Recurring Offline Work

In Figure 3, the left panel reports the median total cost of preparing one recurring offline batch as the committee size n increases, whereas the right panel reports the corresponding amortized cost per one-use slot after division by the common inventory size P = n 2 f . tBLS is absent from both panels because it does not use a signing-nonce inventory. Figure 4 instead reports the centralized one-time or epoch-level key-setup workloads exercised by the evaluated implementations.
Table 6 gives the exact n = 100 medians underlying the setup and recurring-offline comparisons, including the number of one-use records in the SRTS batch.
The short SRTS response path is purchased with substantial finite preprocessing. At n = 100 , SRTS needs a median 57.82 s to produce 34 slots, or 1.70066 s per slot. The corresponding prototype medians are 6.48 ms per FROST nonce record and 6.77 ms per MuSig2 nonce record, making SRTS about 262 and 251 times more expensive per offline record, respectively. The 45.55 s SRTS setup value is centralized share-generation/checking algebra plus beacon key setup, not a measurement of a distributed malicious-secure DKG.
Table 7 decomposes the measured SRTS batch cost into ephemeral VSS creation and checking, modeled ACS selection and rechecking, and Vandermonde extraction with verification-share generation. It shows where this implementation spends time. We didn’t separate elliptic-curve operation counts from other code operations. In particular, the modeled ACS path rechecks candidate deals in the same process. Because no distributed VSS/ACS message exchange is implemented, the artifact supplies neither offline radio bandwidth nor deployed offline latency.

7.4. Storage Costs

The following storage estimates are based on encoded cryptographic payloads. They assume 32-byte scalars, 33-byte compressed secp256k1 points, (n=100), (Q=67), and (P=34).
Table 8 applies these assumptions to the secret, public, and metadata components of one SRTS batch and identifies where each component is intended to reside.
Each UAV requires at least 1,120 bytes of secret scalar per batch, of which 32 bytes correspond to its long-term share. This lower bound excludes assignment records, secret-consumption tracking, rollback protection, storage-system overhead, replicas, and erasure mechanisms. The prototype stores all participants’ batch secrets in centralized dictionaries and deletes them once used. It does not implement isolated per-UAV storage or protection against secret reuse following a crash.
Let T batch denote the median time to generate P new slots and let λ be the command-signing demand in requests per second. The observed single-process provisioning rate and the no-restoration drain cost are
μ prov = P T batch = 34 57.8226 0.588 slots / s , T drain = P λ .
A 1-request/s workload drains 34 slots in 34 s, which is faster than this prototype produces the next batch; at 0.5 request/s, the nominal drain time is 68 s. These are capacity illustrations, not mission demand measurements. Sustainable pre-provisioning would require x plus the ability to overlap the real distributed offline service with signing. Thus, when the adapter has no available slot, it rejects the signing attempt rather than reusing consumed state.

7.5. Modeled Network Behavior

The network models messages within a round concurrently and rounds sequentially, using configured latency, jitter, bandwidth, packet loss, retry, and timeout parameters, but we exclude correlated fading, interference, shared-medium contention, mobility, routing changes, and a deployed Byzantine consensus service. Figure 5 compares the simulated delay of successful online traces across the different network profiles and committee sizes. It isolates network delay from cryptographic computation and from any external consensus or beacon service.
Under the satellite profile and n = 100 , the median successful trace delay is 1.679 s for SRTS, 1.688 s for tBLS, 2.292 s for FROST, and 3.430 s for MuSig2. This ordering follows the one-round versus two-round trace structure and serialized payloads. Figure 6 complements the successful-trace latency results by reporting how often each protocol trace completes under the stated independent-loss and retry model, with error bars are Wilson 95% intervals over 1,000 paired-seed trials.
With the configured retries at 5% independent loss, SRTS and tBLS complete 1,000/1,000 trials, while FROST and MuSig2 complete 999/1,000. The Wilson intervals overlap, so this one-event difference does not support a robustness advantage. It reports only the behavior of the stated simulator, trace boundaries, and retry policy.

7.6. Communication Cost and Beacon Boundary

Figure 7 shows how induced online rounds, transmissions, and encoded application payload scale after the common committed request. Table 9 then gives the exact n = 100 payload totals under coordinator unicast and under the analytical single-copy-package view, making the accounting assumption behind each byte comparison explicit.
Under coordinator unicast, SRTS uses 99.31% fewer encoded payload bytes than FROST and 99.75% fewer than MuSig2. If each identical coordinator package is counted once, the corresponding differences are approximately 73.7% and 83.0%. SRTS uses 64.0% fewer payload bytes than tBLS in both views. It also has half as many unicast transmissions as FROST and 74.5% fewer than MuSig2. These are application-payload calculations: real wireless multicast requires a radio- and link-layer-specific treatment of headers, reliability, retransmission, contention, and receiver diversity.
To expose the cost hidden by the primary post-finalization boundary, Figure 8 separates SRTS signature-share computation from an optional standalone tBLS beacon and compares the resulting critical paths across committee sizes.
In Figure 8, the left panel decomposes the standalone integration into its tBLS beacon and Schnorr components, while the right panel compares that integration with the primary post-finalization computational cost. The beacon component dominates the evaluated standalone path at every committee size. The primary scope accepts a consensus-supplied assignment and unique finalization certificate; it does not generate a standalone beacon. In the separate standalone scenario, beacon shares, aggregation, certificate delivery, and Schnorr shares induce three rounds after the common-request boundary. At n = 100 , the standalone median critical path is 2,338.94 ms (median 95% CI [ 2 , 328.02 , 2 , 371.17 ] ms), and its empirical p95 is 2,438.845 ms. This is 299.50 times the 7.81 ms primary median, with the beacon contributing for 99.665% of the median per-observation fraction. Thus “post-finalization single round” denotes the post-finalization signature-share response, not end-to-end consensus, beacon generation, and signing.

7.7. UAV Deployment Interpretation and Limitations

The evaluation demonstrates the behavior of a cryptographic component prototype under explicit synthetic conditions. It does not validate a deployable UAV security system. Table 10 makes the remaining gaps operationally explicit.
SRTS is attractive only when the deployment already produces a qualifying unique finalization certificate and can safely maintain unused one-use inventory. In that boundary, it returns an ordinary pairing-free Schnorr signature after one response round and has a short measured native secp256k1 component path. It does not have a round-count advantage over tBLS, and the present evidence cannot compare its speed with an optimized BLS12-381 threshold implementation. Its offline workload and persistent one-use state also create lifecycle costs absent from tBLS.

8. Discussion

SRTS is most plausible when a swarm already produces a qualifying unique finalization certificate, can provision presignatures before demand, and can enforce atomic one-time consumption. In that setting, the selected UAVs send only response shares after finalization, and the verifier receives an ordinary Schnorr-form signature. When those services or the protected inventory are unavailable, the short measured response path does not describe the whole system. The alternatives expose the decision boundary. On the one hand, preprocessed FROST requires an additional online delivery stage under this paper’s common boundary. Still, its preprocessing records are much cheaper in the evaluated implementation, and its established design may simplify deployment. On the other hand, tBLS has the same one-response-round structure and no per-command Schnorr nonce inventory, at the cost of pairing-friendly-curve operations and a different signature ecosystem. The present pure-Python tBLS timings cannot rank that alternative against native secp256k1 code. MuSig2 is a useful all-signers reference, but its (n)-of-(n) policy is not a substitute for a Byzantine-tolerant threshold policy. Moreover, the evaluation separates feasibility from deployment. It demonstrates the centralized execution of the cryptographic operations, state transitions, response timing, encoded payload cost, and behavior of deterministic network traces. It does not demonstrate mutually distrustful DKG/VSS/MPC or ACS executions, Byzantine consensus latency, crash-safe erasure, adaptive-corruption security, embedded-UAV energy use, or performance under correlated radio loss and mobility. Consequently, the reported milliseconds and synthetic-network outcomes should be read as reproducible prototype results, not tactical-system bounds.

9. Conclusions

This paper specifies and evaluates SRTS, a Shoup-aligned, batch-extracted threshold Schnorr construction that assigns each presignature slot before revealing a unique finalization certificate. Its main contribution is a concrete secp256k1 prototype with explicit one-use state management and a reproducible comparison with FROST, tBLS, and MuSig2. At n = 100 , post-finalization SRTS achieved a 7.81 ms median critical path, compared with 11.99 ms for FROST and 19.05 ms for MuSig2, while requiring one response round and 51 transmissions. Moreover, its final signature is a standard, pairing-free Schnorr signature. However, this online advantage requires expensive preprocessing: 57.82 s for 34 slots, or 1.70 s per slot. In addition, standalone beacon integration increased the median critical path to 2.34 s, while the tBLS results remain backend-specific diagnostics. Therefore, SRTS offers low post-finalization latency and communication at the cost of finite presignature storage, secure one-time state management, and reliance on assumed DKG, ACS/MPC, consensus, and finalization services. Future work should instantiate these services and evaluate the complete system on representative UAV hardware and networks.

Author Contributions

Conceptualization, A.A.H., M.E.M. and A.Y.; methodology, A.A.H. and M.E.M.; software, A.A.H.; validation, A.A.H., M.E.M. and A.Y.; formal analysis, A.A.H. and M.E.M.; investigation, data curation and visualization, A.A.H.; writing—original draft preparation, A.A.H.; writing—review and editing, M.E.M., A.Y., A.E.H. and A.B.; supervision, M.E.M., A.Y., A.E.H. and A.B. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

The implementation, experiment configurations, derived plot data, manifests, and sealed raw results supporting this study are available from the corresponding author on reasonable request and will be released through a public GitHub repository. The repository URL and archived release identifier will be added after the sanitized publication package has been deposited.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
ACS Asynchronous Common Subset
BLS Boneh–Lynn–Shacham
DKG Distributed Key Generation
EC-GGM Elliptic-Curve Generic-Group Model
FROST Flexible Round-Optimized Schnorr Threshold signatures
GCS Ground Control Station
MPC Multi-Party Computation
ROM Random-Oracle Model
SRTS Single-Round Threshold Schnorr
UAV Unmanned Aerial Vehicle
VSS Verifiable Secret Sharing

References

  1. Boneh, D.; Lynn, B.; Shacham, H. Short signatures from the Weil pairing.
  2. Komlo, C. FROST: Flexible Round-Optimized Schnorr Threshold Signatures. [CrossRef]
  3. Shoup, V. The many faces of Schnorr: a toolkit for the modular design of threshold Schnorr signatures. IACR Commun. Cryptol. 2025, 2. [Google Scholar] [CrossRef]
  4. He, L.; Gan, Y.; Zhang, Y. Attribute-Based Proxy Signature Scheme Supporting Flexible Threshold Predicate for UAV Networks. Electronics 2023, 12, 4854. [Google Scholar] [CrossRef]
  5. He, L.; Gan, Y.; Yin, Y. Efficient Threshold Attribute-Based Signature Scheme for Unmanned Aerial Vehicle (UAV) Networks. Electronics 2025, 14, 339. [Google Scholar] [CrossRef]
  6. He, L.; Gan, Y.; Jin, S. Expressive Attribute-Based Proxy Signature Scheme for UAV Networks. Sensors 2026, 26, 55. [Google Scholar] [CrossRef] [PubMed]
  7. Teng, L.; Jianfeng, M.; Pengbin, F.; Yue, M.; Xindi, M.; Jiawei, Z.; Gao, C.; Di, L. Lightweight Security Authentication Mechanism Towards UAV Networks. In Proceedings of the 2019 International Conference on Networking and Network Applications (NaNA), 2019; pp. 379–384. [Google Scholar] [CrossRef]
  8. Usman, M.; Amin, R.; Aldabbas, H.; Alouffi, B. Lightweight Challenge-Response Authentication in SDN-Based UAVs Using Elliptic Curve Cryptography. Electronics 2022, 11, 1026. [Google Scholar] [CrossRef]
  9. Kou, G.; Wei, G.; Yuan, Z.; Li, S. Latin-Square-Based Key Negotiation Protocol for a Group of UAVs. Electronics 2023, 12, 3131. [Google Scholar] [CrossRef]
  10. Choe, H.; Kang, D. ECC-Based Authentication Protocol for Military Internet of Drone (IoD): A Holistic Security Framework. IEEE Access 2025, 13, 21503–21519. [Google Scholar] [CrossRef]
  11. Rebolo, T.; Grilo, A.; Ribeiro, C. Secure Command, Control and Communications Systems (C3) for Army UxVs, 2025. [CrossRef]
  12. Sysoyev, A.; Nauruzov, K.; Karati, A.; Abramkina, O.; Vitulyova, Y.; Yeskendirova, D.; Popova, Y.; Abdoldina, F. Lightweight Group Signature Scheme Based on PUF for UAV Communication Security. Drones 2025, 9, 693. [Google Scholar] [CrossRef]
  13. Choi, J.; Yoon, S.; Seo, S.C. Optimized Falcon Verify on Cortex-M4 for Post-Quantum secure UAV communications. ICT Express 2025, 11, 281–286. [Google Scholar] [CrossRef]
  14. Li, L.; Zhang, H.; Li, S.; Liu, J.; Chen, C. A Lightweight Batch Authenticated Key Agreement Scheme Based on Fog Computing for VANETs. 2025. [Google Scholar] [CrossRef]
  15. Pu, C.; Warner, C.; Choo, K.K.R.; Lim, S.; Ahmed, I. liteGAP: Lightweight group authentication protocol for internet of drones systems. IEEE Trans. Veh. Technol. 2023, 73, 5849–5860. [Google Scholar] [CrossRef]
  16. Zhao, Z.; Hsu, C.; Harn, L.; Xia, Z.; Jiang, X.; Liu, L. Lightweight ring-neighbor-based user authentication and group-key agreement for internet of drones. Cybersecurity 2024, 7, 50. [Google Scholar] [CrossRef]
  17. Boldyreva, A. Threshold signatures, multisignatures and blind signatures based on the gap-diffie-hellman-group signature scheme. In Proceedings of the PKC. Springer; Lecture notes in computer science, 2003; Vol. 2567, pp. 31–46. [Google Scholar] [CrossRef] [PubMed]
  18. Nick, J.; Ruffing, T.; Seurin, Y. MuSig2: Simple Two-Round Schnorr Multi-Signatures, 2020. Publication info: A major revision of an IACR publication in CRYPTO 2021. [PubMed]
  19. Rochford, P.; Buchanan, W.J.; Macfarlane, R.; Tehrani, M.G. Securely Scaling Autonomy: The Role of Cryptography in Future Unmanned Aircraft Systems (UAS). 2025. [Google Scholar] [CrossRef]
  20. Pointcheval, D.; Stern, J. Security arguments for digital signatures and blind signatures. J. Cryptology. J. Int. Assoc. Cryptologic Res. 2000, 13, 361–396. [Google Scholar] [CrossRef]
Figure 1. Measured online cryptographic work and estimated distributed critical path according to Table 4.
Figure 1. Measured online cryptographic work and estimated distributed critical path according to Table 4.
Preprints 229218 g001
Figure 2. Measured critical-path sensitivity under strict-Shoup
Figure 2. Measured critical-path sensitivity under strict-Shoup
Preprints 229218 g002
Figure 3. Recurring offline preprocessing.
Figure 3. Recurring offline preprocessing.
Preprints 229218 g003
Figure 4. Centralized setup workloads.
Figure 4. Centralized setup workloads.
Preprints 229218 g004
Figure 5. Modeled successful online network delay under configured retries.
Figure 5. Modeled successful online network delay under configured retries.
Preprints 229218 g005
Figure 6. Modeled completion at n = 100 under independent packet loss.
Figure 6. Modeled completion at n = 100 under independent packet loss.
Preprints 229218 g006
Figure 7. Protocol-induced communication after the common committed request.
Figure 7. Protocol-induced communication after the common committed request.
Preprints 229218 g007
Figure 8. SRTS signing separated from optional standalone beacon cost.
Figure 8. SRTS signing separated from optional standalone beacon cost.
Preprints 229218 g008
Table 1. Summary of notation used throughout the paper.
Table 1. Summary of notation used throughout the paper.
Symbol Meaning
G = G , N, Z N Prime-order group, generator, group order, and scalar field
n, P Number and set of UAV signing parties P = { P 1 , , P n }
f, C Static corruption bound and corrupted set, | C | f
t, S Schnorr reconstruction threshold and active signer set, | S | = t
t β = n f Reconstruction threshold required of the finalization/beacon certificate in the prototype
Q = n f , P = n 2 f Agreed ephemeral inputs and extracted one-use slots per batch
I = ( i 1 , , i Q ) Ordered common set of completed ephemeral-input dealers
W Z N P × Q Public super-invertible extraction matrix
d, D = [ d ] G Group signing scalar and public key
d i , D i = [ d i ] G Long-term secret share and public verification share of P i
r ¯ k , R ¯ k = [ r ¯ k ] G Extracted slot-k presignature scalar and public point
r ¯ k , i , R ¯ k , i = [ r ¯ k , i ] G Secret and public verification shares for node P i , slot k
batchID Identifier binding parameters, public key, dealer set, and public slots
A Consensus-committed assignment A = ( requestID , m , batchID , k )
β = ( μ β , σ β , S β ) Finalization certificate: signed digest, unique signature, and signer IDs
δ , R = R ¯ k + [ δ ] G Certificate-derived rerandomization scalar and effective nonce
h, z, σ = ( R , z ) Schnorr challenge, response scalar, and final signature
λ i , S Lagrange coefficient of P i at zero for signer set S
Table 2. Public, secret, and persistent state by lifetime.
Table 2. Public, secret, and persistent state by lifetime.
Lifetime/class State Required property
Epoch public pp , D , { D i } , beacon verification key Authenticated agreement on committee, parameters, and keys
Batch public I , { R ¯ k } , { R ¯ k , i } , batchID Same ordered qualified set and batch transcript at honest nodes
Request public A , β , δ , R , h , σ Assignment finalized before certificate revelation; public verification
Per-UAV secret d i , { r ¯ k , i } Confidential storage; no reconstruction outside prescribed operations
Persistent one-use state AVAILABLE ASSIGNED CONSUMED ; bound assignment Atomic update, rollback protection, crash recovery; reject reuse
Table 3. Comparison of SRTS, FROST  [2], tBLS [17], and MuSig  [18]
Table 3. Comparison of SRTS, FROST  [2], tBLS [17], and MuSig  [18]
Feature SRTS FROST MuSig2 tBLS
Signer model Flexible t-of-n, conditional on external setup/services Flexible t-of-n Ordinary construction is n-of-n Flexible t-of-n
Interaction relevant here One signer-to-combiner response stage after assignment and a qualifying certificate Two-round signing protocol; preprocessing may move nonce generation off the request path Two-round signing protocol with optional nonce preprocessing One signature-share response stage once the message is fixed
One-use secret state One extracted presignature share per slot; durable non-reuse required Per-signature nonce material; non-reuse required Per-signature nonce material; non-reuse required No Schnorr-style signing nonce inventory
Public output Ordinary Schnorr pair under the group key Ordinary Schnorr-family signature Ordinary Schnorr-family multisignature BLS signature
Final verification One Schnorr equation; independent of n , t One Schnorr equation; independent of n , t One Schnorr equation; independent of n Pairing-based verification; independent of n , t after combination
Key setup in this paper Assumed secure long-term key-generation interface External trusted sharing or DKG realization Public-key aggregation with rogue-key defenses External trusted sharing or DKG realization
Table 4. Primary n = 100 timing boundaries. The tBLS row is retained as a backend diagnostic, not included in the primary speed ranking.
Table 4. Primary n = 100 timing boundaries. The tBLS row is retained as a backend diagnostic, not included in the primary speed ranking.
Scheme Curve/backend Signers Measured start Out of scope
SRTS secp256k1/coincurve 51/100 Finalized assignment and certificate available Real DKG/VSS/MPC, ACS, consensus, certificate generation, and durable state
FROST secp256k1/coincurve 51/100 Nonce pairs preprocessed Setup and nonce generation
MuSig2 secp256k1/coincurve 100/100 Nonce pairs preprocessed Key aggregation and nonce generation
tBLS diagnostic BLS12-381/py-ecc 51/100 Cold share signing Key setup; backend is not performance-comparable with native libsecp256k1
Table 5. Primary native-secp256k1 implementation results at n = 100 .
Table 5. Primary native-secp256k1 implementation results at n = 100 .
Scheme/accounting scope Median critical path (ms) 95% CI (ms) p95 (ms) Median total work (ms) Induced rounds Transmissions
SRTS/post-finalization 7.809584 [7.764104, 7.919791] 8.085019 7.890939 1 51
FROST/preprocessed 11.994979 [11.909668, 12.233229] 15.065481 13.804334 2 102
MuSig2/preprocessed 19.053167 [18.986541, 19.118874] 22.614238 21.843624 2 200
Table 6. Setup and recurring offline medians at n = 100 .
Table 6. Setup and recurring offline medians at n = 100 .
Implementation Setup (ms) Offline batch (ms) Per record (ms)
SRTS/coincurve 45,549.05 57,822.58 1,700.66
FROST/coincurve 230.44 220.43 6.48
tBLS/py-ecc diagnostic 27,687.76 N/A N/A
MuSig2/coincurve 8.14 230.14 6.77
Table 7. Recorded SRTS offline phase medians at n = 100 .
Table 7. Recorded SRTS offline phase medians at n = 100 .
Centralized implementation phase Median (s) Share of phase-median sum
Ephemeral VSS creation and checking 22.888 39.6%
In-process ACS selection and rechecking 22.651 39.2%
Vandermonde extraction and verification shares 12.253 21.2%
Table 8. Minimum raw payload represented by one SRTS batch at n = 100 .
Table 8. Minimum raw payload represented by one SRTS batch at n = 100 .
Material Calculation Bytes Intended placement
One UAV’s one-use secret shares 34 × 32 1,088 Only that UAV; erase/burn one scalar per request
All one-use secret shares 100 × 34 × 32 108,800 Distributed across UAVs; held centrally only by the prototype
Public verification-share matrix 100 × 34 × 33 112,200 Coordinator/verifier or replicated public state
Public slot nonces 34 × 33 1,122 Public batch state
Batch identifier and dealer identifiers 32 + 67 × 4 300 Public batch metadata
Table 9. Payload views at n = 100 .
Table 9. Payload views at n = 100 .
Scheme/view Coordinator-unicast bytes Single-copy-package bytes Unicast transmissions
SRTS/post-finalization 1,836 1,836 51
FROST/preprocessed 264,180 6,980 102
tBLS/cold 5,100 5,100 51
MuSig2/preprocessed 722,300 10,787 200
Table 10. Deployment and remaining gaps.
Table 10. Deployment and remaining gaps.
Dimension What is evaluated What remains required
Compute and energy Python on one arm64 macOS host; no power data Native embedded implementation and measurements on the target CPU, RTOS, secure element, thermal envelope, and battery
Distributed services Algebra and deterministic in-process qualification Proven DKG/VSS/MPC, ACS, consensus/finalization, authenticated channels, and their end-to-end cost
Radio and mobility Independent-link synthetic delay/loss profiles Correlated fading, interference, multicast, routing, topology change, partitions, and flight traces
One-use state Successful in-memory slot transitions and container clearing Atomic assignment, crash recovery, rollback protection, durable burn records, and hardware-supported erasure
Inventory lifecycle One finite batch and single-process generation rate Command-demand traces, safe background replenishment, admission control, and exhaustion policy
Physical compromise Fixed-epoch static corruption bound Rekeying, protected storage, proactive refresh, or an adaptively secure realization for cumulative/mobile capture
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.