Identity-based encryption
Identity-based encryption (IBE) is a form of public-key encryption in which a user's public key is an arbitrary string derived from their identity, such as an email address or name, thereby eliminating the need for public key infrastructure and digital certificates.[1] Introduced by Adi Shamir in 1984 within the broader framework of identity-based cryptosystems, IBE aims to simplify key management by allowing encryption directly using the recipient's identity information.[2] The concept relies on a trusted authority known as the Private Key Generator (PKG), which computes and distributes private keys corresponding to user identities while maintaining a master secret key.[1] The first practical and fully functional IBE scheme, achieving chosen-ciphertext security in the random oracle model, was proposed by Dan Boneh and Matthew Franklin in 2001, building on bilinear pairings from elliptic curve cryptography and assuming the hardness of a variant of the computational Diffie-Hellman problem.[3] An IBE scheme operates through four core algorithms: Setup, which initializes public parameters and the PKG's master key; KeyGen (or Extract), which generates a private key from a user's identity string; Encrypt, which produces a ciphertext using the recipient's identity and system parameters; and Decrypt, which recovers the plaintext using the corresponding private key.[1] This structure enables efficient encryption without prior key exchange, though it introduces challenges like key escrow, where the PKG can potentially decrypt any message, often addressed via threshold schemes distributing trust among multiple parties.[3] IBE has significant applications in automated key distribution for email systems, secure group communications, and cloud services, reducing administrative overhead compared to traditional public-key systems.[1] It has spurred advancements in related primitives, including hierarchical IBE for delegated key generation and attribute-based encryption for fine-grained access control.[1] Ongoing research emphasizes post-quantum variants resistant to quantum attacks, with schemes based on lattice problems and other hardness assumptions emerging to ensure long-term security.[4]Introduction
Definition and Core Concepts
Identity-based encryption (IBE) is a variant of public-key encryption in which the public key for a user is an arbitrary string derived from the user's identity, such as an email address, name, or IP address, rather than a randomly generated value.[3] This approach eliminates the need for users to generate and distribute their own public keys, simplifying key management in cryptographic systems. The concept was first proposed by Adi Shamir in 1984 as a way to facilitate secure communication without traditional certificate infrastructures.[2] Central to IBE is the Private Key Generator (PKG), a trusted authority responsible for initializing the system and issuing private keys to users. The PKG performs a setup procedure to generate global public parameters and a master secret key, which remains private to it. Upon a user's request, authenticated via their identity, the PKG uses the master key to extract and provide a corresponding private decryption key.[3] In the basic workflow, a sender encrypts a message solely using the recipient's identity string and the public parameters, producing a ciphertext. The recipient then obtains their private key from the PKG and uses it to decrypt the message, ensuring secure delivery without prior key exchange.[3] Unlike standard public-key encryption (PKE), where users independently generate key pairs and public keys are certified through a public key infrastructure (PKI), IBE derives public keys directly from identities, centralizing key generation at the PKG and introducing inherent key escrow.[3] The core algorithms of an IBE scheme operate abstractly as follows: Setup produces the public parameters and master key; Extract generates a private key from an identity using the master key; Encrypt creates a ciphertext from a message and identity; and Decrypt recovers the message from a ciphertext using the private key, maintaining consistency such that decryption inverts encryption correctly.[3] This structure supports intuitive encryption based on human-readable identifiers while relying on the PKG's trustworthiness for security.[2]Historical Development
The concept of identity-based encryption (IBE) was first proposed by Adi Shamir in 1984 during his presentation at the CRYPTO conference, where he introduced the idea of using a user's identity as its public key to simplify key management in public-key cryptography, though he provided a full construction only for identity-based signatures and left encryption as an open problem.[5] This open challenge remained unresolved for over a decade until 2001, when two independent constructions realized fully functional IBE schemes: the Boneh-Franklin scheme, which relied on bilinear pairings over elliptic curves for efficiency, and the Cocks scheme, which used quadratic residues modulo a composite number for a pairing-free alternative.[3][6] In 2002, Horwitz and Lynn extended the Boneh-Franklin framework to propose hierarchical IBE (HIBE), allowing key delegation across multiple levels of a hierarchy to support scalable access control without requiring a fully trusted central authority.[7] The mid-2000s saw further innovations building on these foundations, including the introduction of fuzzy IBE by Sahai and Waters in 2005, which tolerated partial matches in identities to enable applications like biometric encryption, and its generalization to attribute-based encryption (ABE) that allowed fine-grained access policies based on attributes rather than single identities.[8] Entering the 2010s, research shifted toward post-quantum security amid growing concerns over quantum computing threats, with lattice-based IBE emerging around 2008 through Gentry, Peikert, and Vaikuntanathan's work on trapdoor functions that enabled the first such schemes in the random oracle model, followed by Agrawal, Boneh, and Boyen's 2010 construction achieving security in the standard model.[9] This momentum accelerated after 2015, driven by the National Institute of Standards and Technology's (NIST) initiation of post-quantum cryptography standardization efforts in 2016, which prioritized lattice-based primitives like learning with errors (LWE) for their quantum resistance. In the 2020s, developments have focused on enhancing practicality for real-world deployment, including efficient revocable lattice-based IBE schemes; for instance, a 2024 LWE-based online/offline IBE construction reduced online computation overhead by up to 80% through precomputation.[10] Additionally, IBE has been integrated with blockchain technologies for privacy-preserving applications, such as secure identity management in decentralized systems to prevent identity theft while maintaining data integrity.[11]| Year | Milestone | Key Contributors | Reference |
|---|---|---|---|
| 1984 | Proposal of IBE concept (signatures only) | Adi Shamir | CRYPTO 1984 |
| 2001 | First full IBE using bilinear pairings | Boneh, Franklin | CRYPTO 2001 |
| 2001 | First full IBE using quadratic residues | Clifford Cocks | IMA 2001 |
| 2002 | Introduction of hierarchical IBE (HIBE) | Horwitz, Lynn | Eurocrypt 2002 |
| 2005 | Fuzzy IBE and path to ABE | Sahai, Waters | Eurocrypt 2005 |
| 2008 | First lattice-based IBE (random oracle model) | Gentry, Peikert, Vaikuntanathan | STOC 2008 |
| 2010 | Lattice-based IBE in standard model | Agrawal, Boneh, Boyen | Eurocrypt 2010 |
| 2016 | NIST post-quantum standardization begins, boosting lattice IBE | NIST | NIST PQC |
| 2024 | Efficient LWE-based online/offline IBE | Zuo et al. | Information 2024 |
Applications and Comparisons
Practical Usage
Identity-based encryption (IBE) has found practical application in email systems, where it enables encryption directly to a recipient's identity, such as an email address like [email protected], eliminating the need for certificate distribution and management. This approach simplifies secure communication by allowing senders to use the recipient's email as the public key, with private keys generated by a trusted authority. Voltage Security, now part of OpenText, pioneered commercial IBE products in the early 2000s, including Voltage SecureMail, which powered email encryption for enterprises and was validated under NIST's Cryptographic Algorithm Validation Program for integration into applications.[12][13] In Internet of Things (IoT) environments, IBE facilitates secure messaging by leveraging device identities, such as unique IDs or MAC addresses, as public keys for end-to-end encryption between constrained devices. This reduces overhead in resource-limited settings, enabling lightweight authentication and data protection without traditional public key infrastructure (PKI) complexities. For instance, IBE schemes have been implemented to secure communications among IoT objects, supporting scalable deployment in networks with thousands of devices.[14][15] For cloud storage access control, IBE supports time-bound identities by incorporating expiration parameters into user identities, allowing encrypted data to be accessible only within specified periods without re-encryption. This is particularly useful for temporary sharing, where revocation mechanisms ensure keys expire automatically, enhancing data security in shared environments. Revocable IBE variants enable fine-grained control, such as outsourcing revocation computations to cloud servers to minimize the private key generator's (PKG) workload.[16][17][18] In e-health and blockchain applications, IBE enables secure patient data sharing by encrypting records to healthcare provider identities, bypassing PKI for decentralized systems. Recent revocable IBE schemes, developed around 2025, integrate with blockchain for electronic health records in Internet of Medicine Things (IoMT), allowing patient-controlled access and efficient revocation without central certificate authorities. These pilots, inspired by NIST's post-quantum cryptography efforts, explore lattice-based IBE for quantum-resistant data sharing in smart healthcare. Additionally, as of July 2025, the Internet Computer blockchain platform integrated IBE via its vetKeys feature, allowing encryption to identities like principals or email addresses for secure decentralized applications.[19][20][21][22][23] Practical key management in IBE relies on secure channels for delivering private keys from the PKG to users, often via out-of-band methods like secure email or hardware tokens to prevent interception. Outsourcing PKG operations, such as revocation and key generation, to cloud providers reduces computational burden on the central authority while maintaining security through verifiable computations, as demonstrated in cloud-integrated IBE deployments. Compared to traditional PKI, this simplifies deployment by avoiding certificate lifecycle management.[24][25][26]Comparison with Traditional PKI
Traditional public-key infrastructure (PKI) relies on a hierarchical system where users generate asymmetric key pairs, and certificate authorities (CAs) issue digital certificates to bind public keys to verified identities, ensuring authenticity and enabling trust.[27] This setup necessitates ongoing management of certificates, including issuance, distribution via directories, and validation through protocols like the Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to handle compromised keys.[28] Key distribution occurs through certificate repositories, while revocation involves publishing lists or querying CAs in real-time, which can impose significant computational and network overhead as the number of users grows.[29] In contrast, identity-based encryption (IBE) eliminates the need for certificates by deriving public keys directly from user identities, such as email addresses, allowing encryption without prior key exchange or directory lookups.[27] A private key generator (PKG), analogous to a CA but centralized, authenticates users and extracts corresponding private keys upon request, shifting key management from decentralized user responsibility to a trusted authority.[30] This introduces key escrow, where the PKG holds the master secret and can potentially decrypt any ciphertext, unlike traditional PKI's separation of duties.[29] Scalability in IBE improves enrollment by removing certificate issuance and verification steps, reducing administrative overhead for large systems; however, it centralizes trust in the PKG, creating a single point of failure or compromise risk not present in PKI's distributed hierarchy.[27] For revocation, PKI employs CRLs—periodically updated lists of invalid certificates—or OCSP queries for on-demand status checks, both scaling linearly with user base and requiring sender-side verification.[31] IBE revocation mechanisms differ, often incorporating time-based identities (e.g., appending expiration dates) for natural key expiry or hierarchical IBE (HIBE) for delegated revocation without full reissuance; advanced schemes use broadcast encryption or binary tree structures to update keys logarithmically for non-revoked users.[32] Hybrid approaches integrate IBE with traditional PKI to mitigate weaknesses, such as using PKI for high-level trust anchors and IBE for user-level encryption to ease certificate management during transitions, or certificate-based encryption schemes that combine explicit authentication with identity-derived keys.[29] These hybrids preserve PKI's non-repudiation while leveraging IBE's simplicity, though they introduce compatibility challenges in key binding and revocation synchronization.[29]| Aspect | Traditional PKI | Identity-Based Encryption (IBE) |
|---|---|---|
| Key Generation | Users generate pairs; CA issues certificates after verification. | PKG generates private keys from identities after authentication; no user generation needed. |
| Key Distribution | Certificates published in directories; recipients validate via chains/CRLs. | Private keys delivered securely to users; public keys are identities (no distribution). |
| Revocation | CRLs (periodic lists) or OCSP (real-time queries); sender checks status. | Time-based identities, HIBE delegation, or tree-based updates; PKG manages without sender checks. |