Sergio wrote: > I think you have a conflict with your ideas. A and B want to secure its > communication. They need to be agree about which key to use. I suppose > you can encrypt the information at the origin using a symmetric key > (aes, des, idea etc) and decrypt ir at destination with the same key. A > and B must know the key. But also i suppose you can establish a ssl > connection to perform a key exchange (key negotiation) using > certificates or public keys (asymmetric keys) without certificates. In > this situation neither A and B need to know about a previous secret. > This is the normal situation of a client-server environment.
Actually, the normal situation is that one of either A or B does know a previous secret. They do not need a shared secret, but one of them must know something secret. Otherwise, it is impossible to reject a MITM. For example, when I connect to https://www.amazon.com in my browser, Amazon's web server (or whatever they use as the SSL endpoint) knows a secret -- a private key that's vouched for by a certificate. The beauty of the system is that I don't have to know any secrets. But one end must know something secret or the connection will not be secure. It is possible to use a pre-arranged shared secret in lieu of any certificates and provide the same level of security. It must be done correctly -- you can't just send the key over an ADH link (or even verify the key over an ADH line). The only reduction in security would be that the same secret cannot be used for connections to different clients, unless those clients fully trust each other. Algorithms to do this are basically simple. The idea is that each end mixes the pre-arranged shared secret with the ADH-negotiated shared-secret and they exchange messages. If the ADH-negotiated shared-secret matches on both ends, there is no MITM, and the MITM can't forge these messages because he doesn't know the pre-arranged shared secret. I don't know offhand if such algorithms are built into SSL. However, I can easily sketch out one that I believe would be completely secure: 1) Use ADH to establish the SSL connection. (In fact, you can use a self-signed certificate and RSA or DSA.) 2) As soon as the connection is established, but before any data is exchanged, each end gets its own and the peer's finished message, appends the pre-shared secret, and computes the SHA1 hash of both messages. 3) Each end sends the hash that used the peer's finished message to the peer and compares the result to the hash it didn't send. If it matches, you may continue to exchange data. If not, the connection is rejected. This works because once an ADH connection (or any SSL connection) is setup, the connection is secure if and only if there is no MITM. If there is a MITM, then no entity knows both the pre-shared secret and the newly-negotiated ADH secret (since only the MITM knows the newly-negotiated secret and only the legitimate peer knows the pre-shared secret). Hence reception of the correct hash proves there is no MITM. A MITM cannot force two ADH connections to produce the same negotiated secret. So he cannot proxy the authentication. (And, of course, the MITM cannot extract the secret from the hash, even if he knows the other part of it.) Note that I'm 99% sure this is as secure as anything else typically done with SSL. But balance your reliance on this information against your need for security. Again, SSL might provide a simple way to use a pre-shared secret. It wouldn't susprise me, though I don't know it offhand. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
