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:
threshold Schnorr signatures
; FROST
; rerandomized presignatures
; batch randomness extraction
; unmanned aircraft systems
; decentralized consensus
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.
2. Related Work
[4] uses a simple threshold predicate stating that a signer qualifies if it holds at least `k` of a target attribute set. A default attribute set lets `k` change later without redefining the scheme. The scheme is secure following two CDH reductions in the random oracle model, one for an attacker holding the proxy key and one for an attacker holding the original signer’s key. The costs are estimated based on pairing on a desktop CPU, not on UAV hardware. The estimates count threshold attributes inside one signer’s policy. Following the same security model and assuming a trusted GCS, [5] checks that `d` attributes are shared between each pair of parties in a delegation chain instead of checking against one fixed policy. Dropping the default attribute set removes the flexibility, and the resulting signatures are longer and more expensive to verify compared to [4]. [6] introduces Expressive Attribute-Based Proxy Signature (EABPS) to replace flat predicates in [4,5] with a tree-structured access policy. Thus, each leaf carries its own threshold, so the scheme can express branching authorization rules instead of one attribute count. Both signers must independently satisfy the same tree, and verification recomputes it recursively through Lagrange interpolation before a final pairing check. However, threshold of these previous schemes [4,5,6] are governed with which attributes qualify a signer, not how many signers must agree. [7] proposes pairwise UAV authentication using X.509 ECC certificates, ECDSA, ECDH session-key establishment, and an SHA-1 consistency check intended to detect computation or packet-loss-induced key disagreement. Authors ported an OpenSSL implementation to VxWorks 6.9 on LYS-IMX6Q boards in a four-drone wireless as the authenticated session test environment. [8] combines SDN-controller access control, an OTP challenge, ECC/ECDH-oriented channel protection, and layered controller/firewall enforcement for UAV users to achieve authenticated access rather than collective UAV authorization on two Ubuntu 18.04 virtual machines, Mininet 2.2.2, and an ODL controller. [9] combines Latin-square communication scheduling, BLS signature aggregation, and repeated ECDH operations so registered UAVs can authenticate and derive a common group key without calling the GCS in negotiation. This achieves authenticated group-key negotiation with aggregated individual signatures secure under CDH/ECDLP assumptions. (not a `t`-of-`n` authorization signature.) This work is simulated using PyCryptodome and pypbc on an Intel i7-11800H model, and groups between 16 and 128. [10] provides segmented identity and key management. It defines separate authentication and session-key mechanisms for soldier–drone, drone–CA, and drone–drone communication in a military IoD using ECC, ECDH, group keys, timestamps, hop counts, and UWB-assisted location checks. However, computation is estimated from prior NXP LPC1788 primitive timings rather than a complete deployment, yielding an author-reported 3,280-bit total exchange and 0.456 ms per drone-to-drone link. [11] proposes NC2S, a zero-trustC3 Command, Control, and Communication architecture that separates X.509/ECDSA identity from commander-signed, mission-scoped authorization and supports credential renewal, revocation, and GCS control handover. NC2S directly protects delegated commands through hierarchical credentials and channels rather than a quorum signature. The results are taken from a four-node Windows prototype using Getac/Surface computers, Wi-Fi, and Rohde & Schwarz HR-5000H tactical radios. [12] proposes a PUF–P-256 anonymous group signature. This scheme allows a UAV to produce an anonymous signature, and the GCS verifies it as a trusted party. [13] optimizes Falcon verification for broadcast-heavy UAV settings using signed Plantard arithmetic, packed coefficients, DSP instructions, layer merging, and lazy reduction. It evaluates independent post-quantum signatures, rather than aggregated or threshold authorization on a 20 MHz NUCLEO-L4R5ZI Cortex-M4 with 2 MiB flash and 640 KiB SRAM. Whereas the batch key-agreement scheme called BAKAF [14] allows many vehicles, in the VANET context, to request a session key from one fog node in a short window, with no threshold command signature. A fog node aggregates requests and forwards one batched message to a trusted control center, which builds one interpolated line per vehicle so the vehicle and fog node can each recover a shared session key. This scheme is described as a single round of operations, although it takes four message-transmission stages. Despite its batching claim, the output is a pairwise session key, not a signature under a group key. Besides, [15,16] allow a group of participants to authenticate each other or agree on a shared key, but neither produces a single signature.
In contrast, threshold signature schemes let a quorum of t out of n nodes to cooperate to produce a valid one group signature to authorise a decision. Threshold GDH/BLS [17] extends the single-signer BLS [1] scheme with dealerless distributed key generation and threshold reconstruction. The setup assumes broadcast and secure communication channels among signers. During signing, each shareholder broadcasts one message-dependent share. Then an elected reconstructor validates the shares and combines the qualified subset. The scheme doesn’t include a nonce-coordination round, and its proven secure under the random oracle model against static active corruption when fewer than half the signers are corrupt, and doesn’t include a nonce-coordination round. FROST [2] is considered the reference point for threshold Schnorr. Key generation uses a two-round Pedersen-style protocol, and the design assumes reliable delivery and authenticated participants. It supports two signing modes. In the ordinary mode, signers exchange nonces and responses across two full rounds per signature. In the preprocessed mode, each signer instead publishes batches of single-use nonce commitments in advance. Then, when a message arrives, an aggregator picks unused commitments, and each selected signer returns just one response share. A malformed share triggers identification, exclusion, and a restart, rather than the robustness guarantee threshold GDH/BLS claims. Reusing a nonce can expose a signer’s long-term key share, so nonce handling sits inside the security boundary, not outside it. FROST’s preprocessed mode moves nonce or presignature work offline so only one response stays online. Moreover MuSig2 [18] reaches a one-response signature. The scheme is a two-round multi-signature for a fixed set of `n` independent keys, not a `t`-of-`n` threshold scheme, requiring all parties (UAVs) to take part. The first round can run before knowing the message and signer set, leaving one non-preprocessable response round once both are fixed. Each signer combines a set of its own nonces rather than coordinating with the group on a shared nonce. The scheme could call for an optional untrusted aggregator to collect responses to reduce communication cost. Similar to FROST, reusing nonce state, including through a rollback, can leak a signer’s secret key.
Nevertheless, [19] is the only work that compares true threshold signature schemes in the wide context of secure UAVs. The study tested seven open-source cryptographic libraries focusing on Messaging Layer Security (MLS) and threshold signatures (FROST/FROST-like/BLS), notably highlighting OpenMLS and Cisco MLSpp for group key exchange alongside the Zcash FROST implementation for consensus. The authors acknowledged the preprocessed FROST but compared only FROST’s ordinary two-round mode against one-round threshold BLS on a Windows laptop with WSL.
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 , and denotes a negligible function. We write for uniform sampling from a finite set S, for sampling from a distribution, and for one execution of a probabilistic algorithm with fresh randomness.
The parameter constraints enforced by the prototype are
The direct Shoup-style sharing profile maps Shoup’s corruption parameter to our f and therefore uses . The implementation additionally evaluates a majority profile . Measurements at thresholds other than are sensitivity experiments: their distributed-security interpretation remains conditional on a VSS/MPC realization secure for the chosen . In both beacon integration modes, the prototype sets the finalization threshold to the high value
3.2. Public Parameters, State, and Transcript Binding
The public parameters is defined by:
such that we set so every P-column square submatrix is a nonsingular Vandermonde matrix.
All five functions are domain-separated SHA-256 hashes with length-prefixed inputs. takes and outputs to identify and bind the batch, takes and outputs a to bind the command to its slot, takes a and outputs the beacon-signed digest , takes and outputs to rerandomize the slot, and takes and outputs the Schnorr challenge .
Let and be unsigned big-endian encodings of four and eight bytes. Matching the implementation, the public transcript is bound by
Here denotes the unique signature component of the verified certificate. The certificate is accepted only if it signs , has at least 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 . 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 holds a long-term signing share and one secret share for every available presignature slot k. A selected set of t UAVs produces signature shares.
- Requester: A GCS, mission service, or autonomous UAV may submit . 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 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 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 , 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 is the set of affine points satisfying (together with the point at infinity ), equipped with the chord-and-tangent group law. When is a large prime, is cyclic and every non-identity element is a generator.
We instantiate as the secp256k1 elliptic curve, defined over with
and group order
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 be a cyclic group of prime order N with generator G. Thediscrete logarithm problemis: given for a uniformly random , compute x. We say the DLP is-hardin if every probabilistic algorithm running in time satisfies .
3.6. Schnorr Signatures
Definition 3
(Schnorr signature scheme). ASchnorr signature schemeover group of order N is a triple :
- : sample , output .
- : sample ; let , , ; output .
- : parse ; let ; accept iff .
Schnorr signatures are existentially unforgeable under chosen-message attack (EUF-CMA) in the random oracle model under the DLP assumption [20]. The verification equation is the algebraic identity underlying the correctness proof of SRTS (Proposition 1).
3.7. Secret Sharing and Distributed Key Generation
Definition 4
(-Shamir secret sharing). A-Shamir secret sharingof samples a uniformly random polynomial with , and gives to . 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 ). For , , and evaluations of ϕ,
Applying the formula to the constant polynomial 1 gives .
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
(-threshold signature scheme). A -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 ; it is not part of the generic definition of threshold unforgeability.
3.9. Adversary and Operational Assumptions
The adversary statically selects , with , 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 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 , 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 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, allows every UAV party to obtain privately, while all parties obtain the same D, public verification shares , 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 , which authorize many signatures, from the one-time presignature shares , and it does not mean that the key is permanent.
For every signer set containing t distinct parties with valid shares, the Lagrange coefficients at zero satisfy
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, , and 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 , 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 , extracted scalar , or long-term scalar d is opened by Algorithm 1. The matrix is the deterministic Vandermonde matrix defined in Section 3.2. Because I contains UAVs and at most f are corrupted, it contains at least 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 |
|
4.3. Post-Finalization Signature-Share Stage
For an available slot k, consensus first commits and changes its persistent state from to in one atomic action. Afterward, the finalization service may reveal a certificate . Then, every signer checks that verifies the digest of this exact assignment, contains at least 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 |
|
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 .
Proof.
For the accepted set , Shamir reconstruction and the constant polynomial identity give
Hence
and therefore . □
4.4. Public Signature Verification
After the combiner aggregates t valid signature shares, it publishes the ordinary Schnorr signature . 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 , presignature verification shares , signer identifiers, assignment, or finalization certificate. Algorithm 3 describes this public verification procedure.
For an honestly generated signature, and . Therefore,
so Algorithm 3 returns .
| Algorithm 3: SRTS Public Schnorr Signature Verification |
|
The published signature contains only the Schnorr pair . Neither the signature nor the public verification input encodes the reconstruction threshold t, signer set , 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
each selected signer independently computes one share 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 verifiably shared inputs produces one-use slots. If the corresponding offline execution costs , the accounting identity is
This identity does not make preprocessing , 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 point-to-point transmissions. A fallback that solicits the full committee can cause up to 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 safe. For two responses , , with , the public transcripts reveal
Consequently, durable non-reuse is a safety invariant: an assigned slot never returns to , 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 . 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 satisfies 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 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 of at most f parties before setup, where , , , and . 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 ;
- (iii)
- Consensus safety and persistence for one assignment is fixed while the slot is available and before certificate revelation ;
- (iv)
- A unique, unpredictable, publicly verifiable certificate with a reconstruction threshold ; 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 and are modeled as independent random oracles with range . The transcript functions , , and 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 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 denote the challenger and let be a probabilistic polynomial-time adversary.
Setup.Before setup, statically selects a corrupted set
The challenger executes the long-term threshold key-generation interface
It gives the public state
and the long-term shares of the corrupted parties,
The signing scalar d satisfying is never given to 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
where
The challenger gives the public batch state
and the extracted shares held by corrupted parties,
During generation of batch b, observes the honest public ephemeral inputs
and may choose the inputs of corrupted dealers after observing these values. Let
denote the extracted presignature-scalar vector. Its adversarial bias must admit the representation
where contains the selected honest ephemeral inputs, has full row rank P, and 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
where slot k of batch b is in state . The ideal assignment service first irrevocably commits A and changes the slot state to . It computes
and
Only after the assignment is committed does the finalization service reveal the unique certificate
which verifies under . The challenger then derives
sets
and returns the resulting Schnorr signature
The slot is then permanently marked and cannot be used in another signing query.
Forgery.Finally, outputs
The adversary wins if
equivalently, if, for
and was not the message of any previous successful signing query.
For a probabilistic polynomial-time adversary , define its SRTS EUF-CMA advantage by
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 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 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)
- 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,
where bounds the adversary’s total relevant query budget and . When , this simplifies to .
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 honest inputs, let denote the positions of the honest dealers in and set . 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 . 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 input, the derived has the ideal random-shift distribution, and . The slot is then removed permanently, and 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 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
No concrete value for 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 with , degree- Shamir shares held by 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 , , , 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 has not previously been queried, then δ is fresh in from the adversary’s view at assignment time and 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 input must be excluded or charged to the corresponding external failure term.
Proposition 2
(Nonce reuse remains fatal). If the same presignature scalar is used in two accepted transcripts with distinct challenges , then public rerandomization does not protect the signing key. From , , one computes
Therefore, persistent non-reuse is mandatory.
6.5. Malformed-Share Detection and Liveness Limitations
Given authenticated signer identities and the verification shares and , the combiner rejects a response unless
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 signer-to-combiner transmissions, while committee-wide fallback may solicit up to 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 , set , and use completed inputs and one-use SRTS slots. Flexible-threshold protocols are tested with strict-Shoup , majority , and high profiles. Ordinary MuSig2 is evaluated only at . 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 and be the ordered signer and coordinator phases, and let be signer i’s measured time in signer phase . The two reported computation views are
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 per selected UAV, coordinator share checking and aggregation are , final Schnorr verification is , and the response payload and number of response transmissions are . 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, 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 , where , , and , 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 ms, p95 of ms, median total work of 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 , through the majority setting , to the high setting . 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 or its batch size .
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 . 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 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 , 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 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
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 , 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 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 , the standalone median critical path is 2,338.94 ms (median 95% CI 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 , 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
- Boneh, D.; Lynn, B.; Shacham, H. Short signatures from the Weil pairing.
- Komlo, C. FROST: Flexible Round-Optimized Schnorr Threshold Signatures. [CrossRef]
- 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]
- 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]
- 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]
- He, L.; Gan, Y.; Jin, S. Expressive Attribute-Based Proxy Signature Scheme for UAV Networks. Sensors 2026, 26, 55. [Google Scholar] [CrossRef] [PubMed]
- 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]
- 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]
- 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]
- 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]
- Rebolo, T.; Grilo, A.; Ribeiro, C. Secure Command, Control and Communications Systems (C3) for Army UxVs, 2025. [CrossRef]
- 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]
- 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]
- 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]
- 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]
- 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]
- 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]
- 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]
- 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]
- 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.

