<div dir="ltr">There are basically three common ways to authenticate a DH key exchange:<div><ol><li>If you and your partner <i>already have</i> a shared secret: you mix it into into the key exchange somehow. This is the 'shared key' mechanism, and is the basis of (eg) PAKE. The crux of this mechanism is that the key exchange will fail unless both parties knew the shared secret.<br></li><li>If you and your partner have long-term public keys, and <i>each already knows the public key of the other</i>: you use the corresponding private keys to augment the key exchange. This one basically breaks down into two categories, depending on what kinds of long-term public keys you have.</li><ol><li>If you have signing keys, then you digitally sign the DH transaction to authenticate it. You also need to hash the long-term public keys into the shared secret, or you introduce an identity misbinding vulnerability.</li><li>If you have DH-type keys, then you basically do the DH crypto twice, using both sets of keys.</li></ol><li>If you and your partner have long-term public keys, and you <i>don't know</i> each other's public keys, then you need someone to vouch for you. In most people's heads, that means "PKI", but SSH/OTR-style check-the-fingerprint is potentially viable.</li></ol><div>There's also a whole raft of academic literature on more subtle ways you can authenticate your DH transaction using the properties of the environment, like the availability of secondary, very low-bandwidth channels (think Bluetooth pairing); I can direct you to one or two of those papers if you're interested. But those three are the 'classically strong' ones, and the ones that are the easiest to understand.</div><div><br></div><div>Justin</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2015 at 00:31, 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"><div><div>Natanael wrote on 12/05/2015 12:50 AM:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Den 4 dec 2015 23:49 skrev "U.Mutlu" <<a href="mailto:for-gmane@mutluit.com" target="_blank">for-gmane@mutluit.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Martin Dehnel-Wild wrote on 12/04/2015 09:58 PM:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes. Having a pre-shared public key definitely allows you to prevent MITM<br>
attacks. (Where by 'attack' I assume  you mean 'the adversary learns the<br>
agreed key')<br>
</blockquote>
<br>
<br>
Yes, indeed that's what I'm meaning by attacks.<br>
But I have a hard time to see how the use of a public key can help here,<br>
because the public key is by definition known to everybody, so also to<br>
the MITM, but then he can easily replace the encrypted message by his<br>
own message encrypted with the same public key --> bingo!<br>
<br>
Or, where is my lack of understanding here?<br>
<br>
Thanks for the info and links below, I'm going to study them.<br>
</blockquote>
<br>
This is where you tell them to reply encrypted to your public key, inside<br>
the encrypted message, and sign it. So they got a message from somebody<br>
else? If they know you already, they'll see the signature failed. If they<br>
don't, you'll be the one who notices the total lack of response, and you'll<br>
try again until you get one (which is signed).<br>
</blockquote>
<br></div></div>
This introduces signing, but in the wikipedia article I had quoted<br>
in the OP signing is not mentioned:<br>
<a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Public_key" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange#Public_key</a><br>
<br>
If I might summarize:<br>
 Using DH protocol and adding to it the use of say RSA certificates<br>
 (for signing, enc, dec) will make the DH session MITM-secure,<br>
 for example for subsequently sending a new password (for something else)<br>
 over to the other side.<br>
<br>
Is that conclusion right?<br>
<br>
That would be what I need, ie. a safe way to send the other side a<br>
new/initial password (for a different purpose), but without any human<br>
interaction as the participants are devices or apps but which already<br>
have their own certificates.<div><div><br>
<br>
<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>