<div dir="ltr"><div>You are forgetting one other approach though TOFO (Trust on First Use), which is getting significantly more traction recently, for example in Signal, and OpenSSH actually uses this approach. And as long as on the first communication, you are only being passively attacked, and not actively (full MITM), after the keys have been exchanged and stored, a MITM cannot occur after that point. Further to this, it allows you to verify out-of-band later on that you have been communicating with the correct keys, which can then give you authentication for all previous messages.<br><br></div><div>More specifically, a sustained attack on TOFU requires:<br></div><div>1) An active MITM attack on first communicaiton.<br></div><div>2) An active MITM for every communication thereafter (which is v. difficult in today's mobile world of networks anyway).<br></div><div>3) The two parties to never verify their keys out-of-band.<br><br></div><div>Failing to do (1) will mean that the parties successfully set up communications, failing to do (2) or (3) will mean that the parties will be able to detect they have been being attacked up until now.<br><br></div><div>Cheers,<br></div><div>Sam.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 1:52 PM, Justin King-Lacroix <span dir="ltr"><<a href="mailto:justin.king-lacroix@cs.ox.ac.uk" target="_blank">justin.king-lacroix@cs.ox.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Justin</div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><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>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> 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><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><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><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><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><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><font color="#888888"><br> <br> -- <br> U.Mutlu</font></span><div><div><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> </div></div><br>_______________________________________________<br> Messaging mailing list<br> <a href="mailto:Messaging@moderncrypto.org">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> <br></blockquote></div><br></div>