Identity-Based Encryption

1 minute read

Catching up with the rest of the world after Sun’s summer holiday, I see a posting from James McGovern mentioning ‘Identity-Based Encryption’. I can totally see the utility of IBE in the context of, say, corporate email: there is a mechanism for Alice to easily tranforming an arbitrary string (say, Bob’s email address) to a public key and use the latter to encrypt a message for Bob. At this point, Bob needn’t have a private key at all. On receiving the message, Bob can go to the Private Key Generator (PKG), the equivalent of a certificate authority, I guess, prove that he ‘owns’ the email address in question and obtain a private key. (I haven’t read up on this in the necessary detail to discover whether there is an implicit key escrow here - presumably the key issuer could generate Bob’s private key for itself, if it really wanted to?).

Thinking aloud on the application to identity in the sense of SSO, federation and such… As far as I can see, the ‘Identity’ in IBE’s name could just as well be ‘arbitrary string’, but in an email context, the use of an email address (one possible identifier) has obvious benefits. For authentication, though, I’m not so sure. I can’t see strong non-repudiation here, since the PKG can always mint a private key for any given public key.

Still, there might be applications for encrypting attributes in a loosely-coupled authentication domain. At the request of the principal, an identity provider could encrypt attributes to be sent to a given relying party without a prior relationship with that relying party, using, say, a URL as public key. If that URL located an appropriate web service, the relying party could automatically request a private key from the PKG, which would send the private key to that web service, using message and/or transport encryption for privacy. Interesting…




IBE is equally useful for replacing ssl client certificates. Most folks are limiting the IBE discussion to just email at thier own loss. Would love to know if Sun could provide leadership in this space…


Yes - I can see the utility in SSL too... I'll pass this on to some of our security folks, see what they say.

It's certainly an attractive approach. Of course, it would take some time for this to percolate through the industry, the standardization process and become interoperable, but we've had some experience of that already with elliptic curve.

I am director in India NCR (delhi) ABES and chanced to see this. Sun should go to my play-limited IBE instead. It already is software and will eliminate piracy! you got Diffie so he should see.

richard long

In 2002, an inventor, Patrick Zuili is the first one to have beeb able to integrate the biometric identity into IBE Identity-Based Encryption.
This an extremely interesting advantage and very valuable aspect of this patent.

United States Patent 7,083,090
Zuili August 1, 2006
19. The method of claim 18, wherein the biometric input is a fingerprint.

20. The method of claim 1, wherein information exchange subsequent to the transaction request are encrypted.

21. The method of claim 20, wherein the encryption is based on public-key cryptography.

22. The method of claim 20, wherein the encryption is based on identity-based encryption (IBE) cryptography.


With ibc their is a identity which could be anything from a email to a fingerprint and a shared secret (secure random number). The main advantage of IBC of PKI is that you don't need a internet connection to check or generate the certificate. And you don't need a CA so you don't have a scalability problem anymore. You can generate them yourself. But shared secrets aren't safe!?! With IBC they are because this number is only used to generate the certificate so nobody else who don't know this number can generate the same private key. So the secret is never send across the internet. The only hard part of IBC is that for every connection a certificate is generated so it is very intensive to use IBC on large scale services.

Leave a Comment

Your email address will not be published. Required fields are marked *