PGP CTO Blog

Traditional public key cryptographic schemes use numbers that are hundreds of digits long--not something a human being can remember easily. Even elliptic curve cryptographic keys are several tens of digits long. Cryptographic systems put these keys into a data structure called a certificate that includes a text string humans can use to identify the certificate. In identity-based encryption, the actual key is a function of a text string itself.

Identity-based encryption has two interesting properties:

1. You can give someone a key based on a string such an email address. Because any string specifies a key, even strings such as "President and CEO" are thus a public key.
2. You can encrypt data to someone who does not yet have a key--or more precisely, someone who doesn't yet know what his/her key is because any string is a key. Thus, you could encrypt a message to "alice@doman.tld" and email it to Alice. Alice then merely has to get the private key associated with her email address to decrypt the message.

However, like most things in life, this simple concept has some complications and limitations:

There are details hidden in merely getting a private key associated with a string. Obviously, the private key can't be computed by just anyone, or it wouldn't be a very good encryption scheme. The key pair is created not just with the string, but with some secret that is kept on a server. When Alice gets her private key, she gets it from a server. She must also prove to the server that she's the person who deserves that key. In other words, she must authenticate herself to that server.

If Alice has no prior relationship with that server, this task is difficult. There are any number of ways Alice could authenticate herself; for example, she could use a certificate that the server trusts. However, if she has a certificate the server trusts, the server probably could have encrypted the message to a public key associated with her in the first place. (X.509 certificates were originally invented as a way to strongly authenticate a user to a directory so the user could update his/her personal information.) The server could mail Alice a message that contains a password, but that's relatively weak--and the server could always have encrypted the message to a symmetric key derived from that password.

Although it's clever to be able to encrypt opportunistically, figuring out a way for the recipient to securely retrieve his/her private key is a hard problem. Moreover, the solutions to this problem do away with the advantages of an identity-based scheme.

Because all strings are keys, all typos are keys, too. This is the dark, frustrating side of identity-based encryption. Suppose the person who encrypted the message to Alice accidentally encrypted it to "Alicia." Alice will not be able to decrypt her message and won't know why. Even worse: Suppose Alice knows the message was encrypted to "Alicia." How is she going to prove to the server that she's entitled to the "Alicia" key when she is not Alicia, she's Alice? This is an even harder problem if Alice is actually "Alys."
Those of you with relatively common, easily spelled names may think I'm picking nits here. However, I have a relatively unusual name, "Jon." I can't tell you how many times it becomes "John." I find it most amusing when someone gets my email address right, jon@pgp.com, but then starts the message with a salutation of "John." Even if I use my full name, "Jonathan," that often gets mangled as "Johnathan,""Jonathon," and so on.
These are important human factors issues. Cryptographic systems are subject to many subtle attacks based on semantics and human factors. Identity-based systems have vulnerabilities in ways traditional systems do not because all possible strings are keys. They aren't insurmountable problems, but they require additional infrastructure.

Although identity-based systems eliminate part of the certificate problem, they don't completely get rid of it. It is true that the most important part of a certificate is the name, but certificates are not merely names. They also contain other attributes, such as validity dates, declarations of what a certificate can and cannot be used for, and so on. An identity-based scheme either has to have a certificate to hold these attributes, or it must put them in the string that codes the key. If you have a certificate anyway, then why bother with an identity-based cryptographic system? If you code it into the name, then you lose the whole reason for having it: that it can be easily remembered. If my certificate is the string, "<jon@pgp.com> good from 1/1/03 to 12/31/04, valid for document signatures only, not for purchase orders," and any typo of that string is an equally valid certificate, then perhaps I'd be better off with the old fashioned type.

Because the system requires a server to hold secrets used to create the keys, it is thus an escrowed system. Traditional PKIs can be escrowed or unescrowed--it's an option, not a requirement. Identity-based systems are only escrowed systems.

The trusted server is a vulnerability. If it is compromised or the secrets that generate the keys are lost, all the keys are lost because anyone can then compute all possible identity-based keys.

It makes key revocation a significant problem. Revocation is a problem in any public key system, and a particularly difficult problem in identity-based encryption. What happens if someone loses his/her laptop? Does that mean he/she needs to get a new email address as well as a new public key? And what happens to role-based keys when the person in the role changes? In either case, a traditional PKI lets users just create a new key. That solution is not an option in an identity-based encryption system. One way to handle this problem would be to have different sets of secrets in the server: one for those people who have never lost their keys, one for people who have lost them once, and so on. Creating this type of solution merely requires some degree of database expertise.

It multiplies the number of keys users have to juggle. Today, it's common for people to have more than one email address: for example, I am jon@pgp.com, jcallas@pgp.com, and jon.callas@pgp.com. In a role-based authentication system, I would probably also end up with keys for "CTO," "CSO," "Chief Technical Officer," "CTO/CSO," and so on. With a public key system like the one used in PGP® solutions, it's easy to have one key that responds to all those names. With an identity-based encryption system, users will have as many keys as they have email addresses and roles-each needing correct spellings and suitable proofs of ownership.

It is not based on widely accepted standards. This is a new public key system that does not interoperate with PGP solutions, with X.509, or with anything else. And because it's patented, there won't be standards for it anytime soon. Anyone who buys this system can use it only with other people who have also bought it. Note that elliptic curve systems also have advantages over traditional public key systems, having smaller keys and faster execution. But they are also incompatible with existing standard systems and encumbered by patents. These practical considerations nullify any advantages that they have, and they have not spread. These same issues are likely to put friction on identity-based encryption adoption.

It requires all the same software as other systems. Everything users need for a traditional PKI--including email plugins, authentication, servers, and so on-is also needed for an identity-based encryption system. Ironically, this list even includes a directory server because there has to be some way to know what types of key requests are valid. Although the system does not require a Certificate Authority (CA) per se, users still need something akin to a CA: the "authoritative server" from which they get their keys.

Summary
Identity-based encryption has interesting mathematical properties, such as being able to create a public/private key pair from a string. Although this system has some advantages over a traditional PKI, it also has a number of disadvantages as well.

Identity-based encryption's advantages make sense for offline systems. However, in a world with pervasive networking, the advantages of identity-based encryption can be built into an existing PKI with intelligent servers to manage the keys for the users. This is what we at PGP Corporation have done with PGP Universal™. PGP Universal Server gives users all the advantages of identity-based encryption while maintaining compatibility with existing PKIs and cryptographic systems.

Identity-based encryption is an interesting new technology, and had it been invented in 1984, or even 1994, it might be the dominant form of public key cryptography today. Instead, the spread of pervasive networking means that the mathematical advantages of identity-based encryption are delivered with good old fashioned software engineering and systems design. However innovative it is, identity-based encryption is simply not needed in the twenty-first century.

Background reading

Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing" [PDF], 2001

Boyen, Xavier, "Multipurpose Identity-Based Signcryption: A Swiss Army Knife for Identity-Based Cryptography" [PDF], International Association for Cryptologic Research, 2003

Chromatic, "Terence Spies on Identity-Based Encryption," July 17, 2003

IBE Secure E-Mail

PGP News Feed