AIB-OR: Improving Onion Routing Circuit Construction Using Anonymous Identity-Based Cryptosystems

The rapid growth of Internet applications has made communication anonymity an increasingly important or even indispensable security requirement. Onion routing has been employed as an infrastructure for anonymous communication over a public network, which provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis. However, existing onion routing protocols usually exhibit poor performance due to repeated encryption operations. In this paper, we first present an improved anonymous multi-receiver identity-based encryption (AMRIBE) scheme, and an improved identity-based one-way anonymous key agreement (IBOWAKE) protocol. We then propose an efficient onion routing protocol named AIB-OR that provides provable security and strong anonymity. Our main approach is to use our improved AMRIBE scheme and improved IBOWAKE protocol in onion routing circuit construction. Compared with other onion routing protocols, AIB-OR provides high efficiency, scalability, strong anonymity and fault tolerance. Performance measurements from a prototype implementation show that our proposed AIB-OR can achieve high bandwidths and low latencies when deployed over the Internet.


Introduction
The rapid development of network technology has made anonymous communication an increasingly important security requirement for many network applications [1]. While end-toend encryption can protect the data content of communications from unauthorized access, it does not conceal all the relevant information that two communicating parties are communicating. For example, routing information is still transmitted in the clear because routers need to know packets' destinations in order to route them in the right direction. Traffic analysis can also be done by watching particular data moving through a network, by matching the amount of data, or by examining coincidences, such as connections opening and closing at about the same time.
In many situations, it is highly desirable or indispensable for users to be able to preserve the communications anonymity. For example, an abrupt change in the traffic pattern may indicate some forthcoming activities in a tactical military communication network. This can be extremely dangerous in that adversaries can easily identify critical network nodes and then launch targeted attacks on them. In addition, people have a strong desire to remain anonymous when pursuing sensitive information in order to avoid unnecessary trouble.
Over the years, a large number of anonymity networks have been proposed and some have been implemented. Among them, onion routing has been widely employed as an infrastructure for private communication over a public network.

