7 ms·

I don't understand how SSL can be secure. Aren't the keys for encrypting and decrypting transferred in the open before encryption can take place? If so, isn't a

by augustl 16y ago

I don't understand how SSL can be secure. Aren't the keys for encrypting and decrypting transferred in the open before encryption can take place? If so, isn't a man-in-the-middle able to snoop those keys?

asmithmd1 16y ago
I like this analogy for how keys are exchanged and never exposed in transit: 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.
- augustl 16y ago
  Great! This explanation was worth the downvotes my post got :)
- electromagnetic 16y ago
  Thank you, this is one of the most succinct explanations I've read. I understood how it worked in a roundabout concept, but you made the explanation simple like it should be.
- brownleej 16y ago
  I don't think this is the method SSL uses, because what you're describing is just a variant of symmetric-key encryption. I think SSL uses asymmetric-key encryption. The better metaphor for that is a lock that anyone can lock, but only one person can unlock.
  - jacobolus 16y ago
    That’s how SSL/TLS does the authorization step, but the typical encryption of the actual content sent back and forth uses a symmetric-key block cipher (the two sides negotiate and it’s pretty modular, so I think you can do whatever kind of encryption you want on the messages, even just sending plain text after a TLS handshake if you want). See http://en.wikipedia.org/wiki/Cipher_suite http://en.wikipedia.org/wiki/Cipher_suite
    - brownleej 16y ago
      True, but my point was that the actual key exchange (that is, the exchange of the symmetric keys used for the bulk of the encryption) is done using asymmetric-key encryption. Since this was in response to the question of how keys are exchanged, I thought it was the relevant phase to discuss.
      - jacobolus 16y ago
        Except, not necessarily, no. Sorry, my grandparent post should have been clearer that using a public-key method is only one of the ways to do authentication in SSL/TLS. Either way, some symmetric cipher is used for all the content. See: http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html Search down for Diffie-Hellman. The Wikipedia article might also be useful: http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
  - Bluem00 16y ago
    I've heard a different variation of the metaphor: I have box with two keys. When I use the first key to lock the box, it can only be opened with the second key, and vice versa. I keep the first key hidden, but publish details of how to make a box and the second key for all world to see. This means that anyone can send me a secure message by simply making a box to my specifications and locking it with the publically available key. Only I can unlock it. This is asymmetric key encryption. 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.
    - kngspook 16y ago
      This is the description of public key cryptography, or as you referred to it, asymmetric cryptography. It is a different technique and solves a different problem from the other metaphor above by asmithmd1, which is for Diffie-Hellman(-Merkle) key exchange.
      - Bluem00 16y ago
        Oh. Thank you. I suppose I'll go re-read the other post and learn something. Is the term 'asymmetric key encryption' meaningful, or did I just make that up?
- maggit 16y ago
  This principle is called Diffie-Hellman key exchange ( http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange ) and is vulnerable to a man in the middle attack. The man in the middle would complete key exchanges with both Alice and Bob. All that A and B see are valid key exchanges. This is why we have trusted third parties like Verisign. The further problems with this are discussed in the article.
- RiderOfGiraffes 16y ago
  That explanation is a common one, and very clear. It still doesn't solve the "Man in the Middle" problem.
- RiderOfGiraffes 16y ago
  More correctly, this is how to send a message using commutative ciphers without ever exposing any keys - public or private. 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 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.
jdhopeunique 16y ago
http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography 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.
tptacek 16y ago
The answer to this question is simple: the "egg" key in this chicken in egg problem was distributed with your browser. If a man in the middle can mess with your browser installation, you have bigger problems than SSL.

by augustl 16y ago

asmithmd1 16y ago

I like this analogy for how keys are exchanged and never exposed in transit: 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.

augustl 16y ago
Great! This explanation was worth the downvotes my post got :)
electromagnetic 16y ago
Thank you, this is one of the most succinct explanations I've read. I understood how it worked in a roundabout concept, but you made the explanation simple like it should be.
brownleej 16y ago
I don't think this is the method SSL uses, because what you're describing is just a variant of symmetric-key encryption. I think SSL uses asymmetric-key encryption. The better metaphor for that is a lock that anyone can lock, but only one person can unlock.
- jacobolus 16y ago
  That’s how SSL/TLS does the authorization step, but the typical encryption of the actual content sent back and forth uses a symmetric-key block cipher (the two sides negotiate and it’s pretty modular, so I think you can do whatever kind of encryption you want on the messages, even just sending plain text after a TLS handshake if you want). See http://en.wikipedia.org/wiki/Cipher_suite http://en.wikipedia.org/wiki/Cipher_suite
  - brownleej 16y ago
    True, but my point was that the actual key exchange (that is, the exchange of the symmetric keys used for the bulk of the encryption) is done using asymmetric-key encryption. Since this was in response to the question of how keys are exchanged, I thought it was the relevant phase to discuss.
    - jacobolus 16y ago
      Except, not necessarily, no. Sorry, my grandparent post should have been clearer that using a public-key method is only one of the ways to do authentication in SSL/TLS. Either way, some symmetric cipher is used for all the content. See: http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html http://www.ipa.go.jp/security/rfc/RFC2246-AFEN.html Search down for Diffie-Hellman. The Wikipedia article might also be useful: http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
- Bluem00 16y ago
  I've heard a different variation of the metaphor: I have box with two keys. When I use the first key to lock the box, it can only be opened with the second key, and vice versa. I keep the first key hidden, but publish details of how to make a box and the second key for all world to see. This means that anyone can send me a secure message by simply making a box to my specifications and locking it with the publically available key. Only I can unlock it. This is asymmetric key encryption. 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.
  - kngspook 16y ago
    This is the description of public key cryptography, or as you referred to it, asymmetric cryptography. It is a different technique and solves a different problem from the other metaphor above by asmithmd1, which is for Diffie-Hellman(-Merkle) key exchange.
    - Bluem00 16y ago
      Oh. Thank you. I suppose I'll go re-read the other post and learn something. Is the term 'asymmetric key encryption' meaningful, or did I just make that up?
maggit 16y ago
This principle is called Diffie-Hellman key exchange ( http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange ) and is vulnerable to a man in the middle attack. The man in the middle would complete key exchanges with both Alice and Bob. All that A and B see are valid key exchanges. This is why we have trusted third parties like Verisign. The further problems with this are discussed in the article.
RiderOfGiraffes 16y ago
That explanation is a common one, and very clear. It still doesn't solve the "Man in the Middle" problem.
RiderOfGiraffes 16y ago
More correctly, this is how to send a message using commutative ciphers without ever exposing any keys - public or private. 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 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.

jdhopeunique 16y ago

http://en.wikipedia.org/wiki/Public-key_cryptography http://en.wikipedia.org/wiki/Public-key_cryptography 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.

tptacek 16y ago

The answer to this question is simple: the "egg" key in this chicken in egg problem was distributed with your browser. If a man in the middle can mess with your browser installation, you have bigger problems than SSL.