883 lines
98 KiB
Plaintext
883 lines
98 KiB
Plaintext
Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
Contents lists available at ScienceDirect
|
||
|
||
|
||
Computer Standards & Interfaces
|
||
journal homepage: www.elsevier.com/locate/csi
|
||
|
||
|
||
|
||
|
||
MExpm: Fair computation offloading for batch modular exponentiation with
|
||
improved privacy and checkability in IoV
|
||
∗,1
|
||
Sipeng Shen 1 , Qiang Wang , Fucai Zhou, Jian Xu , Mingxing Jin
|
||
Software College, Northeastern University, China
|
||
|
||
|
||
|
||
ARTICLE INFO ABSTRACT
|
||
|
||
Keywords: Modular exponentiation is a fundamental cryptographic operation extensively applied in the Internet of
|
||
Internet of Vehicles Vehicles (IoV). However, its computational intensity imposes significant resource and time demands on
|
||
Modular exponentiation intelligent vehicles. Offloading such computations to Mobile Edge Computing (MEC) servers has emerged as
|
||
Computation offloading
|
||
a promising approach. Nonetheless, existing schemes are generally impractical, as they either fail to ensure
|
||
Smart contract
|
||
fairness between intelligent vehicles and MEC servers, lack privacy protection for the bases and exponents,
|
||
or cannot guarantee the correctness of results with overwhelming probability due to potential misbehavior by
|
||
MEC servers. To address these limitations, we propose MExpm, a fair and efficient computation offloading
|
||
scheme for batch modular exponentiation under a single untrusted server model. Our scheme leverages
|
||
blockchain technology to ensure fairness through publicly verifiable results. Furthermore, MExpm achieves
|
||
high checkability, offering a near-perfect probability of checkability. To enhance privacy, we introduce secure
|
||
obfuscation and logical split techniques, effectively protecting both the bases and the exponents. Extensive
|
||
theoretical analysis and experimental results demonstrate that our scheme is not only efficient in terms of
|
||
computation, communication, and storage overheads but also significantly improves privacy protection and
|
||
checkability.
|
||
|
||
|
||
|
||
1. Introduction requirements of intelligent vehicles [10,11]. Despite these benefits, it
|
||
still suffers from some security challenges. Once the computation tasks
|
||
1.1. Motivation are offloaded, it will lose control over them. As a result, the MEC
|
||
server may forge the outcome of the computation. To address this issue,
|
||
Batch modular exponentiation, a fundamental mathematical opera- verifiable CO was first proposed by [12] to ensure the integrity of the
|
||
∏ 𝑎
|
||
tion, denoted as 𝑛𝑖=1 𝑢𝑖 𝑖 mod 𝑁, which is widely used in the Internet results. A fundamental requirement for verifiable CO is that the total
|
||
of Vehicles (IoV) (i.e., key exchange, digital signatures, and identity time invested in the verification process should be less than the time
|
||
authentication) and is assumed as one of the most resource-intensive spent performing the computation by himself. Otherwise, the intelligent
|
||
operations. Considering limited computation resources in intelligent vehicle would not prefer to offload its computation.
|
||
vehicles, locally executing the above task is unviable, which cannot
|
||
meet both computation resources and time latency requirements [1].
|
||
1.2. Limitations of prior art
|
||
To tackle this challenge, computation offloading (CO) is proposed to
|
||
undertake resource-intensive computation tasks for intelligent vehi-
|
||
In this paper, we mainly focus on verifiable computation offloading
|
||
cles [2]. However, current cloud computation paradigm for modular
|
||
for batch modular exponentiation with MEC servers. However, to the
|
||
exponentiation offloading in [3–8] fails to meet the requirements of low
|
||
best of our knowledge, none of the existing prior schemes are practical
|
||
latency, location awareness, and mobility support [9], since the cloud
|
||
enough, as demonstrated in Fig. 1. They suffer from the following
|
||
servers are far from the vehicles, it is a challenge for network transfer
|
||
latency. To overcome the limitations of cloud computation, offloading challenges.
|
||
computational tasks from intelligent vehicles to MEC servers, being Fairness. Most verifiable CO schemes for batch modular exponen-
|
||
closer to intelligent vehicles than cloud servers, can provide adequate tiation make sure the results are correct for the client before paying
|
||
computation resources for offloaded tasks while meeting the latency but often disregard the cloud’s interests. As a result, the client might
|
||
|
||
|
||
∗ Corresponding author.
|
||
E-mail address: wangqiang1@mail.neu.edu.cn (Q. Wang).
|
||
1
|
||
Equal contribution.
|
||
|
||
https://doi.org/10.1016/j.csi.2025.104107
|
||
Received 3 June 2025; Received in revised form 12 August 2025; Accepted 28 November 2025
|
||
Available online 3 December 2025
|
||
0920-5489/© 2025 Elsevier B.V. All rights are reserved, including those for text and data mining, AI training, and similar technologies.
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
|
||
|
||
Fig. 1. Limitations of Prior Art and Our Defenses: Scenario 1: Previous works adopt private verification algorithm. Under this assumption, the greedy intelligent
|
||
vehicle may reject the correct computation results and refuse to pay for the MEC server’s work. Scenario 2: Previous works with low checkability fail to detect
|
||
MEC server’s misbehavior. Scenario 3: Previous works with plaintext offloading strategy fail to protect the confidentiality of inputs and outputs.
|
||
|
||
|
||
refuse to pay by deliberately claiming that the MEC server returns Table 1
|
||
an incorrect result even when executed faithfully. Furthermore, the Comparison of properties.
|
||
cloud may intentionally manipulate the computation outcome for some Scheme Batch size Privacy Checkability rate Verification Fairness
|
||
119
|
||
economic incentives. When a dispute occurs between them, a fully MExp [3] 1 × 120
|
||
Private ×
|
||
119
|
||
trusted third party (TTP), such as a judge, has to be involved to deduce SMCExp [4] 1 × 120
|
||
Private ×
|
||
119
|
||
which party is wrong. As an ex-post measure, the dispute can be finally SoRSA [6] 1 × 120
|
||
Private ×
|
||
handled, but it is unfriendly for time-sensitive IoV applications [13]. EPExp [7] 1 × 0 Private ×
|
||
MExpm(ours) 1 ✓ ≈1 Public ✓
|
||
Therefore, it is essential to find an immediate resolution without TTP to 2
|
||
|
||
guarantee fairness between the MEC server and the intelligent vehicle. MExp [3] n × 1 − 10(4𝑛2𝑛+6𝑛+2) Private ×
|
||
2
|
||
|
||
Due to transparency, accountability, and immutability, blockchain can SMCExp [4] n × 1 − 10(4𝑛2𝑛+6𝑛+2) Private ×
|
||
1
|
||
be used to establish trust among untrusted parties. A naive solution is to GExp [5] n × 𝑛+1
|
||
Private ×
|
||
𝑛2
|
||
delegate the entire computation to the blockchain. It is inefficient and MExpm(ours) n ✓ 1 − (4𝑛2 +6𝑛+2)(𝑁−2) Public ✓
|
||
|
||
imposes financial burdens on intelligent vehicles, such as significant gas Batch Size: The number of bases in one offloading;
|
||
fees for modular exponentiation in Ethereum. Besides, this approach Privacy: Whether it can protect privacy of bases and exponents;
|
||
seriously deviates from the original intent of computation offloading. Checkability Rate: The Checkability of Offloading scheme;
|
||
Verification: Verification method for offloading;
|
||
Checkability Rate. The existing schemes employ verification mech- Fairness: The fairness for both service provider and intelligent vehicles;
|
||
anisms to ensure computation correctness against malicious MEC ✓: means the scheme achieves this property; ×: means it does not.
|
||
servers [14]. However, the achieved checkability rate often falls short
|
||
of expectations, failing to reach 100%. For example, in [3,4], the
|
||
checkability rate is only 97.5% when the batch size 𝑛 = 1000. In
|
||
a fair computation offloading task, the verification algorithm should
|
||
other words, intelligent vehicles may fail to detect misbehavior by
|
||
be public. To tackle this challenge, a straightforward approach is to
|
||
malicious MEC servers with a 2.5% probability. Besides, the intelligent
|
||
process the computation using fully homomorphic encryption (FHE).
|
||
vehicle may make misjudgments even if the MEC servers return correct Specifically, the bases 𝑢𝑖 are encrypted using the data owner’s public
|
||
results. When disputes arise between the intelligent vehicle and the key and outsourced to the MEC server. The intelligent vehicle encodes
|
||
MEC servers, as previously mentioned, a complex procedure involving the queries 𝑎𝑖 under the same public key. To recover the final result
|
||
TTP is imperative. This ex-post measure is valid, but it is unsuitable for returned by the MEC server, the private key of the data owner should
|
||
IoV time-sensitive applications. Furthermore, there is no such a fully be shared with the intelligent vehicle. If the private key is leaked, it
|
||
trusted entity in the real world. will cause serious privacy issues [15,16]. Furthermore, the intelligent
|
||
Privacy. Most of the existing schemes offload modular exponenti-
|
||
∏ 𝑎 vehicle cannot afford this heavy computation owing to the limitation
|
||
ation 𝑛𝑖=1 𝑢𝑖 𝑖 mod 𝑁 in a plaintext way [6,7]. If we directly apply of resources.
|
||
them into IoV, this inevitably comes with the privacy concern. Modular Compared with existing works in Table 1, MExpm supports privacy
|
||
exponentiation plays a critical role in secure cryptography algorithms and fairness both for service providers and intelligent vehicles. Our
|
||
(i.e., key exchange, digital signatures, identity authentication). In this contributions can be summarized as follows.
|
||
case, the MEC server knows the base 𝑢𝑖 , exponent 𝑎𝑖 , and output which
|
||
is the result of 𝑢𝑎 ( mod 𝑁), so it will increase the risks of privacy 1. To the best of our knowledge, we are the first ones to attempt fair
|
||
leakage and attacks. From this point, it is essential to protect the computation offloading of batch modular exponentiation under
|
||
privacy of the bases, exponents, and results. To tackle this challenge, a single untrusted server model, which is more appropriate for
|
||
some researchers [3–5] utilize the logical split technique to protect practical applications.
|
||
privacy. The security relies on a strong assumption that the auxiliary 2. We integrate smart contracts into the verification process to en-
|
||
information cannot be known by the malicious adversary. Therefore, sure fairness and correctness. Compared with existing schemes,
|
||
the verification algorithm can only be executed by the data owner. For our approach incurs lower gas consumption.
|
||
|
||
2
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
3. We employ a logical split method and secure obfuscation tech-
|
||
niques to conceal the bases, exponents, and modulus before
|
||
offloading computation. Consequently, MExpm achieves near-
|
||
perfect checkability rate.
|
||
|
||
|
||
2. Related work
|
||
|
||
|
||
2.1. Computation offloading
|
||
|
||
|
||
Intelligent vehicles, with limited computation resources and an
|
||
increasing number of in-car applications, struggle to efficiently execute
|
||
computation-intensive tasks. To address the challenges faced by intel-
|
||
ligent vehicles, computation offloading has been proposed. It transfers
|
||
communication, computation, and storage tasks to MEC servers situ-
|
||
ated around intelligent vehicles [17]. Existing computation offloading
|
||
schemes mainly focus on computation efficiency [17–19], resource allo-
|
||
cation [20,21], or decision-making optimization [11] task. While these
|
||
schemes lay the foundation for offloading computationally intensive
|
||
tasks to MEC servers, they often lack adequate security considerations, Fig. 2. The architecture of system model.
|
||
leading to a gap in verifiable computation offloading for batch modular
|
||
exponentiation.
|
||
3. Fair computation offloading for batch modular exponentiation
|
||
2.2. Secure outsourcing algorithm for modular exponentiation scheme in IoV
|
||
|
||
3.1. System model
|
||
The secure outsourcing algorithm for modular exponentiation can
|
||
be categorized into single and dual-server models. Dual-server model
|
||
As illustrated in Fig. 2, the fair computation offloading for batch
|
||
assumes that there is no complicity risk between cloud servers [22–25].
|
||
modular exponentiation in IoV mainly comprises four entities: Service
|
||
This assumption, complex to implement in real-world applications, is
|
||
Agency (SA), Intelligent Vehicle (IV), Roadside Unit (RSU), and MEC
|
||
vulnerable to collusion attacks between servers. Therefore, we mainly Server.
|
||
consider the single-server model, which is first proposed in 2006 by SA: It is an honest entity. It provides the intelligent vehicle with the
|
||
Dijk et al. [26]. Recently, numerous algorithms have been proposed to initialized bases 𝑢𝑖 and modulus 𝑁 of the batch modular exponentiation
|
||
improve checkability rate [5,27,28]. In 2016, Ding et al. [3] proposed ∏ 𝑎
|
||
task 𝑛𝑖=1 𝑢𝑖 𝑖 mod 𝑁, and its communication with intelligent vehicles
|
||
a modular exponentiation outsourcing scheme with checkability rate is based on secure channels.
|
||
close to 119
|
||
120
|
||
, especially when batch size 𝑛 = 1, which is rather higher IV: It is a resource-limited entity. It does not trust the MEC server,
|
||
than before. Thereafter, Su et al. [4], in 2020, expanded Ding’s method, but it wants to offload some requests 𝑎𝑖 to the MEC server, where
|
||
optimized the logical split, and changed the modulus of the algorithm 𝑖 ∈ {1, … , 𝑛}. Furthermore, it may try to get the result without paying
|
||
to a composite number. Recent schemes including SoRSA [6] and EP- by intentionally saying that the cloud’s computation result is wrong.
|
||
Exp [7] assume that bases in computation tasks are ciphertext and lack RSU: It is an untrusted entity, which serves as a full node of the
|
||
the consideration of security of bases. The checkability rate of these blockchain. It provides verifiable services to guarantee the integrity of
|
||
methods is still far from 1, and it can result in certain security risks. the result.
|
||
Meanwhile, many of these schemes concurrently present outsourcing MEC Server: It is a powerful entity deployed at the network’s
|
||
algorithms for 𝑢𝑎 . Nevertheless, a single modular exponentiation out- edge with adequate computation resources, which is responsible for
|
||
sourcing algorithm represents a specific instance of batch modular performing the computation offloading tasks for the intelligent vehicle.
|
||
exponentiation outsourcing with batch size 𝑛 = 1. Similar to the intelligent vehicle, it is also a profit-driven entity. It
|
||
would like to get the reward from the intelligent vehicle without
|
||
performing the computation.
|
||
2.3. Fair computation A fair computation offloading for batch modular exponentiation
|
||
(MExpm) in IoV consists of the following algorithms.
|
||
Recently, blockchain and smart contracts have been proposed to (𝑃 𝑎𝑟𝑎𝑚𝑠, 𝑅𝐾) ← 𝑆𝑒𝑡𝑢𝑝(1𝜆 , 𝑢1 , … , 𝑢𝑛 , 𝑁). Given a security parameter
|
||
𝜆, the bases 𝑢1 , … , 𝑢𝑛 and 𝑁, SA invokes this algorithm to generate the
|
||
address these fairness issues [29]. Smart contracts can provide a secure
|
||
public parameters 𝑃 𝑎𝑟𝑎𝑚𝑠 and the recovery key 𝑅𝐾, where 𝑢𝑖 and 𝑁
|
||
solution for participants to execute contracts on Ethereum, essentially
|
||
are the base and modulus for modular exponentiation tasks.
|
||
being executable code with correctness, transparency, and immutabil-
|
||
(𝑇 𝐾, 𝑉 𝐾, 𝐴𝑢𝑥) ← 𝐾𝑒𝑦𝐺𝑒𝑛(𝑎1 , … , 𝑎𝑛 , 𝑃 𝑎𝑟𝑎𝑚𝑠). On inputting the ex-
|
||
ity [30]. Although there are some studies utilizing smart contract to
|
||
ponents 𝑎1 , … , 𝑎𝑛 and the public parameters 𝑃 𝑎𝑟𝑎𝑚𝑠, IV runs this
|
||
fulfill fair computation, they either rely on the assumption that the
|
||
algorithm to generate the evaluation key 𝑇 𝐾 for performing the compu-
|
||
client and the cloud are honest [31], or utilize smart contract con- tation task, witness generation key 𝑉 𝐾 and auxiliary information 𝐴𝑢𝑥.
|
||
ducting complex computation tasks [29,32,33]. However, in standard It is worth noting that this algorithm can be carried out entirely offline
|
||
blockchain systems such as Ethereum, users are typically charged gas before the online phase, so it does not introduce additional latency
|
||
fees based on the complexity of the computational task running in the during computation outsourcing. The input 𝑎𝑖 is the exponent of 𝑢𝑖 ,
|
||
smart contract. The gas fees for smart contracts are recorded in the where 𝑖 ∈ {1, … , 𝑛}.
|
||
fee table EIP150 [34]. Generally, the cost of Ethereum is high, and (𝜎E , 𝜋𝐸 ) ← 𝐶𝑜𝑚𝑝𝑢𝑡𝑒(𝑇 𝐾, 𝑉 𝐾). On inputting the evaluation key
|
||
considering that modular exponentiation is an expensive computation 𝑇 𝐾 and witness generation key 𝑉 𝐾, the MEC server performs this
|
||
task, Existing schemes may increase the financial burden on users. algorithm to produce the encoding result 𝜎E and witness 𝜋𝐸 .
|
||
|
||
3
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
Table 2 𝟐. 𝑲𝒆𝒚𝑮𝒆𝒏(𝒂1 , … , 𝒂𝒏 , 𝑷 𝒂𝒓𝒂𝒎𝒔) ∶ This algorithm is executed by the
|
||
Notations. IV to construct the evaluation key 𝑇 𝐾 for performing the computation
|
||
Symbols Descriptions task, the witness generation key 𝑉 𝐾, and auxiliary information 𝐴𝑢𝑥.
|
||
{𝑢1 , 𝑢2 , … , 𝑢𝑛 } Computation bases Notably, the IV can execute this procedure in an offline manner, thereby
|
||
𝜆 Security Parameter
|
||
avoiding additional delays in the online authentication or verification
|
||
𝑝 512-bit prime integer
|
||
𝑁 512-bit prime integer phase. This algorithm works as follows:
|
||
𝐿 A composite integer 𝐿 = 𝑝𝑁 (a) IV parses 𝑃 𝑎𝑟𝑎𝑚𝑠 as {𝐿, 𝑦𝑖 } and the input exponents 𝑎𝑖 ∈ Z∗𝜙(𝐿) .
|
||
𝑘 A random integer
|
||
(b) IV runs RandN program [35] four times to generate four blinding
|
||
𝜏 A composite integer 𝜏 = 𝑘𝑁
|
||
{𝑦1 , 𝑦2 , … , 𝑦𝑛 } Bases after secure obfuscation pairs (𝑘1 , 𝑔 𝑘1 ), (𝑘2 , 𝑔 𝑘2 ), (𝑘3 , 𝑔 𝑘3 ), (𝑘4 , 𝑔 𝑘4 ) and sets:
|
||
(𝑘𝑖 , 𝑔 𝑘𝑖 ), 𝑖 ∈ {1, 2, 3, 4} Random pairs generated by RandN algorithm
|
||
{𝑎1 , 𝑎2 , … , 𝑎𝑛 } Computation exponents
|
||
𝑣1 = 𝑔 𝑘1 mod 𝐿, 𝑣2 = 𝑔 𝑘2 mod 𝐿,
|
||
(2)
|
||
𝜙(⋅) Euler’s function 𝑣3 = 𝑔 𝑘3 mod 𝐿, 𝑣4 = 𝑔 𝑘4 mod 𝐿.
|
||
{𝑤𝑖 , 𝑧1 , 𝛿1 , 𝑚𝑖 }, 𝑖 ∈ {1, … , 𝑛} Computation tasks after logical division
|
||
𝑟 ∈ {2, … , 𝑁} Random integer where 𝑔 ∈ Z∗𝐿 and its order is 𝜙(𝐿).
|
||
𝜉 ∈ {1, … , 𝑛} Random index (c) IV performs logical split to compute 𝑤𝑖 , 𝑧1 , 𝛿1 , and 𝑚𝑖 such that
|
||
𝑑 Modular Multiplicative Inverse of 𝑎𝜉
|
||
{𝑤′𝑖 , 𝑧2 , 𝛿2 , 𝑚′𝑖 }, 𝑖 ∈ {1, … , 𝑛} Verification tasks after logical division
|
||
{𝜎𝐸 , 𝜋𝐸 } Computation results returned by MEC server 𝑤𝑖 = 𝑦𝑖 ∕𝑣1 (mod 𝐿),
|
||
( )
|
||
𝑘1 𝑎1 + 𝑎2 + ⋯ + 𝑎𝑛 = 𝑘3 + 𝛿1 𝑧1 (mod 𝜙(𝐿)), (3)
|
||
𝑎𝑖 = 𝛿1 𝑧1 + 𝑚𝑖 (mod 𝜙(𝐿)).
|
||
{0∕1, 𝜎E } ← 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝜎E , 𝜋𝐸 , 𝐴𝑢𝑥). On inputting the encoding result (d) IV chooses two random integers 𝑟 ∈ {2, … , 𝑁} and 𝜉 ∈ {1, … , 𝑛}
|
||
𝜎E , the witness 𝜋𝐸 and auxiliary information 𝐴𝑢𝑥, the RSU runs this and computes 𝑑, where 𝑎𝜉 𝑑 ≡ 1 (mod 𝜙(𝐿)).
|
||
algorithm to check whether the MEC server returns a correct result
|
||
(e) IV computes 𝑤′𝑖 , 𝑧2 , 𝛿2 , and 𝑚′𝑖 such that
|
||
utilizing smart contract. If not, it outputs 0, 1 and 𝜎E otherwise.
|
||
𝑅𝑒𝑠𝑢𝑙𝑡 ← 𝑅𝑒𝑐𝑜𝑣𝑒𝑟𝑦(𝜎E , 𝑅𝐾). On inputting 𝜎E and recovery key 𝑅𝐾, 𝑤′𝑖 = 𝑦𝑖 ∕𝑣2 (mod 𝐿),
|
||
the intelligent vehicle runs this algorithm to decode the true result ( )
|
||
𝑘2 𝑎1 + 𝑎2 + ⋯ + 𝑎𝑛 = 𝑘4 + 𝛿2 𝑧2 (mod 𝜙(𝐿)), (4)
|
||
𝑅𝑒𝑠𝑢𝑙𝑡.
|
||
𝑎𝑖 = 𝛿2 𝑧2 + 𝑚′𝑖 (mod 𝜙(𝐿)).
|
||
|
||
3.2. Overview of construction and notations Especially when 𝑖 = 𝜉, we have 𝑦′𝜉 = 𝑦𝜉 𝑟𝑑 ( mod 𝐿) and 𝑤′𝜉 = 𝑦′𝜉 ∕𝑣2 ( mod
|
||
𝐿), where 𝜉 ∈ [1, 𝑛] is a random integer.
|
||
∏
|
||
Similar to [3], the bases and exponents are protected using logical (f) IV sets 𝑇𝐾 = {(𝑔 𝑛𝑖=1 𝑤𝑖 , 𝑧1 ), (𝑤𝑖 , 𝑚𝑖 )𝑖∈[𝑛] },
|
||
∏𝑛
|
||
split. A recovery algorithm is also involved to protect the confidentiality 𝑉 𝐾 = {(𝑔 𝑖=1 𝑤′𝑖 , 𝑧2 ), (𝑤′𝑖 , 𝑚′𝑖 )𝑖∈[𝑛] } and 𝐴𝑢𝑥 = {𝑟𝑣3 , 𝑣4 , 𝛿1 , 𝛿2 }, where
|
||
of the final result. At the setup phase, we utilize the secure obfuscation 𝛿1 , 𝛿2 ∈ Z∗𝜙(𝐿) . The pseudo code of the key generation procedure can be
|
||
technique to hide the modulus 𝑁 and bases 𝑢𝑖 . In 𝑆𝑒𝑡𝑢𝑝 step (a), only found in Algorithm 1.
|
||
the masked modulus 𝐿 = 𝑝 ⋅ 𝑁 is sent to MEC server, so the MEC
|
||
server cannot get any information about 𝑁 without the mask factor
|
||
Algorithm 1: KeyGen Algorithm
|
||
𝑝 chosen and kept privately by the User. To prevent the MEC server
|
||
from learning the original bases 𝑢𝑖 , we apply a modular obfuscation Input: Exponents 𝑎1 , ⋯ , 𝑎𝑛 ∈ Z∗𝜙(𝐿) , public parameters
|
||
technique by embedding each base into a larger modular space (i.e., Eq. 𝑃 𝑎𝑟𝑎𝑚𝑠 = {𝐿, 𝑦𝑖 }
|
||
(1)) in 𝑆𝑒𝑡𝑢𝑝 step (b). Since 𝑘 and 𝑝 are sampled uniformly, the Output: Evaluation key 𝑇 𝐾, verification key 𝑉 𝐾, auxiliary info
|
||
adversarial MEC server cannot recover them. The original computation 𝐴𝑢𝑥
|
||
∏𝑛 𝑎𝑖 mod 𝑁 is converted into ∏𝑛 𝑦 𝑎𝑖 mod 𝐿. 1 Parse 𝑃 𝑎𝑟𝑎𝑚𝑠 as {𝐿, 𝑦𝑖 } ; // Step (a)
|
||
offloading task 𝑖=1 𝑢𝑖 𝑖=1 𝑖
|
||
2 Run RandN algorithm four times to get
|
||
The privacy of the exponent 𝑎𝑖 is ensured by the logical split, where
|
||
𝑎𝑖 = 𝛿1 ⋅ 𝑧𝑖 + 𝑚𝑖 mod 𝜙(𝐿). Since the standard integer factorization (𝑘1 , 𝑔 𝑘1 ), (𝑘2 , 𝑔 𝑘2 ), (𝑘3 , 𝑔 𝑘3 ), (𝑘4 , 𝑔 𝑘4 ); // Step (b)
|
||
𝑘 𝑘
|
||
3 Compute 𝑣1 = 𝑔 1 mod 𝐿, 𝑣2 = 𝑔 2 mod 𝐿, 𝑣3 = 𝑔 3 mod 𝐿,
|
||
𝑘
|
||
assumption holds, the adversary cannot derive their factors 𝑝 and 𝑁
|
||
from 𝐿. Without factors 𝑝 and 𝑁, it is infeasible to compute 𝜙(𝐿) = 𝑣4 = 𝑔 𝑘4 mod 𝐿; // Compute Equation 2
|
||
4 Compute 𝑘1 (𝑎1 + ⋯ + 𝑎𝑛 ) = 𝑘3 + 𝛿1 𝑧1 mod 𝜙(𝐿) ; // Equation
|
||
(𝑝 − 1)(𝑁 − 1).𝜙(𝐿) = (𝑝 − 1) ⋅ (𝑁 − 1). As a result, the reduction modulo
|
||
𝜙(𝐿) effectively hides the underlying value, which makes it infeasible 3
|
||
5 for 𝑖 ← 1 to 𝑛 do
|
||
to recover 𝑎𝑖 from 𝛿1 ⋅ 𝑧𝑖 + 𝑚𝑖 mod 𝜙(𝐿). Furthermore, the malicious
|
||
adversary learns nothing about the final computation result without the
|
||
6 Compute 𝑤𝑖 = 𝑦𝑖 ∕𝑣1 mod 𝐿 ; // Equation 3
|
||
recovery key. A detailed description of the notations used in MExpm
|
||
7 Compute 𝑎𝑖 = 𝛿1 𝑧1 + 𝑚𝑖 mod 𝜙(𝐿); // Equation 3
|
||
can be found in Table 2. 8 Sample 𝑟 ∈ {2, ⋯ , 𝑁} and 𝜉 ∈ {1, ⋯ , 𝑛} randomly ; // Step
|
||
(d)
|
||
9 Compute 𝑑 = 𝑎
|
||
−1 mod 𝜙(𝐿); // Step (d)
|
||
3.3. Detailed construction 𝜉
|
||
10 Compute 𝑘2 (𝑎1 + ⋯ + 𝑎𝑛 ) = 𝑘4 + 𝛿2 𝑧2 mod 𝜙(𝐿); // Equation 3
|
||
|
||
𝟏. 𝑺𝒆𝒕𝒖𝒑(𝟏𝝀 , 𝒖1 , … , 𝒖𝒏 , 𝑵) ∶ This algorithm is run by SA. Given 11 for 𝑖 ← 1 to 𝑛 do
|
||
a security parameter 𝜆 and a 512-bit prime integer 𝑁, SA works as 12 Compute 𝑤′𝑖 = 𝑦𝑖 ∕𝑣2 mod 𝐿 ; // Equation 3
|
||
follows: 13 Compute 𝑎𝑖 = 𝛿2 𝑧2 + 𝑚′𝑖 mod 𝜙(𝐿); // Equation 3
|
||
(a) SA generates a 512-bit prime integer 𝑝, and computes 𝐿 = 𝑝𝑁. 14 Randomly Select 𝜉 ∈ [1, 𝑛], and Update 𝑦′𝜉 = 𝑦𝜉 ⋅ 𝑟𝑑 mod 𝐿,
|
||
(b) SA uniformly chooses 𝑘 from 𝑍𝑁 and computes 𝜏 = 𝑘𝑁. For any 𝑤′𝜉 = 𝑦′𝜉 ∕𝑣2 mod 𝐿 ; // Step (e)
|
||
𝑖 ∈ {1, 2, … , 𝑛}, SA sets 𝑦𝑖 as follows: ∏
|
||
15 Set 𝑇 𝐾 = {(𝑔 ⋅ 𝑛𝑖=1 𝑤𝑖 , 𝑧1 ), (𝑤𝑖 , 𝑚𝑖 )𝑖∈[𝑛] }; // Step (f)
|
||
∏𝑛 ′ ′ ′
|
||
𝑦𝑖 = 𝑢𝑖 + 𝜏 mod 𝐿 (1) 16 Set 𝑉 𝐾 = {(𝑔 ⋅
|
||
𝑖=1 𝑤𝑖 , 𝑧2 ), (𝑤𝑖 , 𝑚𝑖 )𝑖∈[𝑛] }; // Step (f)
|
||
17 Set 𝐴𝑢𝑥 = {𝑟𝑣3 , 𝑣4 , 𝛿1 , 𝛿2 }; // Step (f)
|
||
(c) SA sets 𝑃 𝑎𝑟𝑎𝑚𝑠 = {𝐿, 𝑦𝑖 } and 𝑅𝐾 = {𝑁}, where 𝑅𝐾 is 18 return 𝑇 𝐾, 𝑉 𝐾, 𝐴𝑢𝑥;
|
||
transmitted via a secure channel between SA and IV.
|
||
|
||
4
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
1. 𝑆𝑒𝑡𝑢𝑝: Generate two distinct secure primes 𝑝 = 13, 𝑁 = 11.
|
||
Compute 𝐿 = 𝑝 ⋅ 𝑁 = 143. Then generate 𝑢 = 128, 𝑎 = 79.
|
||
𝟑. 𝑪𝒐𝒎𝒑𝒖𝒕𝒆(𝑻 𝑲, 𝑽 𝑲) ∶ This algorithm is run by MEC server to 2. 𝐶𝑜𝑚𝑝𝑢𝑡𝑒: Locally compute result 𝑅𝑒𝑠𝑢𝑙𝑡 = 12879 mod 43 = 8.
|
||
generate encoding result 𝜎𝐸 and witness result 𝜋𝐸 . The MEC server
|
||
works as follows: The proposed MExpm consists of the following procedures.
|
||
∏
|
||
(a) MEC server parses 𝑇 𝐾 as {(𝑔 𝑛𝑖=1 𝑤𝑖 , 𝑧1 ), (𝑤𝑖 , 𝑚𝑖 )𝑖∈[𝑛] } and 𝑉 𝐾
|
||
∏𝑛 ′
|
||
as {(𝑔 𝑖=1 𝑤𝑖 , 𝑧2 ), (𝑤𝑖 , 𝑚𝑖 )𝑖∈[𝑛] }, and then sets 𝛾𝑖 = (𝑤𝑖 )𝑚𝑖 and 𝛾𝑖′ = (𝑤′𝑖 )𝑚𝑖
|
||
′ ′ ′ 1. 𝑆𝑒𝑡𝑢𝑝: SA generates 𝑝 = 13, 𝑁 = 11 and computes 𝐿 = 𝑝⋅𝑁 = 143.
|
||
for any 𝑖 ∈ {1, … , 𝑛}, respectively. Then SA generates base 𝑢 = 128 and utilizes random integer
|
||
( ∏ )𝑧 ( ∏ )𝑧
|
||
(b) MEC server sets 𝑄0 = 𝑔 𝑛𝑖=1 𝑤𝑖 1 and 𝑄1 = 𝑔 𝑛𝑖=1 𝑤′𝑖 2 . 𝑘 = 5 to compute 𝑦 = 𝑢 + 𝑘 ⋅ 𝑁 mod 𝐿 = 40.
|
||
(c) MEC server sets 𝜎𝐸 = {𝑄0 , (𝛾𝑖 )𝑖∈[𝑛] } and 𝜋𝐸 = {𝑄1 , (𝛾𝑖′ )𝑖∈[𝑛] }. 2. 𝐾𝑒𝑦𝐺𝑒𝑛: Intelligent Vehicle runs 𝑅𝑎𝑛𝑑𝑁 algorithm to obtain
|
||
𝟒. 𝑽 𝒆𝒓𝒊𝒇 𝒚(𝝈 𝑬 , 𝝅 𝑬 , 𝑨𝒖𝒙) ∶ The algorithm is run by RSU to check the (63, 125), (42, 25), (52, 113), (82, 69), 𝑔 = 71 and compute 𝑣1 −1 =
|
||
correctness of the result returned by the MEC. The RSU works as 125−1 mod 𝐿 = 135, 𝑣2 −1 = 25−1 mod 𝐿 = 103. Then it gener-
|
||
follows: ates a computation task 𝑎 = 79. Thereafter, intelligent vehicle
|
||
(a) Upon receiving the encoding result 𝜎𝐸 and witness 𝜋𝐸 , it first generate random integers 𝛿1 = 11, 𝛿2 = 109, 𝑟 = 7 and compute
|
||
parses them as {𝑄0 , (𝛾𝑖 )𝑖∈[𝑛] } and {𝑄1 , (𝛾𝑖′ )𝑖∈[𝑛] }, respectively. (b) it 𝑑 = 𝑎−1 mod 𝜙(𝐿) = 79, 𝑟𝑑 mod 𝐿 = 19. Finally, intelligent
|
||
parses auxiliary information 𝐴𝑢𝑥 as {𝑟𝑣3 , 𝑣4 , 𝛿1 , 𝛿2 }. vehicle utilizes Eqs. (3) and (4) to conduct logical split, then
|
||
( )𝛿
|
||
(c) RSU utilizes smart contract to compute 𝜂 = 𝑄0 1 and then obtain 𝑤 = 109, 𝑔𝑤 = 17, 𝑤′ = 59, 𝑔𝑤′ = 42, 𝛿1 𝑧1 = 57, 𝑧1 =
|
||
check whether the following equation holds: 55, 𝛿2 𝑧2 = 78, 𝑧2 = 44, 𝑚 = 74, 𝑚′ = 83, 𝑟𝑣3 = 76.
|
||
∏
|
||
𝑛
|
||
( )𝛿 ∏ 𝑛 3. 𝐶𝑜𝑚𝑝𝑢𝑡𝑒: MEC server receives the offloading tasks and com-
|
||
𝑟𝑣3 ⋅ 𝜂 ⋅ 𝛾𝑖 = 𝑣4 ⋅ 𝑄1 2 ⋅ 𝛾𝑖′ (mod 𝐿) (5) pute (𝑔𝑤)𝑧1 = 5955 mod 143 = 43, (𝑔𝑤′ )𝑧2 = 4244 mod 143 =
|
||
′
|
||
𝑖=1 𝑖=1 126, 𝑤𝑚 = 12, 𝑤′ 𝑚 = 119.
|
||
If not, the smart contract outputs 0 and aborts. Otherwise, outputs 1
|
||
∏ 4. 𝑉 𝑒𝑟𝑖𝑓 𝑦: Smart contract is called to verify 𝐿𝑒𝑓 𝑡 = 76 ⋅ 12 ⋅ 4311
|
||
and sets 𝜎𝐸 = {𝑟𝑣3 𝜂 𝑛𝑖=1 𝛾𝑖 }. The verification logic of the smart contract
|
||
mod 143 = 111 and 𝑅𝑖𝑔ℎ𝑡 = 69 ⋅ 126109 ⋅ 119 mod 143 = 111.
|
||
can be found in Algorithm 2.
|
||
5. 𝑅𝑒𝑐𝑜𝑣𝑒𝑟𝑦: Intelligent Vehicle computes 𝑟−1 mod 𝐿 = 41, then
|
||
obtain 𝑅𝑒𝑠𝑢𝑙𝑡 = 111 ⋅ 41 mod 11 = 8.
|
||
Algorithm 2: Verification Logic of Smart Contract
|
||
Input:
|
||
𝑄0 , 𝑄1 ∈ Z𝐿 ; (𝛾𝑖 )𝑖∈[𝑛] , (𝛾𝑖′ )𝑖∈[𝑛] ∈ Z𝐿 4. Theoretical analysis
|
||
Scalars: 𝑟𝑣3 , 𝑣4 , 𝛿1 , 𝛿2 ∈ Z𝐿
|
||
Output: Boolean flag indicating verification result 4.1. Correctness
|
||
𝛿1
|
||
1 𝜂 ←𝑄
|
||
0
|
||
mod 𝐿 ; // Compute 𝜂
|
||
2 prodGamma ← 1;
|
||
To prove the correctness, we need to argue that the returned results
|
||
3 for 𝑖 ← 1 to 𝑛 do
|
||
by the MEC server can pass the verification algorithm and the intel-
|
||
4 prodGamma ← prodGamma ⋅ 𝛾𝑖 mod 𝐿; // Accumulate
|
||
ligent vehicle can recover the final result if all entities involved are
|
||
product of 𝛾𝑖
|
||
honest.
|
||
5 prodGammaPrime ← 1;
|
||
For the first part, we mainly argue it based on Eq. (5). That is, we
|
||
6 for 𝑖 ← 1 to 𝑛 do
|
||
prove that the 𝜎𝐸 and 𝜋𝐸 can pass the 𝑣𝑒𝑟𝑖𝑓 𝑦 algorithm when MEC
|
||
7 prodGammaPrime ← prodGammaPrime ⋅ 𝛾𝑖′ mod 𝐿;
|
||
server is honest and follows all algorithms mentioned above.
|
||
// Accumulate product of proofs 𝛾𝑖′
|
||
Based on Eq. (4), the right-hand side (𝑅𝐻𝑆) of Eq. (5) can be
|
||
8 lhs ← 𝑟𝑣3 ⋅ 𝜂 ⋅ prodGamma mod 𝐿; // Left-hand side of
|
||
expressed as:
|
||
the equality
|
||
𝛿2
|
||
9 rhs ← 𝑣4 ⋅ 𝑄 ⋅ prodGammaPrime mod 𝐿; // Right-hand ( )𝛿 ∏ 𝑛
|
||
1 𝑅𝐻𝑆 = 𝑣4 ⋅ 𝑄1 2 ⋅ 𝛾𝑖′ (mod 𝐿)
|
||
side of the equality 𝑖=1
|
||
10 return (lhs == rhs); // Return true if verification ( )𝑧2 𝛿2 𝑛
|
||
∏
|
||
𝑛 ∏ 𝑚′
|
||
passes = 𝑔 𝑘4 𝑔 𝑤′𝑖 𝑤′𝑖 𝑖 (mod 𝐿)
|
||
𝑖=1 𝑖=1
|
||
( 𝑛 )𝑧2 𝛿 2 𝑛
|
||
∏ ∏ 𝑚′
|
||
𝟓. 𝑹𝒆𝒄𝒐𝒗𝒆𝒓𝒚(𝝈 𝑬 , 𝑹𝑲) ∶ The algorithm is run by IV to recover the = 𝑔 𝑘4 +𝑧2 𝛿2 𝑤′𝑖 𝑤′𝑖 𝑖 (mod 𝐿)
|
||
encoding result 𝜎𝐸 to the true result 𝑅𝑒𝑠𝑢𝑙𝑡. 𝑖=1 𝑖=1
|
||
∏ )∏ 𝑛
|
||
(a) IV parses 𝑅𝐾 as {𝑁} and 𝜎𝐸 as {𝑟𝑣3 𝜂 𝑛𝑖=1 𝛾𝑖 }, where 𝜂 = ( ′
|
||
( ∏𝑛 )𝑧1 𝛿1 = 𝑔 𝑘2 𝑎1 +𝑎2 +···+𝑎𝑛 𝑤′𝑖 𝑚𝑖 +𝛿2 𝑧2 (mod 𝐿)
|
||
𝑔 𝑖=1 𝑤𝑖 . 𝑖=1
|
||
(b) IV recovers the final computation result 𝑅𝑒𝑠𝑢𝑙𝑡 as follows: ( )∏ 𝑛
|
||
𝑘2 𝑎1 +𝑎2 +···+𝑎𝑛
|
||
=𝑔 𝑤′𝑖 𝑎𝑖 (mod 𝐿) (7)
|
||
∏
|
||
𝑛
|
||
𝑅𝑒𝑠𝑢𝑙𝑡 = 𝑟𝑣3 𝜂 𝛾𝑖 ⋅ 𝑟−1 (mod 𝐿) 𝑖=1
|
||
𝑖=1 ∏𝑛
|
||
( )𝑧1 𝛿1 (6) = 𝑔 𝑘2 𝑎𝑖 𝑤′𝑖 𝑎𝑖 (mod 𝐿)
|
||
∏
|
||
𝑛 ∏
|
||
𝑛
|
||
𝑚 𝑖=1
|
||
= 𝑔 𝑘3 𝑔 𝑤𝑖 𝑤𝑖 𝑖 (mod 𝑁)
|
||
𝑖=1 𝑖=1
|
||
∏𝑛
|
||
𝑎
|
||
= 𝑣2𝑖 𝑤′𝑖 𝑎𝑖 (mod 𝐿)
|
||
𝑖=1
|
||
3.4. An illustrative ∏𝑛
|
||
= 𝑦′𝑖 𝑎𝑖 (mod 𝐿)
|
||
𝑖=1
|
||
We now provide a toy example to further illustrate MExpm. MExpm
|
||
performs the following procedures. The original modular exponentia- ∏
|
||
𝜉−1
|
||
𝑎 ∏ 𝑛
|
||
𝑎
|
||
= 𝑦𝑖 𝑖 ⋅ 𝑦′𝜉 𝑟𝑑𝑎𝜉 ⋅ 𝑦𝑖 𝑖 (mod 𝐿)
|
||
tion performs the following procedures. 𝑖=1 𝑖=𝜉+1
|
||
|
||
|
||
5
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
Since 𝑎𝜉 𝑑 ≡ 1( mod 𝜙(𝐿)), we always have 𝑦′𝜉 𝑟𝑑𝑎𝜉 = 𝑟𝑦𝜉 mod 𝐿. Based on
|
||
Eq. (3), we can get:
|
||
∏
|
||
𝑛
|
||
𝑎
|
||
𝑅𝐻𝑆 = 𝑟 𝑦𝑖 𝑖 (mod 𝐿)
|
||
𝑖=1
|
||
∏
|
||
𝑛
|
||
𝑎
|
||
=𝑟 𝑔 𝑘1 𝑎𝑖 𝑤𝑖 𝑖 (mod 𝐿)
|
||
𝑖=1
|
||
( )∏
|
||
𝑛
|
||
𝑚 +𝛿1 𝑧1
|
||
= 𝑟𝑔 𝑘1 𝑎1 +𝑎2 +···+𝑎𝑛 𝑤𝑖 𝑖 (mod 𝐿)
|
||
𝑖=1
|
||
( 𝑛 )𝑧1 𝛿1
|
||
∏ ∏
|
||
𝑛
|
||
𝑚
|
||
𝑘3 +𝑧1 𝛿1
|
||
= 𝑟𝑔 𝑤𝑖 𝑤𝑖 𝑖 (mod 𝐿) (8)
|
||
𝑖=1 𝑖=1
|
||
( )𝑧1 𝛿1
|
||
∏
|
||
𝑛 ∏
|
||
𝑛
|
||
𝑚
|
||
= 𝑟𝑔 𝑘3 𝑔 𝑤𝑖 𝑤𝑖 𝑖 (mod 𝐿) Fig. 3. Comparison of checkability rate.
|
||
𝑖=1 𝑖=1
|
||
( )𝛿 ∏
|
||
𝑛
|
||
= 𝑟𝑣3 𝑄0 1 𝛾𝑖 (mod 𝐿)
|
||
𝑖=1 Proof. If the malicious MEC server deceives the intelligent vehicle IV
|
||
∏
|
||
𝑛
|
||
successfully, the following equation will hold.
|
||
= 𝑟𝑣3 ⋅ 𝜂 ⋅ 𝛾𝑖 (mod 𝐿)
|
||
𝑖=1 ∏
|
||
𝑛
|
||
( )𝛿 ∏𝑛
|
||
𝑡 ⋅ 𝑟𝑣3 𝜂 𝛾𝑖 = 𝑡 ⋅ 𝑣4 𝑄1 2 𝛾𝑖′ (10)
|
||
Obviously, according to Eq. (8), if the MEC server and intelligent 𝑖=1 𝑖=1
|
||
vehicle IV are honest and follow all procedures described above, the
|
||
The corresponding encoding result will be decoded by IV as follows:
|
||
encoding result 𝜎𝐸 and witness result 𝜋𝐸 can always pass the 𝑉 𝑒𝑟𝑖𝑓 𝑦
|
||
algorithm. ∏
|
||
𝑛
|
||
𝑅𝑒𝑠𝑢𝑙𝑡 = 𝑡 ⋅ 𝑣3 𝜂 𝛾𝑖 (mod 𝑁) (11)
|
||
Second, we will argue that the encoding result 𝜎𝐸 can be decoded
|
||
𝑖=1
|
||
to the actual result 𝑅𝑒𝑠𝑢𝑙𝑡. In this section, we mainly rely on Eq. (1), Since the MEC server could not gain access to the values of 𝛿1 and 𝛿2 ,
|
||
Eq. (2), Eq. (3) and (6). The 𝜎𝐸 can be parsed and computed as follows: ( )𝛿
|
||
it cannot obtain the correct values of 𝜂 and 𝑄1 2 . Therefore, the MEC
|
||
server can only turn to other 𝑛 pairs to cheat the intelligent vehicle,
|
||
∏
|
||
𝑛
|
||
then it needs to determine the correct meanings of 2𝑛 + 2 sub-tasks to
|
||
𝑅𝑒𝑠𝑢𝑙𝑡 = 𝑟𝑣3 𝜂 𝛾𝑖 ⋅ 𝑟−1 (mod 𝑁)
|
||
obtain pairs: (𝑤ℎ , 𝑚ℎ ) and (𝑤′𝑗 , 𝑚′𝑗 ). Since the sending order of these 2𝑛+
|
||
𝑖=1
|
||
( )𝑧1 𝛿1 2 pairs is random, the MEC server is unaware of the specific meanings
|
||
∏
|
||
𝑛 ∏
|
||
𝑛
|
||
= 𝑔 𝑘3 𝑔 𝑤𝑖
|
||
𝑚
|
||
𝑤𝑖 𝑖 (mod 𝑁) of each pair. Therefore, it needs to find (𝑤ℎ , 𝑚ℎ ) and (𝑤′𝑗 , 𝑚′𝑗 ) among the
|
||
𝑛 𝑛
|
||
𝑖=1 𝑖=1 2𝑛 + 2 pairs. The probability of this operation is 2𝑛+2 2𝑛+1
|
||
. Additionally,
|
||
( 𝑛 )𝑧1 𝛿 1 for successful deception, the MEC server needs to determine the value
|
||
∏ ∏
|
||
𝑛
|
||
𝑚
|
||
= 𝑔 𝑘3 +𝑧1 𝛿1 𝑤𝑖 𝑤𝑖 𝑖 (mod 𝑁) of 𝑟, where 𝑟 ∈ {2, … , 𝑁}. Thus, the probability of finding the correct 𝑟
|
||
𝑖=1 𝑖=1 1
|
||
is 𝑁−2 . Subsequently, the MEC server generates a random number 𝑡 and
|
||
( )∏
|
||
𝑛
|
||
𝑚 𝑚′
|
||
= 𝑔 𝑘1 𝑎1 +𝑎2 +···+𝑎𝑛
|
||
𝑚 +𝛿 𝑧
|
||
𝑤𝑖 𝑖 1 1 (mod 𝑁) returns 𝑡𝑤ℎ ℎ and 𝑡𝑤′𝑗 𝑗 . We denote the malicious server successfully
|
||
𝑖=1 (9) determining the correct meaning of (𝑤ℎ , 𝑚ℎ ) and (𝑤′𝑗 , 𝑚′𝑗 ) as event 𝐸1 ,
|
||
∏
|
||
𝑛
|
||
𝑎 and denote the determining the value of 𝑟 as event 𝐸2 . We have:
|
||
𝑘1 𝑎 𝑖
|
||
= 𝑔 𝑤𝑖 𝑖 (mod 𝑁) 𝑛 𝑛 1
|
||
Pr(𝐸1 ) = 2𝑛+2 2𝑛+1
|
||
and Pr(𝐸2 ) = 𝑁−2 .
|
||
𝑖=1
|
||
∏𝑛 Therefore, the probability of the intelligent vehicle being deceived
|
||
𝑎 𝑛2
|
||
= 𝑦𝑖 𝑖 (mod𝑁) is: Pr(𝐸1 ∩ 𝐸2 ) = Pr(𝐸1 ) Pr(𝐸2 ) = (4𝑛2 +6𝑛+2)(𝑁−2) . Therefore, the checka-
|
||
𝑖=1 𝑛 2
|
||
bility rate of our proposed scheme MExpm is: 1 − (4𝑛2 +6𝑛+2)(𝑁−2) .
|
||
∏𝑛
|
||
( )𝑎
|
||
= 𝑢𝑖 + 𝑘𝑁 𝑖 (mod 𝑁)
|
||
𝑖=1
|
||
∏
|
||
𝑛 5. Simulation
|
||
𝑎
|
||
= 𝑢𝑖 𝑖 (mod 𝑁)
|
||
𝑖=1
|
||
In this section, we evaluate the performance of our proposed scheme
|
||
Obviously, when Eq. (9) holds, the correctness of the algorithm
|
||
MExpm by comparing it with the most advanced and representative
|
||
𝑅𝑒𝑐𝑜𝑣𝑒𝑟𝑦 is guaranteed and the proof is completed.
|
||
modular exponentiation offloading schemes reported in recent litera-
|
||
ture. Specifically, we consider MExp [3] and SMCExp [4] for secure
|
||
4.2. Security analysis batch modular exponentiation, as well as SoRSA [6] and EPExp [7]
|
||
for single modular exponentiation. These schemes reflect the latest
|
||
In this section, we demonstrate the privacy for computation of- advancements in both batch-oriented and single-operation settings and
|
||
∏
|
||
floading results. In MExpm, we firstly convert 𝑛𝑖=1 𝑢𝑖 𝑎𝑖 (mod 𝑁) into are widely recognized as benchmarks in the field. Notably, all of these
|
||
∏𝑛 𝑎
|
||
𝑖=1 𝑦𝑖 (mod 𝐿), then the exponents 𝑎𝑖 are transformed into 𝛿1 𝑧1 +
|
||
𝑖 algorithms are incorporated as baselines in our experimental evalua-
|
||
𝑚𝑖,𝑖∈[𝑛] and 𝛿2 𝑧2 + 𝑚′𝑖,𝑖∈[𝑛] . The public information in our scheme are tion, covering key performance indicators such as local computation
|
||
{𝑃 𝑎𝑟𝑎𝑚𝑠, 𝑇 𝐾, 𝑉 𝐾, 𝐴𝑢𝑥, 𝜎𝐸 , 𝜋𝐸 }, and the adversaries cannot obtain any time, end-to-end execution latency, communication overhead, and gas
|
||
information about secret information {𝑢𝑖,𝑖∈[𝑛] , 𝑎𝑖,𝑖∈[𝑛] , 𝑅𝐾, 𝑅𝑒𝑠𝑢𝑙𝑡}. consumption. Since MExpm is designed for batch modular exponenti-
|
||
ation, while SoRSA and EPExp are designed solely for single modular
|
||
Theorem 1. When the MEC server cheats the client, the misbehavior can exponentiation, for fairness, we also conduct the comparison for the
|
||
𝑛2
|
||
be detected with checkability rate 1 − (4𝑛2 +6𝑛+2)(𝑁−2) . case where the batch size 𝑛 = 1.
|
||
|
||
6
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
|
||
|
||
Fig. 4. Comparsion of time cost in 𝑢𝑎 mod 𝑁.
|
||
|
||
|
||
|
||
|
||
∏𝑛
|
||
Fig. 5. Comparison of time cost in 𝑖=1
|
||
𝑢𝑖 𝑎𝑖 mod 𝑁.
|
||
|
||
|
||
|
||
|
||
Fig. 6. Comparison of communication cost. Fig. 7. Comparison of storage cost.
|
||
|
||
|
||
7
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
usage, communication overhead, and storage overhead. We quantify
|
||
privacy using the checkability rate. Computation cost is measured by
|
||
the execution time (in milliseconds), where longer runtimes correspond
|
||
to higher resource consumption. We assess blockchain resource usage
|
||
on the Ethereum simulation platform, Remix, using gas consumption
|
||
as the metric. Communication overhead is defined as the total data
|
||
transmitted during offloading. Storage overhead is quantified by the
|
||
additional storage required on both the client and server sides.
|
||
|
||
|
||
5.3. Checkability
|
||
|
||
|
||
The details of checkability rate comparison of these four schemes
|
||
are shown in Fig. 3. As 𝑛 increases, our proposed scheme MExpm
|
||
always maintains a high checkability rate close to 1, while the other
|
||
three schemes gradually decrease. When 𝑛 = 1000, the checkability
|
||
1
|
||
rate of GExp is only 1001 . It means that a forged result can pass
|
||
the verification algorithm with the probability 1000
|
||
1001
|
||
. Both MExp and
|
||
SMCExp have the same checkability rate. However, when 𝑛 = 5000, the
|
||
Fig. 8. Comparison of Gas Consumption in Verify Algorithm when the size of checkability rate for these two schemes is only 0.975. Since MExpm
|
||
𝑟 is larger than 32 bits. uses a prime number 𝑁 with size 512, its checkability rate is higher
|
||
than 0.999.
|
||
|
||
|
||
5.4. Computation cost
|
||
|
||
|
||
5.4.1. Single modular exponentiation offloading
|
||
The comparsion results of single modular exponentiation offloading
|
||
could be found in Fig. 4. Compared with MExp and SMCExp, MExpm
|
||
demonstrates better performance either in 𝐾𝑒𝑦𝐺𝑒𝑛 algorithm or in
|
||
𝑆𝑒𝑡𝑢𝑝 algorithm. Particularly in 𝑉 𝑒𝑟𝑖𝑓 𝑦 algorithm, MExpm outperforms
|
||
these competitors. When it comes to SoRSA and EPExp, whose security
|
||
assumption is rather simple and cannot applied in real-world scenarios,
|
||
it seems unfair to compare them with schemes for batch modular
|
||
exponentiation with higher security standard.
|
||
|
||
|
||
5.4.2. Batch modular exponentiation offloading
|
||
Fig. 5 compares the computational cost of batch modular exponen-
|
||
tiation offloading. MExpm consistently requires fewer resources than
|
||
MExp across all phases. Although MExpm adds a recovery phase, it
|
||
Fig. 9. The relative saving ratio of MExp and MExpm. consists of a single modular inversion—incurring a fixed and negligible
|
||
overhead.
|
||
|
||
|
||
5.5. Communication and storage cost
|
||
5.1. Experimental setting
|
||
|
||
We implemented MExpm and MExp for batch modular exponentia- To simulate a low-bandwidth network environment, we set the
|
||
tion offloading, MExp, SMCExp, EPExp, SoRSA and MExpm for single transmission rate to 1 Kbps. Fig. 6 shows the communication cost of
|
||
modular exponentiation offloading using Python 3.8, along with the Py- the all competitors and MExpm in terms of the time cost of trans-
|
||
Cryptodome and GNU Multiple Precision (gmpy2 version 2.1.5) library. mission. For fair comparison, all schemes employ 1024-bit modulus.
|
||
All simulation experiments were conducted on the same Windows ma- For EPExp and SoRSA, whose authors assume that they only offload
|
||
chine equipped with an Intel Core TM i9-13900HX processor (running ciphertext to servers and do not need to take security of bases into
|
||
at 2.20 GHz) and 16 GB of memory. We perform each algorithm 100 consideration, and thus, they have lower communication cost com-
|
||
times and then computed the mean of its time cost. The size of prime pared with other schemes. Compared with MExp and SMCExp, MExpm
|
||
numbers selected in MExpm are all 512 bits, meaning the number 𝐿 shares the same communication cost in 𝐶𝑜𝑚𝑝𝑢𝑡𝑒 and 𝑉 𝑒𝑟𝑖𝑓 𝑦 algorithm.
|
||
is 1024 bits. For MExp and methods without offloading, we randomly SMCExp shows the least communication cost in 𝐾𝑒𝑦𝐺𝑒𝑛 and 𝑆𝑒𝑡𝑢𝑝
|
||
generate a pair of 1024-bit prime numbers. In our simulation, ‘MExpm algorithm. The results in Fig. 6 demonstrate that MExpm can deploy
|
||
w/o obfuscation’ denotes MExpm without the secure obfuscation oper-
|
||
a more secure offloading strategy while with similar communication
|
||
ation and ‘w/o offloading’ indicates the local execution of the modular
|
||
cost compared with other competitors. Fig. 7 shows the storage cost
|
||
exponentiation operation.
|
||
among all schemes, SoRSA needs to store 𝑛, 𝑞, 𝑝, 𝐶, 𝑘, 𝑡1 , 𝑡2 to conduct
|
||
5.2. Evaluation metrics verification and recovery, leading to the most demanding storage cost.
|
||
EPExp demonstrates the best storage performance, while it lacks a
|
||
To comprehensively evaluate MExpm, we assess its performance consideration of a malicious MEC server. Among MExp and SMCExp,
|
||
across five dimensions: privacy, computation cost, blockchain resource MExpm demonstrates the best performance in storage performance.
|
||
|
||
8
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
5.6. Gas consumption • Witness Tampering: The MEC server alters or forges witnesses
|
||
with the objective of deceiving the verifier and illegitimately
|
||
The results of the gas consumption comparison are demonstrated in passing the verification process.
|
||
Fig. 8. It can be observed that as 𝑟 increases, the gas consumption for
|
||
In our simulation, the Intelligent Vehicle (IV) executes the KeyGen
|
||
both MExpm and MExp grows steadily. However, the gap between them
|
||
algorithm entirely offline to generate the evaluation key 𝑇 𝐾, witness
|
||
widens significantly. For instance, when 𝑛 = 5, the gas fee difference
|
||
generation key 𝑉 𝐾, and auxiliary information 𝐴𝑢𝑥. The 𝑇 𝐾 and 𝑉 𝐾
|
||
rises from 7,504 gas at 𝑟 = 32 bits to 58,981 gas at 𝑟 = 256 bits.
|
||
are then transmitted to the MEC server and the Roadside Unit (RSU),
|
||
Furthermore, the gas cost of MExpm’s 𝑉 𝑒𝑟𝑖𝑓 𝑦 algorithm scales linearly
|
||
respectively. The RSU, acting as a lightweight verifier, executes the
|
||
with 𝑛 and is largely unaffected by 𝑟, whereas MExp’s verification cost
|
||
verification algorithm upon receiving computation results from the
|
||
increases with both 𝑟 and 𝑛. This highlights MExpm’s superior efficiency
|
||
MEC server.
|
||
in reducing computational and financial burdens for intelligent vehi- Experimental results demonstrate that our verification mechanism
|
||
cles, especially at larger scales. To provide a normalized view of these achieves a 100% detection rate for all injected malicious behaviors,
|
||
savings, we evaluate the relative saving ratio (SR) defined as with zero false positives under benign conditions. This confirms that
|
||
𝑛,𝑟 𝑛,𝑟
|
||
𝐺MExp − 𝐺MExpm the proposed scheme maintains strong security guarantees even in the
|
||
𝑆𝑅 = 𝑛,𝑟 presence of malicious MEC servers, thereby reinforcing its practicality
|
||
𝐺MExp
|
||
for real-world V2X deployments.
|
||
𝑛,𝑟 𝑛,𝑟
|
||
where 𝐺MExp , 𝐺MExpm is the gas consumption of MExp and MExpm with
|
||
same 𝑛 and 𝑟 respectively. As illustrated in Fig. 9, MExpm consistently 5.9. Deployment feasibility in real-world V2X environments
|
||
achieves 𝑆𝑅 > 0 across all tested parameter, with observed savings
|
||
The proposed scheme is designed for secure computation outsourc-
|
||
ranging from approximately 30% to 70%. These results confirm that
|
||
ing in resource-constrained vehicular networks. In such scenarios, the
|
||
MExpm delivers substantial resource savings over MExp, reinforcing its
|
||
primary metric for evaluation is whether the total computational cost
|
||
scalability and economic advantages.
|
||
incurred locally after outsourcing is significantly lower than that of
|
||
fully local execution. Therefore, as is common in the literature on com-
|
||
5.7. Economic analysis of gas savings
|
||
putation outsourcing, we perform all experiments — including the com-
|
||
putation algorithm, verification algorithm, and a non-outsourced base-
|
||
To further assess the practical impact of our scheme in real-world line — on the same hardware platform. This ensures a fair and repro-
|
||
deployments, we provide an economic estimation of gas savings ducible comparison under identical computational conditions, thereby
|
||
achieved by the proposed MExpm scheme compared with the represen- directly demonstrating the benefits of outsourcing.
|
||
tative baseline MExp, particularly in the context of blockchain-based In the proposed system, the Service Authority (SA) is responsible for
|
||
smart contract verification. As shown in Fig. 8, the gas cost of each handling the bulk of initialization tasks, such as modulus generation,
|
||
offloaded batch modular exponentiation result increases with both the base obfuscation, and parameter distribution. This design choice aligns
|
||
batch size 𝑛 and the bit length of the randomness parameter 𝑟. When 𝑛 = with the practical division of labor in vehicular networks, reducing
|
||
1 and bit length of 𝑟 is 32 bits, MExp incurs 24,013 gas while MExpm the computational burden on field devices. The Intelligent Vehicle (IV)
|
||
requires only 16,509 gas, leading to a difference of 7504 gas per executes the KeyGen algorithm to generate the evaluation key 𝑇 𝐾,
|
||
verification. The average gas price is approximately 30 Gwei (1 Gwei = witness generation key 𝑉 𝐾, and auxiliary information 𝐴𝑢𝑥. Crucially,
|
||
10−9 ETH), the ETH/USD exchange rate is approximately $4, 000, and 1 the KeyGen algorithm can be performed entirely offline before the
|
||
million gas cost approximately $120 on Ethereum networks. Therefore, online phase, ensuring that no additional delay is introduced when
|
||
the savings can be translated as initiating the outsourced computation. Once 𝑇 𝐾 is generated, the IV
|
||
transmits 𝑇 𝐾 to the MEC server for performing the computation tasks.
|
||
Gas Savings = 7,504 gas × 0.03 USD∕1,000,000 ≈ 0.90 USD In real deployments, RSUs are lightweight verification devices typi-
|
||
Consider a practical usage scenario where each intelligent vehicle cally deployed at traffic intersections or along highways, where power
|
||
offloads batch modular exponentiation tasks 10 times per day (e.g., for supply and network connectivity can be unstable. To emulate these
|
||
authentication, key negotiation, digital signatures, etc.), the annual constraints, we configure the RSU role on a lightweight laptop and
|
||
number of invocations is 10 (tasks/day)×365 (days/year) = 3,650 tasks/ limit the network transmission rate to 1 Kbps, thereby simulating a
|
||
year. Thus, the total annual gas cost saving per vehicle is: 0.90 realistic low-bandwidth vehicular environment. Meanwhile, the Service
|
||
Authority (SA) undertakes the bulk of initialization tasks, ensuring that
|
||
USD/task × 3,650 tasks/year ≈ 𝟑𝟐𝟖𝟓𝐔𝐒𝐃∕𝐲𝐞𝐚𝐫. This estimation high-
|
||
RSUs and IVs remain computationally efficient during the online phase.
|
||
lights the substantial economic benefits of MExpm when deployed at
|
||
This deployment-oriented design, together with our simulation set-
|
||
scale in large IoV systems. For a fleet of 10,000 vehicles, the projected
|
||
tings, ensures that the evaluation faithfully reflects real-world lim-
|
||
gas savings could exceed 32.8 million USD annually.
|
||
itations while remaining reproducible. Consequently, the proposed
|
||
scheme is shown to be both practically feasible and robust for secure
|
||
5.8. Robustness evaluation against malicious MEC servers
|
||
computation outsourcing in V2X environments.
|
||
|
||
To address potential security risks in practical deployments, we 6. Conclusion and future work
|
||
conducted robustness experiments simulating malicious Mobile Edge
|
||
Computing (MEC) servers that deviate from the prescribed computation In this paper, we propose MExpm, a secure and efficient computa-
|
||
protocol. Such adversarial behaviors may include, but are not limited tion offloading scheme for batch modular exponentiation in Vehicle-
|
||
to: to-Everything (V2X) communications. Our proposed scheme addresses
|
||
critical challenges in V2X systems, such as computational burden,
|
||
• Forged Results: The MEC server deliberately returns computa- latency, and privacy concerns, by leveraging Mobile Edge Computing
|
||
tion results that deviate from the prescribed algorithm, thereby (MEC) servers and blockchain technology. Our scheme achieves several
|
||
attempting to mislead the verifier regarding the correctness of the significant improvements over existing methods. It ensures fairness
|
||
computation. in computation offloading by using smart contracts, provides high
|
||
• Partial Omission or Manipulation: The MEC server selectively checkability to detect any misbehavior by MEC servers, and enhances
|
||
omits partial computation results or manipulates intermediate privacy protection through secure obfuscation and logical split tech-
|
||
values with the intent of reducing its own computational work- niques. These features make MExpm particularly well-suited for various
|
||
load. real-time applications in V2X systems. These include
|
||
|
||
9
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
• Real-time Cryptographic Operations: MExpm can offload [6] H. Zhang, J. Yu, C. Tian, L. Tong, J. Lin, L. Ge, H. Wang, Efficient and secure
|
||
resource-intensive cryptographic tasks, such as digital signatures outsourcing scheme for rsa decryption in internet of things, IEEE Internet Things
|
||
J. 7 (8) (2020) 6868–6881.
|
||
and key exchanges, ensuring secure and efficient communication
|
||
[7] Q. Hu, M. Duan, Z. Yang, S. Yu, B. Xiao, Efficient parallel secure outsourcing of
|
||
with reduced latency. modular exponentiation to cloud for iot applications, IEEE Internet Things J. 8
|
||
• Safety-Critical Message Signature: Offloading the computation (16) (2020) 12782–12791.
|
||
of digital signatures (which rely on exponentiation) for emer- [8] K. Zhou, M. Afifi, J. Ren, Expsos: Secure and verifiable outsourcing of exponen-
|
||
gency braking alerts and collision avoidance warnings, with on- tiation operations for mobile cloud computing, IEEE Trans. Inf. Forensics Secur.
|
||
12 (11) (2017) 2518–2531.
|
||
chain smart contracts validating each signature to prevent tam-
|
||
[9] Y. Saleem, F. Salim, M.H. Rehmani, Integration of cognitive radio sensor
|
||
pering. networks and cloud computing: A recent trend, in: Cognitive Radio Sensor
|
||
• Privacy-Preserving Authentication: The scheme guarantees the Networks: Applications, Architectures, and Challenges, IGI Global, 2014, pp.
|
||
privacy of sensitive data, such as cryptographic bases and expo- 288–312.
|
||
nents, while allowing verification of computation results. This is [10] J. Wang, Y. Wang, H. Ke, Joint optimization for mec computation offloading
|
||
and resource allocation in iov based on deep reinforcement learning, Mob. Inf.
|
||
essential for secure authentication in V2X communications, pro-
|
||
Syst. 2022 (2022).
|
||
tecting both vehicles and infrastructure from malicious attacks. [11] L. Yao, X. Xu, M. Bilal, H. Wang, Dynamic edge computation offloading for
|
||
• Traffic Management Systems: MExpm can be integrated into internet of vehicles with deep reinforcement learning, IEEE Trans. Intell. Transp.
|
||
smart city infrastructures, supporting secure communication for Syst. (2022).
|
||
traffic management, tolling systems, and other applications where [12] R. Gennaro, C. Gentry, B. Parno, Non-interactive verifiable computing: Out-
|
||
sourcing computation to untrusted workers, in: Advances in Cryptology–CRYPTO
|
||
privacy and computation efficiency are crucial.
|
||
2010: 30th Annual Cryptology Conference, Santa Barbara, CA, USA, August 2010
|
||
15-19. Proceedings 30, Springer, 2010, pp. 465–482.
|
||
Although MExpm significantly reduces computation resources com-
|
||
[13] Y. Guan, H. Zheng, J. Shao, R. Lu, G. Wei, Fair outsourcing polynomial
|
||
pared to local execution, it introduces additional complexity due to en- computation based on the blockchain, IEEE Trans. Serv. Comput. 15 (5) (2021)
|
||
hanced security features. Future work should aim to design a more gen- 2795–2808.
|
||
eralized verifiable computation offloading framework that optimizes [14] H. Pagnia, F.C. Gärtner, et al., On the Impossibility of Fair Exchange Without a
|
||
the balance between security and computational efficiency. Trusted Third Party, Tech. Rep., Citeseer, 1999.
|
||
[15] A. Aloufi, P. Hu, Y. Song, K. Lauter, Computing blindfolded on data homomor-
|
||
phically encrypted under multiple keys: A survey, ACM Comput. Surv. 54 (9)
|
||
CRediT authorship contribution statement (2021) http://dx.doi.org/10.1145/3477139.
|
||
[16] J. Zhang, Z.L. Jiang, P. Li, S.M. Yiu, Privacy-preserving multikey com-
|
||
Sipeng Shen: Writing – review & editing, Writing – original draft, puting framework for encrypted data in the cloud, Inform. Sci. 575
|
||
Methodology, Conceptualization. Qiang Wang: Writing – review & (2021) 217–230, http://dx.doi.org/10.1016/j.ins.2021.06.017, https://www.
|
||
sciencedirect.com/science/article/pii/S0020025521006083.
|
||
editing, Writing – original draft, Methodology. Fucai Zhou: Writing –
|
||
[17] M. Cui, S. Zhong, B. Li, X. Chen, K. Huang, Offloading autonomous driving
|
||
review & editing, Supervision. Jian Xu: Writing – review & editing, services via edge computing, IEEE Internet Things J. 7 (10) (2020) 10535–10547.
|
||
Supervision. Mingxing Jin: Writing – review & editing. [18] J. Zhou, F. Wu, K. Zhang, Y. Mao, S. Leng, Joint optimization of offloading
|
||
and resource allocation in vehicular networks with mobile edge computing, in:
|
||
Declaration of competing interest 2018 10th International Conference on Wireless Communications and Signal
|
||
Processing, WCSP, IEEE, 2018, pp. 1–6.
|
||
[19] S. Yang, A task offloading solution for internet of vehicles using combination
|
||
The authors declare no competing interests.
|
||
auction matching model based on mobile edge computing, IEEE Access 8 (2020)
|
||
53261–53273.
|
||
Acknowledgments [20] H. Xu, W. Huang, Y. Zhou, D. Yang, M. Li, Z. Han, Edge computing resource
|
||
allocation for unmanned aerial vehicle assisted mobile network with blockchain
|
||
This work was supported in part by the National Natural Sci- applications, IEEE Trans. Wirel. Commun. 20 (5) (2021) 3107–3121.
|
||
[21] Y. Liu, H. Yu, S. Xie, Y. Zhang, Deep reinforcement learning for offloading and
|
||
ence Foundation of China under Grants 62202090, 62173101, and
|
||
resource allocation in vehicle edge computing and networks, IEEE Trans. Veh.
|
||
62372069, by Natural Science Foundation of Liaoning Province un- Technol. 68 (11) (2019) 11158–11168.
|
||
der Grant 2025-MS-046, by the Fundamental Research Funds for the [22] J. Kilian, Theory of Cryptography: Second Theory of Cryptography Conference,
|
||
Central Universities, China under Grant N2417006, and by Liaoning TCC 2005, Cambridge, MA, USA, February 10-12. 2005, Proceedings, vol. 3378,
|
||
Collaboration Innovation Center for CSLE under Grant XTCX2024-015. Springer, 2005.
|
||
[23] X. Ma, J. Li, F. Zhang, Efficient and secure batch exponentiations outsourcing
|
||
in cloud computing, in: 2012 Fourth International Conference on Intelligent
|
||
Data availability Networking and Collaborative Systems, IEEE, 2012, pp. 600–605.
|
||
[24] X. Chen, J. Li, J. Ma, Q. Tang, W. Lou, New algorithms for secure outsourcing
|
||
Data will be made available on request. of modular exponentiations, IEEE Trans. Parallel Distrib. Syst. 25 (9) (2013)
|
||
2386–2396.
|
||
[25] Y. Ren, N. Ding, X. Zhang, H. Lu, D. Gu, Verifiable outsourcing algorithms for
|
||
References modular exponentiations with improved checkability, in: Proceedings of the 11th
|
||
ACM on Asia Conference on Computer and Communications Security, 2016, pp.
|
||
[1] R. Sun, Y. Wen, N. Cheng, W. Wang, R. Chai, Y. Hui, Structural knowledge- 293–303.
|
||
driven meta-learning for task offloading in vehicular networks with integrated [26] M. Van Dijk, D. Clarke, B. Gassend, G.E. Suh, S. Devadas, Speeding up
|
||
communications, sensing and computing, J. Inf. Intell. (2024). exponentiation using an untrusted computational resource, Des. Codes Cryptogr.
|
||
[2] S. Yuan, Y. Fan, Y. Cai, A survey on computation offloading for vehicular 39 (2006) 253–273.
|
||
edge computing, in: Proceedings of the 2019 7th International Conference on [27] J. Ye, J. Wang, Secure outsourcing of modular exponentiation with single
|
||
Information Technology: IoT and Smart City, 2019, pp. 107–112. untrusted server, in: 2015 18th International Conference on Network-Based
|
||
[3] Y. Ding, Z. Xu, J. Ye, K.-K.R. Choo, Secure outsourcing of modular exponen- Information Systems, IEEE, 2015, pp. 643–645.
|
||
tiations under single untrusted programme model, J. Comput. System Sci. 90 [28] S. Li, L. Huang, A. Fu, J. Yearwood, Cexp: secure and verifiable outsourcing of
|
||
(2017) 1–13. composite modular exponentiation with single untrusted server, Digit. Commun.
|
||
[4] Q. Su, R. Zhang, R. Xue, Secure outsourcing algorithms for composite modular Netw. 3 (4) (2017) 236–241.
|
||
exponentiation based on single untrusted cloud, Comput. J. 63 (8) (2020) [29] C. Dong, Y. Wang, A. Aldweesh, P. McCorry, A. van Moorsel, Betrayal, distrust,
|
||
1271–1271. and rationality: Smart counter-collusion contracts for verifiable cloud comput-
|
||
[5] Y. Wang, Q. Wu, D.S. Wong, B. Qin, S.S. Chow, Z. Liu, X. Tan, Securely ing, in: Proceedings of the 2017 ACM SIGSAC Conference on Computer and
|
||
outsourcing exponentiations with single untrusted program for cloud storage, in: Communications Security, 2017, pp. 211–227.
|
||
Computer Security-ESORICS 2014: 19th European Symposium on Research in [30] J. Ellul, G.J. Pace, Runtime verification of ethereum smart contracts, in: 2018
|
||
Computer Security, Wroclaw, Poland, September 2014 7-11. Proceedings, Part I 14th European Dependable Computing Conference, EDCC, IEEE, 2018, pp.
|
||
19, Springer, 2014, pp. 326–343. 158–163.
|
||
|
||
|
||
10
|
||
S. Shen et al. Computer Standards & Interfaces 97 (2026) 104107
|
||
|
||
|
||
[31] M.R. Dorsala, V. Sastry, S. Chapram, Fair payments for verifiable cloud services [33] D. Xu, Y. Ren, X. Li, G. Feng, Efficient and secure outsourcing of modular
|
||
using smart contracts, Comput. Secur. 90 (2020) 101712. exponentiation based on smart contract, Int. J. Netw. Secur. 22 (6) (2020)
|
||
[32] S. Avizheh, M. Nabi, R. Safavi-Naini, K. M. Venkateswarlu, Verifiable computa- 934–944.
|
||
tion using smart contracts, in: Proceedings of the 2019 ACM SIGSAC Conference [34] G. Wood, et al., Ethereum: a secure decentralised generalised transaction ledger,
|
||
on Cloud Computing Security Workshop, 2019, pp. 17–28. (2014) 2017.
|
||
[35] S. Mahdavi-Hezavehi, Y. Alimardani, R. Rahmani, D. Rosaci, An efficient frame-
|
||
work for a third party auditor in cloud computing environments, Comput. J. 63
|
||
(1) (2020) 1285–1297.
|
||
|
||
|
||
|
||
|
||
11
|
||
|