Related Work
Identity-Based Cryptography. To simplify certificate management in tradition public key infrastructure, Shamir [2] first introduced the concept of identity-based public key cryptography, where an entity's public key can be publicly computed from his recognizable identity information, such as a complete name or an e-mail address, while the corresponding private key is generated by a trusted third party named as private key generator (PKG).
The first practical and secure identity-based encryption (IBE) scheme was constructed from bilinear pairings by Boneh and Franklin [3]. Since then, various IBE schemes, identitybased signature schemes and identity-based key agreement (IBKA) protocols have been proposed [4].
For example, considering a situation where a sender would like to encrypt a message for t receivers, the sender must encrypt the message t time using conventional IBE schemes. To improve the performance, Baek et al. [5] introduced the notion of multi-receiver IBE scheme, and proposed an efficient provably secure multi-receiver IBE scheme from bilinear pairings. To guarantee receiver's privacy, Boyen and Waters [6] proposed an anonymous IBE scheme, where the ciphertext does not leak the identity of the recipient.
Later, Fan et al. [7] introduced the concept of anonymous multi-receiver IBE (AMRIBE) scheme and proposed an efficient AMRIBE scheme from bilinear parings. In an AMRIBE scheme, one can examine whether himself is a selected receiver or not. Nobody, except the sender, knows who the other selected receivers are. Subsequently, Chien [8] pointed out that Fan et al.'s AMRIBE scheme only provides receiver anonymity for outsider attackers or non-selected receivers, and presented an improved AMRIBE scheme. However, only heuristic arguments for security proofs are presented. Tseng et al. [9] proposed a new AMRIBE scheme that was proved to be semantically secure against adaptive chosen ciphertext attacks in the random oracle model under the Gap-BDH assumption.
Sakai et al. proposed the first non-interactive IBKA protocol from bilinear pairing, where the established key consists of only one participant's identity-based private key and the other participant's identity. Thus, the established key can not be used as a session key because it always establishes the same (secret) key for the same entities in each run of the protocol. Kate et al. [10] extended Sakai et al.'s IBKA protocol, and proposed an identity-based one-way anonymous key agreement (IBOWAKE) protocol to provide unconditional anonymity for participants by replacing the identities of the participants by pseudonyms. Unfortunately, Kate et al. IBOWAKE protocol is insecure against man-in-the-middle (MIMA) attack because it can not authenticate the communication entities.
Certificateless Cryptography. The concept of certificateless public key cryptography was first introduced by Al-Riyami and Paterson [11], which combines the advantages of traditional certificate-based public key cryptography and identity-based public key cryptography. In a certificateless cryptosystem, the key generation center (KGC) does not have access to the entity's private key, the KGC derives a partial private key from the entity's identity and the master secret key. The entity then combines the partial private key with some secret information to generate the actual private key. Thus, certificates are not considered necessary anymore to guarantee the authenticity of public keys in traditional certificate-based public key cryptography, and at the same time the private key is not fully determined by the KGC to prevent the inherent key escrow problem in identity-based public key cryptography.
Certificateless public key cryptography has received a significant attention in recent years, several certificateless encryption schemes, certificateless signature schemes and certificateless key agreement protocols were presented. For example, Catalano et al. [12] introduced the concept of anonymous certificateless key agreement and proposed two constructions.
Attribute-Based Encryption. Attribute-based encryption (ABE) was first introduced by Sahai and Waters [13] with the original goal of providing an error-tolerant IBE that uses biometric identities. ABE can be viewed as an extension of the notion of IBE in which user identity is generalized to a set of descriptive attributes instead of a single string specifying the user identity. Compared with IBE, ABE has significant advantage as it achieves flexible one-to-many encryption instead of one-to-one, it is envisioned as a promising tool for addressing the problem of secure and fine-grained data sharing and decentralized access control.
ABE have drawn extensive attention from both academia and industry in recent years, many ABE schemes have been proposed [14][15][16] and several cloud-based secure systems using ABE have been developed [17][18][19]. There are two types of ABE depending on which of private keys or ciphertexts that access policies are associated with.
In a key-policy attribute-based encryption (KP-ABE) system, ciphertexts are labeled by the sender with a set of descriptive attributes, and users' private keys are issued by the trusted attribute authority are associated with access policies (also called access structures) that specify which type of ciphertexts the key can decrypt. In a ciphertext-policy attribute-based encryption (CP-ABE) system, when a sender encrypts a message, they specify a specific access policy in terms of access structure over attributes in the ciphertext, stating what kind of receivers will be able to decrypt the ciphertext. Users possess sets of attributes and obtain corresponding secret attribute keys from the attribute authority, such a user can decrypt a ciphertext if his/her attributes satisfy the access policy associated with the ciphertext.
Onion Routing. Onion routing was first proposed by Reed, Syverson and Goldschlag [20,21]. In onion routing, for a given connection, the sender selects a sequence of routers, known as a circuit, that will be used to forward the sender's traffic. The sender establishes a circuit by first directly opening a circuit with the first router, and then iteratively extending the circuit by sending message over the existing circuit. Messages are encrypted with the key of each router in the circuit in the reverse order that the routers appear. Like someone peeling an onion, each onion router removes a layer of encryption to uncover routing instructions, and sends the message to the next router where this is repeated. This prevents these intermediary nodes from knowing the origin, destination, and contents of the message.
In the original onion routing protocol [22], each onion router is equipped with a pair of public and private key. The source uses the public keys of the intermediate routers with the top layer encrypted with the public key of the router immediately next to the source. The intermediate routers then use their own corresponding private keys to decrypt the packet and obtain the information about the next hop in the network. The packets thus routed and forwarded by each intermediate genuine node, eventually reach the destination. The advantage here is that if any one of the routers is compromised by an adversary, even then, the other components remain beyond the reach, because of being encrypted using a different public key. However, it is evident that a sender is required to encrypt a message as many times as is the number of intermediate onion routers.
Kate et al. [10] presented a pairing-based onion routing (PB-OR) protocol by using an IBOWAKE protocol. Catalano et al. [12] then proposed a certificateless onion routing (CL-OR) protocol by using an anonymous certificateless key agreement protocol. Later, Catalano et al. [23] proposed a fully non-interactive onion routing protocol with forward secrecy by using a forward-secure IBE scheme. Recently, Doshi et al. [24] proposed an onion routing circuit construction called attribute-based onion routing (AB-OR) using the Bethencourt et al. CP-ABE scheme [15]. Here the access policy is boolean formula over routers' identities and the access policy is sent in the clear along with the ciphertext. Thus, AB-OR provides neither recipient anonymity nor route anonymity.

Motivation and Our Contributions
Compared to the original onion routing protocol, onion routing protocols proposed in recent years have greatly improved in terms of efficiency and anonymity. However, there are still three drawbacks in the existing onion routing protocols.
• Failure tolerance is relatively poor. The palsy of any one of the intermediate onion router will result in the palsy of the entire onion routing process.
• Recipient anonymity is not strong enough. The last onion router will know the identity of the recipient.
• Communication anonymity is weak. Each intermediate onion router needs to know the identity of the next hop router on the path, which impairs the communication anonymity.
In this paper, we first improve Kate et al.'s IBOWAKE protocol [10] and Tseng et al.'s AMRIBE scheme [9], then we propose a new onion routing circuit construction called anonymous identity-based onion routing (AIB-OR) by integrating our improved IBOWAKE protocol with AMRIBE scheme in onion routing circuits construction. Compared to PB-OR and CL-OR, our proposed AIB-OR achieves both efficiency improvement and anonymity enhancement. This paper makes three primary contributions in the field of anonymous communication.
• The efficiency of onion routing circuit construction is improved. The performance of AIB-OR surpasses those of PB-OR and CL-OR, requiring significantly less computation and fewer network communications. Unlike existing onion routing protocols, Our proposed AIB-OR only requires the sender to encrypt the message twice, irrespective of the number of intermediate onion routers.
• Failure tolerance of onion routing circuit construction is provided. The sender can select any one of the path through which to forward the packet out of the multiple paths at its disposal in the proposed AIB-OR.
• Anonymity of onion routing circuit construction is enhanced. The sender, the recipient and the intermediate onion routers are anonymous to others, no one knows the real identities and location of the sender, the intermediate onion routers, or the recipient. Adversaries cannot trace a packet flow back to its sender or the recipient. Nobody, except the sender, knows the real routing path between the sender and the recipient.

Paper Organization
The rest of this paper is organized as follows. Some necessary preliminary work and our improved IBOWAKE protocol and AMRIBE scheme are introduced in Section 2. The proposed AIB-OR model and construction are described in Section 3. Efficiency and security analysis of our AIB-OR are discussed in Section 4. Performance test of PB-OR and our AIB-OR are explained in Section 5. Finally, we conclude our work in Section 6.

Notations
To facilitate further description, we introduce notations in Table 1.

Bilinear Group Generator and Complexity Assumptions
Definition 1 The bilinear group generator G is an algorithm that takes as input a security parameter κ and outputs a bilinear group (q,G 1 ,G 2 , ê, P), where q is a prime of size 2 κ , G 1 and G 2 are cyclic groups of order q, P is a generator of G 1 , and ê:G 1 ×G 1 ! G 2 is a bilinear map with the following properties: • Bilinearity: For a; b $ Z Ã q , we have ê(aP, bP) = e(P, P) ab .

