<div dir="ltr"><div>No. Even in principle, this is essentially impossible -- two parties with no relationship basically can't communicate securely.<br></div><div>There are lots of approaches to the problem, but they all involve breaking the 'no relationship' constraint. PKI -- and thus iMessage, WhatsApp -- does it by introducing a well-known trusted third-party. PGP / Web of Trust does it by relying on social graphs. OTR and SSH leave it up to you: they show you the key fingerprint, and it's up to you to work out whether it's the right one.</div><div>But in general, the problem you're describing has no solution.</div><div><br></div><div>(Once you've exchanged keys, of course, there are a multitude of way to create a secure channel on that basis. But you need to exchange keys somehow first.)</div><div><br></div><div>Justin</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 December 2015 at 23:43, U.Mutlu <span dir="ltr"><<a href="mailto:for-gmane@mutluit.com" target="_blank">for-gmane@mutluit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Justin King-Lacroix wrote on 12/06/2015 03:23 PM:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
There are basically three common ways to authenticate a DH key exchange:<br>
<br></span>
1. If you and your partner *already have* a shared secret: you mix it<span class=""><br>
into into the key exchange somehow. This is the 'shared key' mechanism, and<br>
is the basis of (eg) PAKE. The crux of this mechanism is that the key<br>
exchange will fail unless both parties knew the shared secret.<br></span>
2. If you and your partner have long-term public keys, and *each already<br>
knows the public key of the other*: you use the corresponding private<span class=""><br>
keys to augment the key exchange. This one basically breaks down into two<br>
categories, depending on what kinds of long-term public keys you have.<br></span>
1. If you have signing keys, then you digitally sign the DH<span class=""><br>
transaction to authenticate it. You also need to hash the<br>
long-term public<br>
keys into the shared secret, or you introduce an identity misbinding<br>
vulnerability.<br></span>
2. If you have DH-type keys, then you basically do the DH crypto<span class=""><br>
twice, using both sets of keys.<br></span>
3. If you and your partner have long-term public keys, and you *don't<br>
know* each other's public keys, then you need someone to vouch for you.<span class=""><br>
In most people's heads, that means "PKI", but SSH/OTR-style<br>
check-the-fingerprint is potentially viable.<br>
<br>
There's also a whole raft of academic literature on more subtle ways you<br>
can authenticate your DH transaction using the properties of the<br>
environment, like the availability of secondary, very low-bandwidth<br>
channels (think Bluetooth pairing); I can direct you to one or two of those<br>
papers if you're interested. But those three are the 'classically strong'<br>
ones, and the ones that are the easiest to understand.<br>
<br>
Justin<br>
</span></blockquote>
<br>
Hello, thank you,<br>
I'm interested in a practical and ultimate MITM-prevention method<br>
to be used in computer communication using TCP.<br>
<br>
All the papers and examples I read on MITM-prevention do expect<br>
that one already has safely (pre-) exchanged the public keys<br>
of a signing algo like RSA for signing+enc+dec.<br>
<br>
And just that exactly is now the question I'm seeking an answer for,<br>
ie. does there exist an algorithm for sending/exchanging the public keys<br>
safely (that is guaranteed authentic) over the public internet,<br>
w/o human interaction by the two parties?<br>
<br>
Said differently:<br>
Public keys are by definition of course public, but there is the "little"<br>
problem of authentically transmitting it to the other party, for example<br>
the public key of an ephemeral RSA method to be used as nonce in session<br>
creation with PFS: here Alice needs to be sure that Bob receives her<br>
new pubkey, and not that of someone else in the middle (MITM).<br>
Any algorithm known for solving this elementary problem of securely<br>
exchanging the public keys?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
U.Mutlu</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></div><br></div>