Researchers Propose a Revocable Identity-Based Encryption Scheme 76
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.
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.
Any other schemes to choose from? (Score:2)
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: (Score:2)
This isn't a new idea. I saw the opposite workings with the NeXT back in 1992 had a public/private key scheme, where a person could create a password or passphrase, of any characters as a private key, and then NeXTStep would make a public key from that phrase.
Not distributed (Score:5, Interesting)
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 (Score:4, Interesting)
(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: (Score:2, Informative)
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 comp
Re: (Score:1)
Yeah. And Someone(TM) is providing private keys -- thus the keys ain't truly private anymore.
One of the really nice properties of the "classical" schemes were that my private keys never left my realm -- from (and including) creation to disposal.
While there are enough weaknesses to these schemes as well (is my realm secure?), giving up this property seems to make us weaker, not stronger.
Make no mistake: big players will be pushing towards central management, but that's not because it serves the user, but bec
flawed (Score:3, Informative)
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: (Score:3)
Something seems off... (Score:5, Interesting)
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: (Score:1)
The article summary is useless, it's just better to read the article.
Re: (Score:2, Funny)
It's the wibbly wobbly, timely slimely, wishy washy magic sauce.
Re:Something seems off... (Score:4, Informative)
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: (Score:1)
We used to trust the USA
At least, ***I*** used to
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
from wiki (http://en.wikipedia.org/wiki/ID-based_encryption)
A trusted third party, called the Private Key Generator (PKG), generates the corresponding private keys.
Right. It's the same as PKI, just more complicated.
Re: (Score:2)
Problem is there are no trusted third parties any more. Pretty much anyone could be lent on by governments demanding access to keys and gagging them from warning users. There is also the risk of hacking my GCHQ/NSA/etc.
Re: (Score:2)
Could a domain owner be their own trusted third party?
Re: (Score:2)
What the FUCK?!
...retains the corresponding master private key (referred to as master key).
So we have a Master Public Key and a Master Private Key but we refer to the Master Private Key as only Master.
What kind of hand-waving smoke and mirrors bullshit is going on here?
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.
Contacts the PKG which uses the Master Private Key?
Really. What. The fuck. Ever. Did I miss something here? How is this in ANY way a good idea? "But if you trust..." I trust NOBODY. I barely even trust myself and only because I have to.
Meh
Re: (Score:2)
Because no-one else in the world knows how to ROT13 the @ sign.
Re: (Score:3)
And neither does the American Secret Service.
Are you sure about that [wikipedia.org]?
Re: (Score:2)
And neither does the American Secret Service. If you intend to use this technology to engage in terrorist activities, we will find you. You can't escape the SS.
Apparently you didn't read the news this weekend.
Oh please. (Score:5, Insightful)
This is Slashdot. Pretty please stop underestimating our skills.
Re: (Score:1)
I don't even know how to code 'Hello World' in QBASIC.
Re: (Score:2, Funny)
Let me explain how to do it:
1. open your editor
2. do some wibbly-wobbly stuff
3. some more timey-wimey
4. done!
Re: (Score:2)
This should work in any BASIC dialect:
10 PRINT "HELLO WORLD"
Re: More great insightful summaries from /. - not! (Score:2)
I've used the site longer and reserve the right to use Doctor Who references where I'm suspicious of technical details, especially as relate to timing vulnerabilities. This is allowed, as per The Hacker's Dictionary. Bonus points for finding the Doctor Who references included.
entropy (Score:4, Insightful)
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 (Score:3)
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 (Score:3)
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 (Score:5, Funny)
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.
No better than using gmail (Score:2)
As any such identity based encryption requires a master secret (or secrets) that is used to generate the private keys (if not anyone who knows your email can generate a private key for that public key and thus read anything encrypted to you) you might as well just be using gmail and counting on google not to get hacked. After all, you can't compromise every gmail account by gaining access to a few servers but anyone who hacks the server with the master secret brings down the whole system in IBE. And gmail
Multiple master secrets (Score:2)
Of course you can have as many master secrets as you want with each controlled by a different entity but those master public keys need to be distributed somehow. However, if you try and allow any master secret to work with any email you have exactly the system we have with ssl certs and we know that won't work for things like email. After all if any master secret can generate a private key for any email that means that if any master key is compromised so is the whole system. I believe it also requires th
Re: (Score:2)
It's an older code, sir...but, it checks out. Shall I hold them?
No...I will DEEEAAAALLL with them myself.
Re: (Score:2)
Revocation in general has issues. If you block access to a revocation server, it would allow a key that is compromised to be in effect longer.
The ideal might be SLC (short-lived certificates), but of course, the downside of that is the computational overhead by the key signing machines.
I agree with you on the software. In the 1990s, console games were not shipped until they were finished. Not "finished", but of a release grade. This doesn't mean it will be 100% bug free, but solid enough. Even with thi
PGP? (Score:1)
Anybody ACTUALLY read the article? (Score:2)
Or, are they responding the premise that this simply can't be secure?
I haven't fully digested it, but it sounds interesting at the very least for me to at least try to understand it. It does not appear to be a crackpot article as one might assume. And, it sounds like it's being posted for true peer review as most security papers should,
Better to make the public key the identity (Score:1)
It makes sense embedding into the identity itself the means to prove that identity. Linking a public key identity to an email address would be simple; you just put a self-signed certificate somewhere which claims "this email address belongs to me". There could be public, distributed lookup services for this.
To make things simpler, instead of using complex schemes for carrying private keys around, better just to use a deterministic key generation scheme which builds the identity from a passphrase. It is easy
Cursory reading (Score:2)
To address the summary, the difficulty is in proving certain security aspects, as current models don't fit the assumptions that RIBE models use. In practice, it could be fine.
The article seems to propose a set forward in a scheme to manage the keys by combining two previously proposed methods in a novel way. I can't judge if this is indeed an advance as I am not familiar with this domain. The main advance claimed is that the publicly needed parameters is constant. This suggests that other schemes had an iss
Re: Cursory reading (Score:2)
That was pretty much my interpretation as well. Which would be great for ad-hoc encrypted tunnels - the source and destination can have keys that are valid only until the tunnel's authentication expires (typically hourly) and where the encryption is based on the identity the other side is known by. Ad-hoc tunnels need to generate keys quickly and efficiently, but also don't need to be super-secure. In fact, they can't be.
If RIBE isn't useful in ad-hoc, then you'd end up having to ask when it would be useful
The Time? (Score:2)
After reading through it, my first response to new IBE schemes is "Can I implement it efficiently in hardware?". In this instance, no. The need for bignum arithmetic is a problem since it leads a nondeterministic state requirement. Worse is it appears to require a common understanding of time between the interacting entities. If IBE is used for the key management and those keys are used to secure a common, secure notion of time, then you have a circular dependency.
I'll need to go an abduct a proper crypto m
why not use email header (Score:1)
Oh my god (Score:2)
and having a private key generator do some wibbly-wobbly timey-wimey stuff to generate a secure private key out if it.
This is another one of those fucked up "articles" isn't it... Perhaps it is time I left. What the HELL is up with this crap? When I arrived here back in 99 there were very few articles that insulted me. Lately, it seems that one out of every 5 articles is insulting me. Did I miss a memo or something?
Re: Oh my god (Score:2)
Don't Blink.