Definition 2 (Bilinear Diffie-Hellman Assumption)
The BDH assumption in a prime order bilinear group (q, G 1 , G 2 , e^, P) generated by G(1 κ ) is that if a tuple hP; aP; bP; cPi 2 G ð4Þ 1 is given for unknown a; b; c $ Z Ã q , there is no probabilistic polynomial-time (PPT) adversary A can compute e^(P, P) abc 2 G 2 with non-negligible advantage [3].
Definition 3 (Decisional Bilinear Diffie-Hellman Assumption) The DBDH assumption in a prime order bilinear group (q, G 1 , G 2 , e^, P) generated by G(1 κ ) is that if a tuple hP; aP; bP; cP; Ti 2 G ð4Þ 1 ñG 2 is given for unknown a; b; c $ Z Ã q and T $ G 2 , there is no PPT adversary A can decide whether T = e^(P, P) abc with non-negligible advantage [4]. Definition 4 (Gap Bilinear Diffie-Hellman Assumption) The Gap-BDH assumption in a prime order bilinear group (q, G 1 , G 2 , e^, P) generated by G(1 κ ) is that if a tuple hP; aP; bP; cPi 2 G ð4Þ 1 is given for unknown a; b; c $ Z Ã q , there is no PPT adversary A can compute e^(P, P) abc 2 G 2 with the help of the DBDH oracle with non-negligible advantage. The DBDH oracle means that given a tuple hP; aP; bP; cP; Ti 2 G ð4Þ 1 ñG 2 , outputs 1 if T = e^(P, P) abc and 0 otherwise [9].

Our Improved IBOWAKE Protocol
Kate et al. [10] proposed an IBOWAKE protocol that was proved to be secure in the random oracle model under the BDH assumption. The core idea of Kate et al.'s IBOWAKE protocol is to replace the identity hashes with pseudonyms generated by users, and each user can randomly generate many possible pseudonyms and the corresponding private keys.
To avoid impersonation and MIMA attacks, it is desirable that only the pseudonym with valid certificate can be used as an encryption key during an anonymous communication session. For privacy purposes, we require that the PKG will not know the real pseudonym of an entity and the corresponding certificate. Our improved IBOWAKE protocol is described as follows.
• Extract: Given a user's identity ID, the PKG computes Q ID = H 0 (ID) and d ID = sQ ID . Finally, the PKG sends the user's private key d ID to the user via a secure channel.
• PNGen: An entity X chooses k X $ Z Ã q , computes PN X = k X P and sk PN X = k X P pub = sPN X . Finally, the entity X sets PN X and sk PN X as his pseudonym and the corresponding private key, respectively.
• BlindCert An entity X with a pseudonym PN X chooses r X $ Z Ã q , generates a masked pseudonym by computing PN 0 X ¼ r X H 0 ðPN X Þ, X then sends PN 0 X to the PKG. The PKG computes s 0 X ¼ sPN 0 X and sends the signature s 0 X to X. Upon receiving s 0 X , X verifies s 0 X by checkinĝ eðs 0 X ; PÞ ¼êðPN 0 X ; P pub Þ. If the equation holds, X then computes s X ¼ r À1 X s 0 X ¼ sH 0 ðPN X Þ, and obtains his pseudonym certificate hPN X , σ X i. Anyone can verify entity X's pseudonym certificate hPN X , σ X i by testing ê(σ X , P) = ê(H 0 (PN X ), P pub ).
• Key Agreement: Suppose Alice wants to perform a session key agreement with Bob. Alice knows Bob's identity ID B and wishes to remain anonymous to Bob, Alice and Bob perform the following steps: • Alice generates her pseudonym PN X and gets her pseudonym certificate hPN A , σ A i by performing the PNGen algorithm and the BlindCert algorithm, respectively.
• Alice computes the session key K A, B = ê(sk PN A , Q ID B ). Alice then sends her pseudonym certificate hPN A , σ A i to Bob.
• Upon receiving Alice's pseudonym certificate hPN A , σ A i, Bob verifies Alice's pseudonym certificate by testing ê(σ A , P) = ê(H 0 (PN A ), P pub ). If the equation holds, Bob then computes the corresponding session key K A, B = ê(PN A , d ID B ) by using his private key d ID B .
Note that the BlindCert algorithm is in fact a blind Boneh-Lynn-Shacham (BLS) signature scheme [25], which is proved to be existentially unforgeable under adaptive chosen-message attacks under the computational Diffie-Hellman assumption in the random oracle model.

