3.6 Summary
5.1.4 Performance Evaluation
This section presents our evaluation results for the proposed scheme in terms of computation and communication loads as well as the storage load. We will present both numerical results and the experimental results. Finally, we give a brief discus- sion as well as the comparison between our proposed scheme and existing work. In the following part of this section, we assume the total number of attributes is n. We denote one scalar multiplication on the elliptic curve by an EXP , and one point addition operation by a MUL.
1. Numerical Results
Computation Load on the Authority The authority is responsible for execu- tion of three algorithms: Setup, KeyGen, and Encryption. The main computation load of the algorithm Setup is caused by the calculation of hi,0 and hi,1, which involves 2n EXP operations in total. The algorithm KeyGen is responsible for computing the secret key SK. The main computation load is caused by the calcu- lation of {Di = hr
i, ¯Xi}∀i∈Zn. It accounts for n EXP operations. KeyGen consumes
(n + 3) EXP operations in total as the secret key components D, D0, and D00 each accounts for one EXP . The main computation load of the algorithm Encryption comes from items {Ci = (gsi, Ci,0, Ci,1)}∀i∈Zn which represent 3n EXP operations9.
In total the number of EXP operations required by Encryption is (3n + 3) since ˇ
C and ˆC consume 1 and 2 EXP operations respectively. In addition, Encryption
requires one one-way hash operation. The bilinear pairing operation required by the item ˜C can be ignored since we can pre-compute e(g, g)α. We do not count the integer field operations into our computation load because they account for a trivial
9Note that since the authority knows the master secret key M K, she can first calculate the
exponents and then compute Ci,j, j = 0|1, by one EXP operation. We present the calculation of Ci,j by two EXP ’s and one M U L in the algorithm just for clear description of our scheme. It is
the similar case for gs0
MUL EXP pairing
Setup 10 0 2n 0
KeyGen10 0 n+3 0
Encryption11 0 3n+3 0
Decryption11 n 0 n+4
Table 5.2: Summary of cryptographic operations part as compared to operations over elliptic curves.
Computation Load for Users Computation load on the user side mainly caused by the Decryption operation. According to our scheme description, following operations are required to decrypt a ciphertext: (2n + 3) pairings and one hash. In most cases, a pairing operation is more expensive than an EXP operation or a MUL operation. Therefore, it is desirable to minimize the number of pairing operations. For this purpose, we can modify our decryption algorithm a little bit. We show this by expanding the calculation of F in Step 2 of Decryption:
F = n−1Y i=0 Fi = n−1Y i=0
e(Di, gsi)e(Ci,Xi, D
0)/B Xi = e( n−1Y i=0 Ci,Xi, D 0) ·n−1Y i=0 (e(Di, gsi)/BX i) (5.7)
Instead of computing e(Ci,Xi, D
0) for each attribute as shown in Step 1, users can first multiply all Ci,Xi for all i in Zn, and then apply one pairing between D
0 and the product of the multiplication as is shown in Eq. (7). This revision saves (n − 1) pairings and causes n MU L operations on the user side. The computation load of Decryption algorithm now becomes (n + 4) pairings, n MUL operations and
10Operations performed by the authority. 11Operations performed by users.
one hash. We do not take into count the computation of dividing BXi’s as they are
trivial as compared to operations on elliptic curves. Table 5.2 concludes the main cryptographic operations required by our design12.
Communication Load Our ciphertext is composed of four parts: ˜C, ˇC, { ˆCj}j=0,1,
{Ci}∀ i∈Zn. Each Cihas three parts: gsi, Ci,0, Ci,1. Therefore, the ciphertext contains
(3n + 3) G0 and 1 GT group elements in total.
Storage Load for Users The main storage load of each user is for the secret key SK which represents (n + 3) G0 group elements in total.
2. Experimental Results
In our experiment, we implement our algorithms based on the Pairing-Based Crypto (PBC) library [96]. We test our program on Ubuntu 8.04 with Intel Pentium D 3.40GHz CPU.
The Choice of Elliptic Curves In our experiment, we test on three types of elliptic curves: supersingular curves (type A), MNT curves (type D), and type F curves as is named in [96]. Type A curves enable fast pairing, while type D and type F curves require short group element. In particular, type F curves provides 1920-bit RSA security with only 160-bit group element. For type D curves, we test on two kinds of curves, namely d159 and d201. The detailed description of these curves can be found in [96].
To understand how the choice of elliptic curves affects our ciphertext size, it’s necessary to discuss two kinds of groups characterized by bilinear maps: symmetric bilinear groups and asymmetric bilinear groups. The bilinear map in the former case has the form: e : G0× G0 → GT, while the latter has the form: e : G1× G2 →
GT, G1 6= G2. Type A curves are characterized by having symmetric bilinear groups.
Type D and type F curves are characterized by having asymmetric bilinear groups. For fast pairing, we usually choose elliptic curves from symmetric bilinear groups with small embedding degrees. For example, type A curves have embedding degree of 2 and base field size of G0 is 512 bits. On the other hand, for short group size, we
usually choose elliptic curves from asymmetric bilinear groups with high embedding degrees. For example, type F curves have embedding degree of 12. This turns out that the base field size of G1is just 160 bits. The embedding degree of type D curves
is 6. The base field size of G1 is just 170 bits for 1020-bit RSA security.
Ciphertext Size Our design uses symmetric bilinear groups by default. There- fore, the ciphertext size is 512(3n + 4) bits in the case of type A curves as both G0
and GT can be represented by 512 bits. To achieve short ciphertext size, we can easily modify our design by using asymmetric bilinear groups. After this revision the ciphertext would just contain the following group elements: (2n + 3) G1, n G2,
and 1 GT. Table 5.3 gives a summary of our ciphertext size under the selected curves. As shown in Table 5.3, type A curves (supersingular) exhibits the longest ciphertext while type F curves provides the shortest ciphertext.
type A type d159 type d201 type F
512(3n+4) 159(5n+6) 201(5n+6) 160(4n+9)
Table 5.3: Ciphertext sizes (bits) for different elliptic curves
Computation Load In our experiment, we run our algorithms over elliptic curves of type A (SS), d159, d201, and type F respectively. The number of attributes is chosen to be 4, 8, 16, 32, 64, 128, and 256. The experiment results are shown in Fig.5.1(a)-Fig.5.1(d). From these figures we can see that the computation load of our scheme is linear to the number of attributes, which verifies our numerical analysis results in Table 5.2. As is analyzed in Table 5.2, computation overhead of algorithm Setup, KeyGen, and Encryption is dominated by scalar multiplication
4 8 16 32 64 128 256 102 103 104 Number of Attributes Setup Time (ms) SS MNT:D201 MNT:D159 F (a) Setup 4 8 16 32 64 128 256 101 102 103 104 Number of Attributes
Key Generation Time (ms)
SS MNT:D201 MNT:D159 F (b) KeyGen 4 8 16 32 64 128 256 101 102 103 104 Number of Attributes Encryption Time (ms) SS MNT:D201 MNT:D159 F (c) Encryption 4 8 16 32 64 128 256 101 102 103 104 105 Number of Attributes Decryption Time (ms) SS MNT:D201 MNT:D159 F (d) Decryption
Figure 5.1: Experiment results on computation load.
operations on elliptic curves. Therefore, the elliptic curves with small base field size are more efficient than others. This is verified by Fig.5.1(a)-Fig.5.1(c) which show that type F curves are the most efficient. Type A (SS) curves are the least efficient as is shown in Fig.5.1(a) and Fig.5.1(b). In Fig.5.1(c), however, type A (SS) curves outperform type d201 curves and exhibit comparable encryption efficiency with d159 curves. This is because Encryption algorithm also involves n scalar multiplication operations on group G2. The base field size of G2 in the case of type F, d159, type A,
and d201 are 320 bits, 477 bits, 512 bits, and 603 bits respectively. As the base field size of G2 is much larger than that of G1, these n scalar multiplication operations
the worst. This coincides with our previous analysis.
Specifically, from these figures we can see that, in the case of 256 attributes our
Encrytion algorithm takes about 0.7 seconds under type F curves and 1 second
under type D and F curves. Our Decryption algorithm takes less than 2 second for type A curves in the case of 256 attributes. In the case of 64 attributes, Decryption takes about 0.3 seconds for type A curves and 1 second for type D curves.
3. Discussion and Comparison
From above numerical and experimental results, we can see that our scheme exhibits an acceptable computation load if the number of attributes are carefully chosen. Actually, the computation overhead for both ECC and bilinear pairing op- erations can be further reduced to the magnitude of µs under hardware implemen- tations [52]. Moreover, as the computing power of processors is increasing rapidly, computation overload should not be a problem. What actually matters is the com- munication overload as bandwidth is a limited resource under environments such as wireless networks. Fortunately, the communication overload of our scheme grows linearly to the number of attributes only. Since attributes are shared by unlim- ited number of users, communication overload of our scheme can be well controlled even in the case of large-scale application scenarios. As a matter of fact, even in large-scale systems, the number of attributes required could be relatively small. To evaluate the performance of our scheme, we can compare it with current work. To the best of our knowledge, the only existing work that addresses the similar issue is proposed by Barth et al. [45]. In that scheme, identities of the recipients are pro- tected by encrypting the message using every user’s public key. The computational load as well as the ciphertext size grow linear to the group size. Assume we are using 1024 bit RSA, the ciphertext size would be 1024N bits, where N is the total
number of users. This represent a huge communication load in large-scale applica- tions and not applicable for large-scale application scenarios. Moreover, our scheme also protects the number of the intended users while [45] does not.