Questions: Identity-Based Encryption

Question 1

IBE eliminates the need for certificates. Why is this a significant advantage over traditional PKI, and what is the corresponding disadvantage?

Model answer: In PKI, a sender must obtain and verify the recipient's certificate before encrypting — this requires certificate distribution infrastructure, revocation checking, and trust chain validation. IBE eliminates this: the sender encrypts directly to '[email protected]' using only the system's public parameters. The disadvantage is key escrow: the KGC generates all private keys and therefore can decrypt any message. There is no way for a user to have a private key that the KGC doesn't know, which is unacceptable for many applications.

IBE trades the decentralized trust model of PKI (trust many CAs, no single point of decryption) for a centralized one (trust one KGC, which can decrypt everything). This tradeoff is acceptable in enterprise settings (the organization already controls all data) but problematic for general internet encryption where users expect end-to-end privacy.

Question 2

Bilinear pairings are the mathematical tool enabling Boneh-Franklin IBE. What property does a pairing e: G1 x G2 → GT provide?

• A. e(aP, bQ) = e(P, Q)^{ab} — the pairing is bilinear, meaning it 'transfers' scalar multiplication from the input groups to exponentiation in the target group. This creates algebraic relationships between group elements that don't exist without pairings
• B. The pairing encrypts elements from G1 using elements from G2
• C. The pairing provides a collision-resistant hash from G1 x G2 to GT
• D. The pairing compresses two group elements into one smaller element

Answer: (A)

Bilinearity is the key: e(aP, bQ) = e(P, Q)^{ab}. This lets the Boneh-Franklin scheme work: the KGC computes a private key d_ID = s*H(ID) (master secret s times the hash of the identity), and encryption/decryption use the pairing to connect the identity-derived public key with the secret key, without anyone else being able to compute s. Pairings enabled a revolution in cryptography, yielding IBE, short signatures, and efficient non-interactive zero-knowledge proofs.

Question 3

In IBE, a user can receive encrypted messages before they have even obtained their private key from the KGC.

• T. True
• F. False

Answer: True

This is one of IBE's most useful properties. Anyone can encrypt to '[email protected]' using only Alice's identity and the system's public parameters — Alice doesn't need to have registered or obtained her key yet. When Alice eventually authenticates to the KGC and receives her private key, she can decrypt all messages that were encrypted to her identity. This enables 'encrypt-to-the-future' scenarios and simplifies deployment because the sender never needs to coordinate with the recipient.

Question 4

IBE provides a natural solution to certificate revocation. How can time-based IBE key management replace CRLs and OCSP?

• A. IBE keys never expire, eliminating the need for revocation
• B. Encrypt to identity strings that include a time period, e.g., '[email protected] || 2026-Q1'. The KGC issues private keys for the current period only. A revoked user simply doesn't receive keys for future periods. No revocation lists or online checking needed — expired identities automatically become undecryptable
• C. The KGC broadcasts revocation messages that invalidate specific identities
• D. IBE uses the same CRL mechanism as PKI

Answer: (B)

This elegant approach was proposed by Boneh and Franklin. By embedding time into the identity string, revocation becomes key non-issuance: the KGC stops generating keys for revoked users in future periods. The sender's encryption automatically includes a time component, ensuring messages are only decryptable by users who are active during the relevant period. The main cost is that users must periodically obtain fresh keys from the KGC, but this is a feature — it enforces ongoing authentication.

Question 5

Hierarchical IBE (HIBE) allows organizations to delegate key generation to sub-authorities. A university KGC generates keys for department KGCs, which generate keys for individual professors. Why is this valuable?

Model answer: HIBE distributes the KGC's load and trust. The university root KGC issues a department-level secret key to 'cs.university.edu'. The CS department uses this key to derive individual keys like '[email protected]' without contacting the root KGC. This mirrors organizational hierarchies, scales better than a single KGC, and limits damage from compromise (a compromised department KGC can only forge keys within its sub-tree). The tradeoff is that ciphertext size and decryption cost grow with hierarchy depth.

HIBE extends IBE's identity-as-public-key paradigm to hierarchical namespaces, naturally matching organizations like companies (CEO → VP → Manager → Employee) or DNS (com → example → mail). Each level can independently manage its sub-tree, providing both scalability and compartmentalized trust.