Note that there is one case which falls more into the 'shared secret' category than the 'trusted introducer' category, and that is the case where you have two entities which share self-signed certificates. Even though what they share aren't secrets, they still have to do it through a mechanism that can authenticate the certificate exchange.
(Now, one or both of the parties can act as trusted introducers to the other, if the other trusts them. This causes their self-signed certificate exchange to have much more use and meaning, because it means that their public keys were exchanged in a secure manner... and thus anything signed by them can be trace back to them. I'm still exploring the ramifications of this in small, enclosed peer-to-peer communities, with essentially a web of trust implemented in X.509.) -Kyle H On Sat, Aug 29, 2009 at 12:52 PM, David Schwartz<dav...@webmaster.com> wrote: > >> No. Without a previously arranged shared secret and no trusted introducer, >> authentication is *impossible*. Authentication is an act of recognizing >> a party that posesses something you can verify. You CAN NOT generate >> authentication secrets on the fly. > >> Viktor. > > Or, to put it in simple terms, to ensure that you are talking to the correct > party, there must be some definition of "correct party" that is testable or > verifiable. It requires in principle that the correct party have something > or be able to do something that no MITM has or can do. > > Otherwise, MITM rejection is impossible in principle. There must be some > difference between the MITM and the intended endpoint. > > (This is not quite literally true, as interlock provides another way to do > something sort of like MITM rejection. But for practical purposes, it's > correct. If the idea is that MITM rejection must actually complete at some > point and allow normal communication to progress afterwards, there is no > other way known.) > > DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
