Slashdot Mirror
Ellipse-based Email Encryption
madlinguist writes: "Researchers connected with Stanford's Applied Crypto Group have developed a new method of identity-based encryption from spending too much time with ellipses. Named after two of the researchers, the Boneh-Franklin project was presented at Crypto 2001, where these researchers encouraged the crypto community to crack their open-source system. Best of all, the project's homepage allows you to try it on your own email address."
Well, I tried to use their demo thingy to see how it worked, but it seems to require Eudora at the moment, so that wasn't really an option.
It certainly sounds interesting, especially since the public key is so short. It also makes key revocation hard - you'd have to change email address. But that's probably less confusing than many other types of key management.
I had a quick look at the details, but can't really get my head around this level of crypto stuff.
How long is the private key length, for example? And doesn't the short public key leave brute force attacks a possibility (since surely there can only be a valid number of private keys corresponding to the bit length of the possible public keys?)
- Muggins
IBE keeps being pushed as a way to solve the key distribution problem - the problem of determining someone's public key so that one can encrypt a message for them. Really the problem is not with finding someone's key, of course, but with making sure that one has the right key, and not a fake one. IBE solves this by making the public key a function of the identity. But it does this at the expense of requiring a central CA to generate everyone's private keys. Everyone has to trust this CA - it can decrypt everyone's messages, and in signature applications it can forge anyone's signature.
If everyone trusts a single CA, then there's an easier answer to the key distribution problem - the single CA just certifies everyone's public keys. This means everyone has to go to the CA to get anyone's public key, but the advantage is that the CA doesn't know anyone's private keys, and so doesn't have to be quite as trusted.
In addition to the trust issue, IBE introduces its own, much more serious, key distribution problem. The CA has to give all the private keys to their respective owners, without anyone else being able to eavesdrop, and it must be very sure that it gave each key to the right person and not to an imposter. In some specialized applications this is easy, but in most cases IBE is just replacing one key distribution problem with a more difficult one.
The system that these researchers provided the source for, for example, doesn't properly solve this problem. It needs to authenticate the user requesting a private key as being the actual owner of the email address they specified. It does this by emailing the private key to that email address - essentially, ability to read email sent to the address is what authenticates a user as the owner of that email address. This mechanism assumes that the email containing the private key can't be eavesdropped - an eavesdropper, who can receive email sent to the email address in question, passes the authentication. But if email can't be eavesdropped, then why did we want to encrypt our email in the first place?
One must also consider the increased damage that occurs if an IBE CA is compromised - all private keys ever used are compromised in one go. There's also a huge problem of replacing a compromised key.
Taken all together, IBEs just shouldn't be considered as a general-purpose PKI. I'm sure the researchers working on them understand this, but we keep getting organs such as Slashdot presenting IBE inappropriately, as something to solve all our PKI woes. Slashdot, and everyone else, please learn: IBE just isn't useful to your crypto-geek audience.
Alright, take everything I say with a few bytes of salt--One should read the paper before drawing any strong conclusions.
However, from a cursory reading I have some concerns. The security seems to rely on the difficulty of discrete division in a finite field. In other words, your public key is a hash of your email address, P, and your private key is xP where x is a secret known only to the key generator. Figuring out x from P and xP is said to be hard. All well and good (assuming my number theory is up to date).
However, the problem is that if x is compromised by anyone in the system, everyone's private key is compromised. In other words, you have to trust the key generating site not to be hacked, invaded by the FBI, or just be evil in general.
Not only that, but the security of the system relies on deriving x from xP and P being hard. Even if this is hard in the general case, I worry about weak keys. For example, if one can find a string whose hash is 1 and feed it to the site, then one gets back x*P = x*1 = x and the entire system is compromised. Supposedly the IBE paper addresses this, but I found the PDF corrupted.
You aren't in control of all your secrets in this protocol and hence you are not secure.
Cool idea, nonetheless.
The elliptic part... that's not entirely relevant to what they are saying, or to IBE.
What essentially happens here is a key authority generates your private key... and your email address is your public key. SOunds fine.. very efficient.. except that the key authority has copies of *everyone's* key (and knows how to re-generate it, if if they don't keep it)
It uses elliptic curve crypto. It has nothing to do with ellipses. Elliptic curves are not ellipses and have absolutely nothing to do with ellipses. OK - they do have a historical connection with ellipses because elliptic curves arise out of the study of elliptic functions and elliptic functions can be used to find the arc-length of an ellipse. But really the use of the word 'elliptic' is just a historical accident.
-- SIGFPE
If both the private and public key are calculated from the same publically available peice of knowledge (the email address), how do you keep the private key *private*? I am as capable as anyone of feeding "rms@fsf.org", "hemos@slashdot.org", or "billg@microsoft.com" into the algorithm as Richard Stallman, Hemos, or Bill Gates are. This gives me the ability to impersonate any of those people.
The whole idea of a private key is that it's *private*, i.e. only I know it, and no one else can figure it out from the publically available information about me.