David Schwartz wrote:
How would you know you were verifying the shared secret with the desired endpoint and not again verifying it with the man in the middle? I believe this problem is unsolvable without advanced knowledge of the desired remote peer.2) Streams of entangled particles can generate shared secrets where none previously existed.
No, not really, since the scheme described on page 80 of the Jan 2005 Scientific American looks vulnerable to a man-in-the-middle attack.
In that case, it generates two shared secrets. Either way, shared secrets are generated where none previously existed.
I'm *fairly* sure that wrt shared secrets if "none previously existed" then there is NO way to prevent a man-in-the-middle attack, as there is no way to authenticate your correspondant, however, I am willing to listen to arguments.
In this case, it's not an attack. You have a secure channel to the MITM. All that I said is that a shared secret is generated, not that you know who you share that secret with. And, of course, either of the parties to a secret can share it if they want.
You might wonder what good a shared secret is if you have no idea who it's with. The idea is that you authenticate the endpoint right after you establish the shared secret, before you send any sensitive information. The MITM cannot keep the shared secrets the same with both endpoints, so you simply confirm equivalence at the endpoints as the next step.
The advantage of quantum encryption is a guarantee that if and only if the initial connection can be guaranteed, then all future data can be guaranteed secure. Establishing (and re-establishing if the connection is broken) the authenticity of the remote peer initially can never be guaranteed, but practically speaking you can pre-distribute some piece of information to the peers in such a way that you're reasonably assured of its secrecy.
Andrew
For an example not involving any quantum encryption, consider using anonymous DH to establish a connection. Then, over the connection, each end sends the shared secret encrypted with its public key. Each end then validates the signatures and that the shared secrets match. In other words, you do MITM detection as a separate step.
The advantage over using ADH in this same application is the forward security. You are protected against future compromises of the keys involved and passive interception. This is a serious issue with public/private keys because it is *always* possible to break such a key with sufficient computational power in an automated, foolproof way.
DS
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
