Hacker News Reader

Comment by asmithmd1 | Hacker News Reader

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.

View on HN

This principle is called 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.

Great! This explanation was worth the downvotes my post got :)

That explanation is a common one, and very clear. It still doesn't solve the "Man in the Middle" problem.

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 ) 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.

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.

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

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.

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

Search down for Diffie-Hellman.

The Wikipedia article might also be useful:

http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

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.

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.

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?

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.

Reply on news.ycombinator.com