Summary A vast body of literature is filled with many key management schemes constructed using different cryptographic primitives. They aim toward either security goals or improvement in performance efficiency. However, the key management schemes based on proxy re‐encryption suffer from massive communication and computational costs. We propose an ElGamal proxy re‐encryption‐based construction for the key management scheme to resolve this. The proposed scheme involves constant computational and communication costs in rekeying operations and linear public bulletin size. We achieve essential security requirements of forward and backward secrecy in this scheme. The scheme is also secure against the collusion attack. In addition, we address the importance of adequately managing missed rekeying updates for offline users. The existing schemes trivially keep track of each rekeying message on the public bulletin board, which increases the size of the public bulletin with every join/leave operation. However, the proposed scheme uses the public bulletin board so that the handling of offline users is built into the scheme itself, which manages it efficiently. Also, the public bulletin size in the proposed scheme is not dependent on the number of rekeying operations but linear in the number of users.

In the literature, secure group key management schemes have focused on either rekeying cost or security requirements, i.e., forward and backward secrecy. There is little or no work that adds new features to the secure group key management scheme. In the existing key management schemes, any user can join or leave the group any number of times during the group's lifetime. There is a need to restrict the number of times a user joins the group during the group's lifetime. We propose a user-driven general framework wherein a cap is enforced on the number of times a user can join the group. Any existing key management scheme can use this framework. In the proposed scheme, the user is prevented from joining a group, say, more than t > 0 times. We analyse the scheme and show that the proposed scheme indeed caps the number of times a user can join the group.