David Schwartz wrote:
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.
OK, fine, split hairs :-) there are two shared secrets but there are no secrets shared by A and B. There is one shared by A and X and another shared by X and B.
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.
More hair splitting.
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.
It seems to me that this all depends on an authenticated (but not necessarily secret) channel between the two parties. For example, in the Scientific American article, a man in the middle would have to be able to send back to A, in step 4, what looks to her like B's list of the (randomly generated) filter selections that had been used. Otherwise X still does a man in the middle attack:
A tries to talk to B, but X plays B's part, randomly generating a set of detection filter choices and recording both the filter and measurement.
X then sends back to A the list of measurements (just as B would have). When A sends X the list of agreed bits, the AX channel is complete.
X then sends to B, the article doesn't say but I assume both the choice of sending filters and the sent bits are randomly generated. When B replies with the list of filters he decided to use (thinking he was talking to A) then X completes the channel as if she were A. Now the XB channel is complete. Neither side can detect the man in the middle unless they can sneak some key mixing through X.
What this depends on is X being able to masquerade as B when returning the list of detection filter choices to A, and to be able to masquerade as A when sending the list of bits to be used on to B.
SO, if you have an authenticated channel you can build a secured channel. No surprise here, if you have an authenticated channel from A to B you can generate a public/private key pair at A and send the public key to B, then have B generate a session key and send it back to A encrypted by the public key just exchanged. This should be somewhat obvious to the readers on the OpenSSL list (:-) since we are using a PKI as exactly this authenticated channel courtesy of the public key of the CA.
I wonder what the hardware boxes do. Do you think they display a number on a display, and that Alphonse has to make a phone call to Beauregard, saying "Hi Beau, how are the wife Betty and the two boys Barry and Billy? My box says FEED FACE DEAD BEEF. What does your box say?"?
If the boxes do steps 4 and 5 over the fiber I don't see any way (other than pre built in keys in the boxes) for preventing MIM.
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.
Hmm I do not follow here. What good does it do to encrypt the shared secret with THIS side's public key, since the OTHER side would need THIS side's PRIVATE key to do anything useful with it? This makes no sense to me.
Each side sends the other side the shared secret encrypted with THE OTHER SIDE'S public key? This allows the other side to decrypt with the other side's private key and check for identity (much like key mixing) but how do you get the other side's public key over here without vulnerability to impersonation?
Each end sends the other side the shared secret encrypted with THIS SIDE's private key? Again, how is the other side to get, in an authenticated way, this sides's public key?
Are you assuming each side has the other side's certificate, signed by a trusted CA?
I guess the fourth possiblility is to send the shared secret encrypted with the other side's private key, again, the question is how do you get it? Do any permutations involving having the other side's private key make any real sense at all?
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.
Yes I guess this IS the strong promise of the quantum stuff. I wish I understood enough about the claims of the Perfect Forward Security stuff to make a strong argument about conventional encryption being just as strong, but the fact is that I don't, and my gut feeling is that in fact it isn't...
-- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..."
Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
