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

Not distributed

[Animats]

I'm not qualified to judge whether it's secure, but it's not distributed. "Each user is provided by PKG with a set of private keys corresponding to his/her identity for each node on the path from his/her associated leaf to the root of the tree via a secure channel as in IBE scheme." So there's a tree of all users, maintained by somebody. I think; the paper suffered in translation.

Re:Not distributed

[Lennie]

(I haven't read the article yet)

Distributed wouldn't be my fear, federated would be fine (for example can a person or organization use their own domain).

I wonder will my communication be easy to identify with an Identity-based encryption scheme.

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.

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:flawed

[Sique]

You can by adding a random salt. If the scheme warrants that the spaces of possible private keys of two sources don't overlap, then you can have secure private keys which are not recreatable from the publicly known source, but which still can be attributed to it.

Something seems off...

[penguinoid]

If the email address is the public key, and then you generate a private key from that... what's to stop someone else from generating your private key from the email address?

Re:Something seems off...

[Anonymous Coward]

It's the wibbly wobbly, timely slimely, wishy washy magic sauce.

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.

Any other schemes to choose from?

[Taco Cowboy]

So we have email-based public / private key encryption scheme; revocable identity-based encryption scheme ...
 
Are there other schemes or paradigms we can choose from?

Re:Terrorism never sleeps

[Chrisq]

And neither does the American Secret Service.

Are you sure about that?

Oh please.

[andyn]

having a private key generator do some wibbly-wobbly timey-wimey stuff to generate a secure private key out if it.

This is Slashdot. Pretty please stop underestimating our skills.

Re:Oh please.

[Anonymous Coward]

Let me explain how to do it:
1. open your editor
2. do some wibbly-wobbly stuff
3. some more timey-wimey
4. done!

entropy

[epyT-R]

an email address is likely very low entropy.. Shouldn't both key halves be as random as possible?

The same public key can map to many private keys

[Simon Brooke]

Private key and public key are factors in a two factor mathematical relationship.

So there can potentially be many (possibly infinitely many, I haven't tried to prove this) valid private keys for any given public key.

So I can see that, given the public key john@doe.com, I can see that there could be potentially many private keys. I see how you could brute force selecting a private key that matched your public key, and I can see that, depending how the brute-forcing is done, it would not be determinate that an attacker also trying to brute force a private key from the same public key would not come up with the same private key.

What I can't see is how, if you have a message which unlocks with the public key, how you can tell whether it was locked with the 'authentic' private key or with an attackers' inauthentic private key.

Anyone?

Probably not

[IamTheRealMike]

whether (in light of what's known) default strong encryption for everything is something users should just get whether they like it or not.

There are many unsolved problems for making strong end to end secured communications work. Key management is only one. A bigger and even more complicated problem is that people derive significant benefits from sharing their message contents with big, powerful third parties, for example spam filtering, importance filtering, ability to search 10 years of email from a cheap battery powered device, ability to receive messages when all personal devices are offline, ability to reset passwords if they are forgotten and so on.

To make truly end to end communication ubiquitous you would have to find a way to recreate all these features in the purely decentralised end to end context. Otherwise "giving" e2e crypto to people "whether they like it or not" is a quick way to find an angry mob with pitchforks outside your house. A lot of people care a lot more about those features than (somewhat theoretical) privacy against the NSA.

wibbly-wobbly timey-wimey stuff

[thegarbz]

Oh thank god for a moment I thought I was going to get a dumbed down news article rather than news for nerds. Good to see they cover the technical details like the "wibbly-wobbly timey-wimey stuff" in the summary.