Figure 2.
Measured critical-path sensitivity under strict-Shoup

Figure 3.
Recurring offline preprocessing.

Figure 4.
Centralized setup workloads.

Figure 5.
Modeled successful online network delay under configured retries.

Figure 6.
Modeled completion at under independent packet loss.

Figure 7.
Protocol-induced communication after the common committed request.

Figure 8.
SRTS signing separated from optional standalone beacon cost.

Table 1.
Summary of notation used throughout the paper.
| Symbol | Meaning |
|---|---|
| , N, | Prime-order group, generator, group order, and scalar field |
| n, | Number and set of UAV signing parties |
| f, | Static corruption bound and corrupted set, |
| t, | Schnorr reconstruction threshold and active signer set, |
| Reconstruction threshold required of the finalization/beacon certificate in the prototype | |
| , | Agreed ephemeral inputs and extracted one-use slots per batch |
| Ordered common set of completed ephemeral-input dealers | |
| Public super-invertible extraction matrix | |
| d, | Group signing scalar and public key |
| , | Long-term secret share and public verification share of |
| , | Extracted slot-k presignature scalar and public point |
| , | Secret and public verification shares for node , slot k |
| Identifier binding parameters, public key, dealer set, and public slots | |
| A | Consensus-committed assignment |
| Finalization certificate: signed digest, unique signature, and signer IDs | |
| , | Certificate-derived rerandomization scalar and effective nonce |
| h, z, | Schnorr challenge, response scalar, and final signature |
| Lagrange coefficient of at zero for signer set |
Table 2.
Public, secret, and persistent state by lifetime.
| Lifetime/class | State | Required property |
|---|---|---|
| Epoch public | , beacon verification key | Authenticated agreement on committee, parameters, and keys |
| Batch public | Same ordered qualified set and batch transcript at honest nodes | |
| Request public | Assignment finalized before certificate revelation; public verification | |
| Per-UAV secret | Confidential storage; no reconstruction outside prescribed operations | |
| Persistent one-use state | ; bound assignment | Atomic update, rollback protection, crash recovery; reject reuse |
| 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 | One Schnorr equation; independent of | One Schnorr equation; independent of n | Pairing-based verification; independent of 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 timing boundaries. The tBLS row is retained as a backend diagnostic, not included in the primary speed ranking.
Table 4.
Primary 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 .
| 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 .
| 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 .
| 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 .
| Material | Calculation | Bytes | Intended placement |
|---|---|---|---|
| One UAV’s one-use secret shares | 1,088 | Only that UAV; erase/burn one scalar per request | |
| All one-use secret shares | 108,800 | Distributed across UAVs; held centrally only by the prototype | |
| Public verification-share matrix | 112,200 | Coordinator/verifier or replicated public state | |
| Public slot nonces | 1,122 | Public batch state | |
| Batch identifier and dealer identifiers | 300 | Public batch metadata |
Table 9.
Payload views at .
| 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.
| 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. |
© 2026 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
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.