Identity-Based Encryption and Open Source

Question

I recently ran across the notion of Identity Based Encryption (IBE) which seems like a novel idea. However, I haven't noticed many in the cryptography community attempting to find ways to break it. Am I wrong?

Likewise, I am of the belief that unless you can actually distribute open source implementations where the blackhat crowd can attack it, that it may not have merit?

I guess I would like to understand the experiences of the community-at-large in using this approach and how easy it is to incorporate into your application and distribute?

(Edit: here's a Wikipedia article on ID based encryption.)

Answer 1

Is there a particular scheme you have in mind? "Identity-Based Encryption" is quite a broad term.

But in any case, possibly you haven't seen so much attention because it's not cryptographically that special per se. General principles of cryptography will still apply, such as how many bits of entropy are there in the encryption key? what are the risks of collision attacks and other attacks based on having large volumes of plaintext/ciphertext if the same key is going to be used for an essentially indefinite period of time..?

Answer 2

I'm not clear what you're trying to ask, so I'm going to make up a couple things, and answer them. Let me know if I'm getting warm

First, "identity based encryption" isn't really an encryption scheme so much as a key management scheme. In any public/private — or, technically, "asymmetric" — encryption, there are two keys. One of them is used to encrypt, one to decrypt, and they have the special property that if you know one of them, it's still exponentially hard (or thought to be exponentially hard) to construct the other one. So, I can for example encrypt a letter to you using my private key; I publish my public key. If you can decrypt the letter using the public key, you have assurance that I was the one who really sent it. This is the core idea of digital signing schemes.

The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.

ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.

Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.

In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.

• Alice sends a request to Tom with her email address "[email protected]", and gets back a private key P. There is a corresponding public key p, but Tom doesn't send that to anyone.
• Bob sends a request to Tom and gets Tom's master public key m.
• Alice encrypts her message "x" with her private key, giving {"x"}P. (That notation is just "message "x" "wrapped" or encryption with key P.) Alice then sends that message to Bob.
• Bon uses his knowledge of Alice's email address and Tom's master key m, and computes. p=f("[email protected]", m). Now he applies the decryption decrypt({"x")P, p) and poof, out comes Alice's message.

The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.

Some ways this is good; it handles the problem of lost keys. But for most reasons people want to use encryption, it's bad. Now someone can subpoena Tom, or just beat him up, and get at your private data.

The result is that ID based encryption alone is a nifty idea, but hasn't got a lot of a market.

Answer 3

Charlie is on the right track, but I want to emphasize some other points. (My comments were written based on an earlier, shorter version of Charlie's answer.) IBE is more a key-management scheme than an approach to encryption, and its approach to key management sweeps the important issues under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.

Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.

Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users and key management is expensive. Relying on certificate issuers is another approach, but there it's clear that the issuers are the trusted third parties. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.

Answer 4

Identity based encryption would be difficult to pull off in an open source project, especially the kind that's not just free as in freedom, but free as in beer. As has been mentioned, the whole system relies on a trusted third party to issue keys. This takes infrastructure, for both hard and software, that is expensive to purchase and maintain. Additionally, it puts a lot of responsibility on the party that's doing the key issuing. People who use the system will expect the issuer to take responsibility when things go wrong (and they will); this kind of responsibility is not cheap, and is often infeasible for a open source project to take on.