Editing Identity-based encryption (section)

== Drawbacks ==
* If a Private Key Generator (PKG) is compromised, all messages protected over the entire lifetime of the public–private key pair used by that server are also compromised.  This makes the PKG a high-value target to adversaries.  To limit the exposure due to a compromised server, the master private-public key pair could be updated with a new independent key pair. However, this introduces a key-management problem where all users must have the most recent public key for the server.
* Because the Private Key Generator (PKG) generates private keys for users, it may decrypt and/or sign any message without authorization.  This implies that IBS systems cannot be used for [[non-repudiation]].  This may not be an issue for organizations that host their own PKG and are willing to trust their system administrators and do not require non-repudiation.
* The issue of implicit key escrow does not exist with the current [[Public key infrastructure|PKI]] system, wherein private keys are usually generated on the user's computer.  Depending on the context key escrow can be seen as a positive feature (e.g., within Enterprises).  A number of variant systems have been proposed which remove the escrow including [[certificate-based encryption]], [[secret sharing]], [[secure key issuing cryptography]] and [[certificateless cryptography]].
* A secure channel between a user and the Private Key Generator (PKG) is required for transmitting the private key on joining the system. Here, a [[Secure Sockets Layer|SSL]]-like connection is a common solution for a large-scale system.  It is important to observe that users that hold accounts with the PKG must be able to authenticate themselves. In principle, this may be achieved through username, password or through public key pairs managed on smart cards.
* IBE solutions may rely on cryptographic techniques that are insecure against code breaking [[quantum computer]] attacks (see [[Shor's algorithm]]).