Researchers Propose a Revocable Identity-Based Encryption Scheme

jd writes Identity-based public key encryption works on the idea of using something well-known (like an e-mail address) as the public key and having a private key generator do some wibbly-wobbly timey-wimey stuff to generate a secure private key out if it. A private key I can understand, secure is another matter. In fact, the paper notes that security has been a big hassle in IBE-type encryption, as has revocation of keys. The authors claim, however, that they have accomplished both. Which implies the public key can't be an arbitrary string like an e-mail, since presumably you would still want messages going to said e-mail address, otherwise why bother revoking when you could just change address?

Anyways, this is not the only cool new crypto concept in town, but it is certainly one of the most intriguing as it would be a very simple platform for building mostly-transparent encryption into typical consumer apps. If it works as advertised. I present it to Slashdot readers to engender discussion on the method, RIBE in general and whether (in light of what's known) default strong encryption for everything is something users should just get whether they like it or not.

Comments

flawed

[Anonymous Coward]

You can not generate a secure private key from a public key by definition.

This method requires the use of a middle man.

Everytime you make it "stupid proof" you make it insecure, in this case, needing a trusted (insecure) third party.

Let's just grow up, and start teaching kids at a young age about data security and making better UX for existing tech.

Re:Something seems off...

[jarkus4]

from wiki (http://en.wikipedia.org/wiki/ID-based_encryption)

Identity-based systems allow any party to generate a public key from a known identity value such as an ASCII string. A trusted third party, called the Private Key Generator (PKG), generates the corresponding private keys. To operate, the PKG first publishes a master public key, and retains the corresponding master private key (referred to as master key). Given the master public key, any party can compute a public key corresponding to the identity ID by combining the master public key with the identity value. To obtain a corresponding private key, the party authorized to use the identity ID contacts the PKG, which uses the master private key to generate the private key for identity ID.

Re:Not distributed

[Anonymous Coward]

For most schemes you can't check which identity encrypted a message unless you know the private key, so you can't be tracked any more than e-mail headers already tell about you. The main problem with all IBEs is that you need a centralized key generator that will generate all the keys. The key generator has a master secret key and can therefore decrypt all messages. Therefore, it's best suited for organizations, where it doesn't hurt that there's one entity with the keys to the safe.

There are some more complicated attribute based encryption schemes, where there can be multiple key generators that do not trust each other. Each key generator can give out rights "attributes" that it manages, but no other key generator can enable a user to have these rights. I.e. one key generator for company X can give a user the attribute "is an employee of X" while a key generator for company Y can give the same user the attribute "is a contractor at Y". Then if someone sends out a message, you can give the message the attributes, say, "contractors and employees at Y" and then this said user could decrypt the message being a contractor at Y, but a regular employee at X could not open it.

However, key sizes tend to grow with the number of key generators, so these are not implementable in practice.