Our Improved AMRIBE Scheme
Tseng et al. [9] proposed an AMRIBE scheme that was proved to be semantically secure against adaptive chosen ciphertext attacks in the random oracle model under the Gap-BDH assumption.
Tseng et al.'s AMRIBE scheme [9] is an extension of Boneh and Franlin's IBE scheme [3] to multiple recipients scenario. Rapid enhanced-security asymmetric cryptosystems transform (REACT) [26] is an important tool for any asymmetric encryption schemes to achieve IND-CCA secure from IND-CPA secure. We apply the REACT transformation in Tseng et al.'s AMRIBE scheme to further improve the efficiency without compromising security.
• Extract: Given a user's identity ID, the PKG computes Q ID = H 0 (ID) and d ID = sQ ID . Finally, the PKG sends the user's private key d ID to the user via a secure channel.
• Decrypt: Upon receiving a ciphertext C = hc 0 , c 1 ,. . ., c t−1 , U, W, λi that is encrypted using identities ID ¼ fID i g t i¼1 , a selected receiver with identity ID j 2 ID first computes v j = j mod q and m 0 = D H 2 (k 0 ) (W). The receiver then sets λ 0 = H 3 (m 0 , k 0 , c 0 , c 1 ,. . .c t−1 , U, W), and tests whether λ 0 = λ holds or not. If it does not hold, the recipient rejects the ciphertext. Otherwise, the recipient outputs m as the decryption of C.

The AIB-OR Protocol
The system model for our proposed AIB-OR protocol is illustrated as Fig. 1, in which the round represents the users and the rectangle represents the onion routers. Assume that there are t−1 onion routers between the sender and the receiver along the routing path. We denote the i-th router in the path by OR i where 1 i t−1. Unlike existing onion routing protocols, we will distinguish users and routers in our AIB-OR.
The proposed AIB-OR protocol involves a trusted PKG whose responsibility is to initialize system parameters and to issue identity-based private keys and blind pseudonym certificates for all participants. The PKG runs the setup algorithm in AMRIBE scheme, sets the master key msk = s, and publishes the system parameters mpk = hq,G 1 ,G 2 , ê, P, P pub , H 0 , H 1 , H 2 , H 3 , Pi.

