Slashdot Mirror
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.
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.
An interesting idea.
I am a free-ish sort of slave!
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.
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.
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?
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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?
Muchas Gracias, Señor Edward Snowden !
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.
The OP didn't get that all identity based encryption (IBE) schemes need to have a trusted authority that issues the private keys: If I could generate my own private key (fitting to my public key that is my e-mail address), what would prevent me from generating someone else private key?
This is Slashdot. Pretty please stop underestimating our skills.
an email address is likely very low entropy.. Shouldn't both key halves be as random as possible?
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?
I'm old enough to remember when discussions on Slashdot were well informed.
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.
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.
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 also provides transport security and tls for your web connections so why even bother with IBE unless your correspondent doesn't have transport level security.
MAYBE you could create some kind of large distributed infrastructure for storing the master key but at that point it seems easier just to distribute standard public keys directly.
If you liked this thought maybe you would find my blog nice too:
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 that anyone encrypting messages needs information about all the master keys so it really is like certs, you trust all the root certs in the list that comes with your software.
On the other hand if each email address can specify the master key to use with it we are back to the problem of key distribution as the choice of master public key for your email address functions just like a public key (to send you encrypted messages the sender needs to know it and if they are tricked into using the wrong one you get a MITM attack).
Obviously, I use email to stand in for whatever identifier one has in mind.
If you liked this thought maybe you would find my blog nice too:
slice and dice it any way you like it's still a turd.
yum?
What you describe is no different than the weakness of any public-private key encryption scheme.
Revoke is pointless. You can always refuse messages encoded with an old key, so you can abandon them.
Half of the problem with encryption is that you make it too complex, add on pointless fluff like key-revoke, and third party identify confirmation, and in the process you open it to attack, and make it so complex as to be useless.
Just attach the public key to outgoing messages, reader stores the key, and verifies them each time, and over time if the key changes they can flag it. To attack that system you have to intercept the first key, and then every subsequent message (miss one and the key is flagged and the user alerted). Since no attacker can travel back in time, it is as secure as the first key exchange*.
* And the encryption scheme needs to be secure, so use a combination of all of US, Russian and Chinese encryption schemes.
* And the software doing the encode/decode needs no backdoors, so open source and no 'auto upgrade'.
A user can always do the first key exchange themselves via a USB key or similar, or verify it later via a different route.
When you get a key, you encrypt the messages to that user automatically using their key.
Isn't this what PGP is for?
Buck Feta. You know what to do.
Encryption can be simple easy and painless.
Simply sending out your public key automatically, and encrypting with that public key if you have it.
If you attach a public key to outgoing emails, and you receive spam unencrypted without the public key, then it makes the spam filtering much easier. The important stuff is encrypted, spam is in the unimportant stuff.
*Your* computer is perfectly capable of searching *your* emails. Thunderbird still does search and spam filtering without issue.
You really don't need to make it more complicated than simple public key encryption. The complexity is what prevents widespread encryption.
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,
well ....
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 to use slight variations of this data to create alternate identities for different services and "ID spaces". There exist implementations of this concept, e.g. search Google for "decentral identities". There would be no need for password based login to services, because you would log in with the public key of your identity, and you would use the private key to prove your identity. Server side password theft is no longer possible. With such a scheme, you could possibly maintain only one single very complex password, and all identities are generated from that password, by adding e.g. service name. No need for any password manager or such.
If the key is compromised, then the identity is effectively lost. The identity would have to be revoked by distributing a self-signed revocation certificate, and the user would have to register a new identity to associate with service accounts and for contacts.
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 issue in which the public information would keep growing as the number of issued keys and users grew, causing a scaling issue that limited practical, widespread applications. Again, I can't judge if this is indeed correct.
But, as noted, this does require a trusted third party to ultimately decide if a key is valid. Also, a lot of the work seems to be temporally based; the identity is combined with a timespan to create a key that is only use for a given set of time.
It's an interesting idea overall. It avoids the public key problem by making the information you need the channel in which you communicate on. (For example sending a encrypted email in which the key is the email address),
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 mathematician to check my interpretation though.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Serious question. Why is there not just some email header that contains your public key so that anyone who had gotten an email from you and has a supporting client can then send you an encrypted message? It so simple a solution that I assume I must be missing something obvious that prevents it from be a no brainer for key distribution.
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?
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen