Ellipse-based Email Encryption 15
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."
Sounds Cool (Score:1, Interesting)
I wish I understood this stuff (Score:2)
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
Re:I wish I understood this stuff (Score:1)
I have not read the details, but I know that elliptic curve cryptography requires much shorter keys than a 'normal' public key system, to obtain the same level of security.
I think that the time it takes to break a 2048 bit key by brute force in a 'normal' system, corresponds to the time it takes to break a 210 bit key in a elliptic curve system. These numbers refer to the RSA and the ElGamal, the latter being an elliptic curve based RSA like system.
The new system is possibly even better thank ElGamal.
Interesting (Score:1)
...and give them a potential list of persons that will do evil things with encryption that self-minded politicians will subpoena for black-listing.
Personally, I like the idea of encrypted communications. The more the merrier!
!sdnah ruoy no emit hcum oot evah uoy siht daer nac uoy fI
when are people going to learn? (Score:2, Informative)
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.
Obscurity not Security? (Score:2, Interesting)
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.
Well.. (Score:2)
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 has nothing to do with ellipses (Score:4, Informative)
Yikes (Score:1)
How is this secure? (Score:1)
If the key generator server has some sort of secret value that it uses to compute the keys with, what happens if that server is cracked.
If this one piece of information is discovered, it breaks all encrypted documents using the keys that key generator server issued.
There is also the issue of trust in the administrator(s) of the key generator server. Since they have access to the secret data used to generate the private key, they can decrypt any document encrypted with this method.
Is it just me or does that not sound all that secure.
Is this the type of backdoor crypto scheme the government seems to be going after?
Smells like snake oil from here (Score:3, Insightful)
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.
Redundant( 0 ) (Score:1)
"Once Bob receives an encrypted message, he retrieves his private key from the trusted server (he only has to do this the first time) and then decrypts."
It's absolutely backdoored and therefore worthless.
And another thing, who cares what algorithm they use to convert the mail address to a private key? It's the protocol that's flawed.
I don't know why anyone wasted their time on this unless they got a grant ( from somewhere with a 3-letter acronym ) to do it.