The Internet's Secret Back Door
slate.com
slate.com
I put my secret in a box and put a lock on it for which only I have the key and ship the box to you. When you receive the box you put your own lock on the box for which only you have the key and send the box now with two locks back to me. When I get the box I take my lock off and send it back to you. Finally you open the box by taking your lock off. The box is always locked in transit and no keys were ever out of the owners hands.
See: http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html
Search down for Diffie-Hellman.
The Wikipedia article might also be useful:
Asymmetric key encryption is slow, and symmetric is fast, so we use the former to set up the conditions necessary for the latter: If we both have a box and keypair like this, then you can send me your secret phrase using mine and I can send you my secret phrase using yours. Now that we each know both secret phrases and nobody else knows either, we can combine the secret phrases and switch to symmetric. That's how SSL is set up.
Is the term 'asymmetric key encryption' meaningful, or did I just make that up?
This is why we have trusted third parties like Verisign.
The further problems with this are discussed in the article.
This is the problem with analogies such as these. They can sort of be nearly right, and sort of give the right idea, but at the same time actually be quite misleading in the detail.
Here's what's actually equivalent to the analogy. We openly agree a large prime N (this is equivalent to agreeing on a style of box to use). I select a random number A (the padlock) and compute its multiplicative inverse A' (mod N) (the key). You do the same to compute B and B'.
I want to send you a message M. I compute W=M^A (mod N) [I put the message in the box and lock it with the padlock] and send that to you. You compute X=W^B (mod N) [you put your padlock on it] and send it back.
Now I compute Y=X^A' (mod N) [unlock with the key] and send you that, and finally you unlock with B' by taking Z=Y^B' (mod N).
We compute Z=Y^B'=(X^A')^B'=((W^B)^A')^B'=(((M^A)^B)^A')^B' but that's equal to M^(A.A'.B.B') which turns out to equal M. On the way any evesdropper will know M^A, M^(A.B) and M^B, but it is computationally infeasible (if P!=NP) currently to compute M, A or B from these.
The obvious method of attack is to use M^A and M^(AB) to try to deduce B and hence compute B', but that's equivalent (probably) to the discrete log problem ( http://en.wikipedia.org/wiki/Discrete_logarithm ) which is thought to be pretty similar to factoring integers.
Both RSA and Diffie-Hellman-Merkle-Williamson key exchange need different analogies. RSA usually uses the analogy that I give people open padlocks, and they use them to send me locked boxes. I can open them because I have the key.
I don't know a good analogy for the DHMW key exchange. It works like this. We agree a large prime N and a suitable base b. I choose a random A, compute X=b^A and send X to you. You choose a random B, compute Y=b^B and send that to me. I compute Y^A, you compute X^B, and we both end up with K, a shared secret which we can use in a symmetric cipher.
I now await the really clever people to correct my errors.
The sender and receiver exchange public keys which can be visible by anyone. Only the private key can unlock what is locked with its associated public key. It would be like me sending you a locked box (that only I have the key to) with a slot in the top to allow messages to go in but not come out. And then you send me a similar locked box with a slot in it for me to put messages in. Once a message goes in the slot, only the private key owner can unlock it.
There is still a problem with man in the middle attacks where an attacker steals each public key and sends his own public key back to both participants. This problem is somewhat solved by the use of certificate authorities who certify that the public keys belong to who they say they belong to. Some of these certificate authorities have delegated their powers to organizations which may not be trusted.
In that case, couldn't the EFF or similar organizations take matters into their own hands, and release lists of certificates they think users should be cautious about?
I suspect libel laws make this more difficult, but perhaps not impossible, if revocation providers are careful not to overstate their case, but just say "here's a list of certificates of organizations who have been documented to meet the following criteria...".
[Edited to add:]
http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revo... says that "To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory." It's not clear whether the browser checks this signature, or whether the user is expected to. In the latter case, a CRL could be signed by the 3rd party revocation provider instead.
Background: Browsers check for a man-in-the-middle attack by verifying that: a) remote site's certificate is signed by a certificate authority (CA) that the browser trusts; b) the URL matches the common-name attribute (CN) in the site's certificate.
So, for an attacker to get around this check, they need to: a) forge/spoof DNS (relatively easy); b) get a cert signed by a CA the browser trusts with a matching CN of the site to be spoofed (supposed to be relatively hard). (There is also Extended Validation, I won't go into that here.)
Unfortunately, these days, browsers trust _a lot_ of CA's, either directly or via chained certificates. Some of these chained certificates may be surprising to you.
SSL does not encrypt content and vendors don't all ahve their own rules about how SSL works. It's a standard. I really wish that journalists covering technical matters would do enough research to explain things properly.
I'm not sure if you can delete any of the OS's built-in certs ('cept maybe on Linux); and I'm not sure I'd want to risk that. Verizon/GTE/whoever probably authenticates a lot of really useful people too... (Which is a risk with deleting the browser's root certs as well.)
Having said that - no comments there.