Circuit Construction
When the sender would like to send a message m 2 {0, 1} ℓ to the designated recipient with identity ID R anonymously and securely, he performs the following steps: 1. The sender generates his pseudonym PN S and gets his pseudonym certificate hPN S , σ S i by performing the PNGen algorithm and the BlindCert algorithm, respectively.
2. The sender runs the Key Agreement algorithm of our improved IBOWAKE protocol, gets the session key K S, R = ê(sk PN S , Q ID R ), and encrypts message m using a symmetric encryption algorithm (such as Advanced Encryption Standard, AES) with the session key K S, R to get the ciphertext C 0 . Note that the seesion key is used to encrypt data and is valid only for the duration of the communication.
3. The sender then constructs a circuit by selecting an ordered subset of onion routers from a generally known set of onion routers. We denote the identities of selected subset of onion routers by fID i g tÀ1 i¼1 , where ID t−1 is the identity of onion router closest to the designated receiver. 4. The sender encrypts the inner ciphertext C 0 for identities fID i g tÀ1 i¼1 [ ID R by applying the Encrypt algorithm of our improved AMRIBE scheme to get the outer ciphertext C 1 .
5. Finally, the sender transmits the onion packet ONI ≜ (seq, hPN S , σ S i, C 1 ) to the first onion router OR 1 along the path.

Decrypt by Onion Router
When an onion router OR i receives the onion packet, it processes the onion packet as follows.
1. The onion router OR i checks whether the packet has already been received or not by using the field seq as the unique identifier for the packet. If there is an entry with the same seq field in its local routing table, it simply discards the onion packet. Otherwise it inserts a new record (seq, OR i−1 , ttl) into the local routing table.
2. The onion router OR i decrypts the ciphertext C 1 of the onion packet with its private key d ID i by running the Decrypt algorithm of our improved AMRIBE scheme. If the decryption fails, the OR i just discards the packet without forwarding. Otherwise, the OR i forwards the onion packet to all the connecting onion routers and users except the previous onion router (whom it gets the packet from).

Decrypt by the Recipient
When a user receives the onion packet, he performs the same operations as the onion routers. Note that a user can not decrypt the ciphertext C 1 of the onion packet with his private key unless he is the designated recipient. If he is not the designated recipient, he simply discards the packet. Otherwise, he is the designated recipient, and he can further decrypt the inner ciphertext C 0 with the session key K S, R = ê(PN S , d ID R ) and get the plaintext m.

Security and Efficiency Analysis
In this section, we explain how the proposed AIB-OR protocol meets the sender anonymity, recipient anonymity, route anonymity and failure tolerance, and analyze why the proposed AIB-OR protocol can greatly reduce computational and communications costs. In the following, all analyzes and discussions are based on the onion routing example illustrated in Fig. 2.
• Sender Anonymity: The sender constructs circuit using its one-time pseudonym in our AIB-OR protocol, which ensures sender anonymity.
• Recipient Anonymity: In existing onion routing protocols, if an adversary compromised the onion router OR 10 , then he knows the address or identity of the recipient. In our AIB-OR protocol, the sender encrypts the inner ciphertext for multiple identities fID i g tÀ1 i¼1 [ ID R by applying AMRIBE scheme, which provides privacy protection for the recipient and the onion routers in the circuit.
• Route Anonymity: In the circuit construction given in PB-OR and CL-OR, the sender sends to each onion router a pseudonym and a message symmetrically encrypted with the session key K i . The session key K i is generated by a non-interactive anonymous key agreement protocol, and the message contains the identity of the next node in the circuit. Thus every onion router in the circuit knows the address or identity of both the previous onion router and the next onion router. In the circuit construction of our AIB-OR protocol, the sender encrypts the inner ciphertext for multiple identities fID i g tÀ1 i¼1 [ ID R by applying AMRIBE scheme, which ensures none of the onion routers knows who is the next onion router or user since every onion router sends message to all the connecting onion routers and users except the previous onion router.
• Failure Tolerance: Assume that sender sends a message to the receiver using the routing path Sender ! OR 1 ! OR 2 ! OR 5 ! OR 6 ! OR 10 ! Recipient. If there is something wrong with OR 6 , the message will be discarded after OR 5 in the existing onion routing protocols. In our AIB-OR protocol, the sender can add both the identity of OR 8 and OR 9 to the recipient collection. In this way, both OR 8 and OR 9 can decrypt the ciphertext with their own private key, respectively. If OR 6 failed, the message can still be transferred to the receiver following the path Sender ! OR 1 ! OR 2 ! OR 5 ! OR 8 ! OR 9 ! OR 10 ! Recipient. This will bring extra overhead in circuit construction since the sender needs to construct higher order polynomial. Here we assume the sender has sufficient knowledge of routing paths leading to the recipient and the sender make a tradeoff between efficiency and failure tolerance to decide the actual routing path.
• Message Consistency: We assume the adversaries have complete control over some part of the network, but not all parts of the network, since this cannot be possible for large network with thousands of network links. It may look like the message is not changing at every hop in the path so this may give path information to an attacker. However, attackers do not know the next hop in the path in our AIB-OR. So there is nearly no possibility for adversaries to get the whole path information by utilizing techniques such as traffic analysis, unless they are watching the entire network. In addition, our AIB-OR, unlike PB-OR and CL-OR, provides message integrity detection by verifying the value of λ.
• Forward Secrecy: To achieve forward secrecy in PB-OR and CL-OR, onion routers' keys are required to be changed frequently, this implies a significant computational effort for the PKG. In contrast our AIB-OR, none of the onion routers can decrypt the inner ciphertext and know who is the next onion router or user. To achieve forward secrecy in our proposed AIB-OR, only the sender's pseudonym or the recipient's key is required to be changed.
• Communication Cost: At first glance, our AIB-OR protocol will bring higher network overhead since each onion router forwards the onion packet to all the connecting onion routers and users except the previous onion router. In fact, out of all only onion routers in the circuit can decrypt and the remaining will discard the onion packet. In Fig. 2, when OR 5 receives an onion packet from OR 2 , it will send the onion packet to the onion routers OR 4 , OR 6 , OR 7 , OR 8 and a user, respectively. However, only OR 6 can decrypt the onion packet and others will discard it since they can not decrypt the onion packet. In addition, the size of the onion packet is shorter than those of PB-OR and CL-OR.
• Storage Cost: Both onion routers and users are given an identity-based private key from the trusted PKG, which can be used to decrypt the ciphertext encrypted by AMRIBE scheme as well as symmetric encryption algorithm with the session key K S, R , thus the overhead of key management is greatly reduced. In addition, for an onion router or a user who receives the same packet for the second time, they can check the field seq in the packet against entries in the local routing table. If there is a matching record in the routing table, the onion router or user will discard the packet. A time to live field (ttl) is set in the local routing table, so that the entry can be removed from the local routing table when the ttl reaches zero.
• Computation Cost: In the PB-OR and CL-OR, a sender is required to perform symmetric encryption operation t times if there are t onion routers in the path. In our AIB-OR, a sender is only required to perform symmetric encryption operation 2 times irrespective of number of onion routers in the path. Our AIB-OR, like PB-OR and CL-OR, each intermediate onion router is required to perform one bilinear pairing and one symmetric decryption operations. Note that, message is actually transmitted from the last onion router to the designated recipient in the clear text both in the PB-OR and CL-OR. Thus, the recipient does not need to perform any operations in PB-OR and CL-OR. Obviously, this would lead to the disclosure of messages and exposure of recipient identity. Our AIB-OR, unlike existing onion routing protocols, the user and the onion router is different, and the recipient is required to perform two bilinear pairing and two symmetric decryption operations.
We compare the security properties, computational and communications costs on circuit construction in PB-OR, CL-OR and our AIB-OR. The comparison is summarized in Table 2. We denote by t, jmj, jIDj, jG 1 j and jZ Ã q j the number of onion routers in the circuit, the bitlength of a plaintext, an identity, an element in group G 1 , and an element in group Z Ã q , respectively. We denote by e 1 , e 2 , p, E, D the computation cost of an exponentiation in G 1 , an exponentiation in G 2 , a bilinear pairing in (G 1 ,G 2 ), a encryption operation and a decryption operation in P, respectively. Other operations are omitted in the following analysis since their computation cost is trivial.

Performance Test
We conducted several experiments to compare AIB-OR with PB-OR in terms of computation cost and bandwidth overhead. The experiments were run on a machine with 2GB of RAM, and hosted on 2.00GHz. We implement our algorithms based on Charm-Crypto Framework (version 0.42) [27] and Pairing-Based Crypto (PBC) library [28].
In our experiment, we use symmetric bilinear groups over supersingular elliptic curves of type A [28], where an element in G 1 can be represented by 512 bits. We choose AES-256 as the symmetric encryption algorithm, and the number of onion routers is chosen to be from 5 to 20, and the packet size is chosen to be 512 bytes. The time cost of circuit construction is measured on encryption time run by the source node, decryption time run by all the intermediate nodes in the circuit and decryption time run by the destination node. Fig. 3 shows the comparison of computation time required by the sender in PB-OR [10] and our AIB-OR. As shown in the figure, the computation time required by the sender in our AIB-OR is shorter than in PB-OR for the same number of onion routers. Moreover, the growth rate of computation time required by the sender in our AIB-OR is slower than in PB-OR.
For PB-OR, the size of onion packets becomes larger with the increase in the number of onion routers. For the intermediate routers, the closer to the destination node, the higher bandwidth overhead will be. There is no such problem in our AIB-OR. Fig. 4 shows the comparison of onion packet size in PB-OR [10] and in our AIB-OR. As shown in the figure, the size of onion packet in our AIB-OR is shorter than in PB-OR. Moreover, the growth rate of onion packet size in our AIB-OR is slower than in PB-OR.

Conclusion
In this paper, we propose a new approach for circuit construction in onion routing anonymity networks by using our improved anonymous multi-receiver identity-based encryption scheme and our improved anonymous identity-based one-way key agreement protocol. Compared to existing approach for circuit construction in onion routing anonymity networks, our approach provides high efficiency, scalability, strong anonymity and fault tolerance. Performance experiment shows that our proposed approach uses significantly less computation and communication than that of paring-based onion routing.