An Efficient Public Key Trace and Revoke Scheme Secure against Adaptive Chosen Ciphertext Attack

Abstract

Abstract. We propose a new public key trace and revoke scheme secure against adaptive chosen ciphertext attack. Our scheme is more efficient than the DF scheme suggested by Y. Dodis and N. Fazio [9]. Our scheme reduces the length of enabling block of the DF scheme by (about) half. Additionally, the computational overhead of the user is lower than that of the DF scheme; instead, the computational overhead of the server is increased. The total computational overhead of the user and the server is the same as that of the DF scheme, and therefore, our scheme is more practical, since the computing power of the user is weaker than that of the server in many applications. In addition, our scheme is secure against adaptive chosen ciphertext attack under only the decision Diffie-Hellman (DDH) assumption and the collision-resistant hash function H assumption, whereas the DF scheme also needs the one-time MAC (message authentication code) assumption.

How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack

“…Since it is often distributing information of its own choice, it is assumed to have control over the group membership, i.e., the center is allowed to make decisions about who can join the group and whose membership should be revoked. This is in line with almost all multicast schemes such as [25,4,26,27,22,23,24].…”

“…This gives her a chance to "protect" these shares and, as a result, the resulting multicast encryption can be made more secure than T D. This can be seen as an extension of Construction 1: This construction can be used to build a multicast scheme with higher security than the underlying threshold scheme. This is essentially what was done in [23] and [24]. The protection mechanism (i.e.…”

“…The price for this flexibility is the loss of the public key feature, which should not be a problem for many applications. However we observe that in many instantiations of our constructions, it is easy to "publicize" the encryption key, without affecting the security of the scheme, as demonstrated by works such as [22,23,24]. This effectively turns the scheme into a public key system and all the openness features are reinstalled.…”

“…This is different from the public key systems such as [17,22,23,24] where the information to encrypt a message is public. The openness is unnecessary for some applications and unacceptable for some others (e.g.…”

“…[35,32,33,34] and the IND-CCA2 threshold ElGamal in [36]) and a multicast encryption constructed via Construction 1 using one of these schemes is therefore guaranteed to be CCA2 secure too. In addition, all existing ATD-based multicast encryption schemes [17,14,22,23,24] are based on discrete logarithm. Theorem 1 provides security guarantee for constructing multicast encryption using any other assumptions.…”