Computation Costs Clause Samples
The Computation Costs clause defines how expenses related to computational resources or services are calculated and allocated between parties. It typically outlines which party is responsible for paying for processing time, data storage, or other computational needs, and may specify the method for determining these costs, such as by usage metrics or fixed rates. This clause ensures transparency and fairness in distributing the financial burden of computational activities, preventing disputes over unexpected or ambiguous charges.
Computation Costs. The computation costs are measured by counting the number of most compute intensive operations and taking their corresponding computational time into account. We denote the timing for the bilinear pairing as Tb, the point multiplication Tmp, point addition Tap, modular exponentiation Te, a symmetric encryption/decryption Ts, and hash operation Th. The timings of these operations have been computed in [25] on a personal computer with a 2.5 GHz CPU, an 8 GB RAM and Windows 7 as OS for an 80-bit security level. This corresponds with a hash function resulting in a 160-bit output and an EC of order 160, i.e., q = 160. For the timing of the same operations on a more constrained device, mimicking a SM, a single core 798 MHz CPU and 256 MB of RAM is chosen. We refer to [14] for the corresponding timings. In addition, similar as in [14], the time to execute a 128-bit arbiter PUF call on an embedded device MSP430 micro controller with 798 MHz CPU is derived from [26]. For the time to execute a fuzzy extractor generation operation, TFE.Gen, and a fuzzy extractor reconstruction operation, TRE.Rec, the code offset mechanism using the Bose-Chaudhuri-Hocquenghem (BCH) code is considered, as in [27]. Table 3 shows the comparison of the computational overheads between our scheme and [9–11,14]. As it can be seen, our scheme is offering a better overall computational complexity compared to most of the other schemes. The complexity is very close to the scheme of [12]. However, the scheme of [11] is still slightly more efficient at the side of the SM. This cost in performance needs to be paid in order to offer resistance in the CK security model. In addition, there is a huge difference in complexity with [14] at the SM, as the timing in [14] strictly depends on the efficiency of the PUF and the fuzzy extractor and no EC operations are computed. However, it should be noted that the fuzzy extractor of the PUF has several severe limitations [15]. Scheme Cost at SM ms Cost at SP µs [9] [10] 4Tmp + 4Tap + Te + 5Th ≈31.59 3Tmp + 2Tap + 2Tb + Te + 5Th ≈38.27 Table 3. Comparison of computational complexity among other schemes. 3Tmp + Tap + Te + 6Th ≈25.72 2Tmp + Tap + 2Tb + Te + 6Th ≈37.28 [11] 2Tmp + Te + 5Th ≈19.79 3Tmp + Tb + Te + 5Th ≈21.26 [12] 4Tmp + Tap + 5Th ≈23.80 4Tmp + Tap + 5Th ≈3.98 [14] 5Th + TPUF + TFE.Rec ≈ 3.53 6Th + TRE.Gen ≈1170 Ours 4Tmp + Tap + Ts + 5Th ≈23.81 4Tmp + 2Tap + Ts + 5Th ≈3.99
Computation Costs. To achieve exact computational costs is impossible and also impracticable. Different implementations of an identical group key agreement scheme bring different results. Even the same implementation cannot guarantee same result in different environments. However, it can estimate the computation costs by identifying the expensive and time-critical operations. The protocol can be ignored the concrete operation time, and only compare the number of such operations. Some computations can be pre-performed before protocol run or computed when the system is idle. Hence only the operations which have to be performed sequentially should be considered. Those operations are denoted by serial operations.