[messaging] Can a pre-shared public key prevent MITM-attacks?

[Justin King-Lacroix]

There are basically three common ways to authenticate a DH key exchange:

   1. If you and your partner *already have* 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.
   2. If you and your partner have long-term public keys, and *each already
   knows the public key of the other*: 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.
      1. 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.
      2. If you have DH-type keys, then you basically do the DH crypto
      twice, using both sets of keys.
   3. If you and your partner have long-term public keys, and you *don't
   know* 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.

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.

Justin




On 5 December 2015 at 00:31, U.Mutlu <for-gmane at mutluit.com> wrote:

> Natanael wrote on 12/05/2015 12:50 AM:
>
>> Den 4 dec 2015 23:49 skrev "U.Mutlu" <for-gmane at mutluit.com>:
>>
>>>
>>> Martin Dehnel-Wild wrote on 12/04/2015 09:58 PM:
>>>
>>>>
>>>> Yes. Having a pre-shared public key definitely allows you to prevent
>>>> MITM
>>>> attacks. (Where by 'attack' I assume  you mean 'the adversary learns the
>>>> agreed key')
>>>>
>>>
>>>
>>> Yes, indeed that's what I'm meaning by attacks.
>>> But I have a hard time to see how the use of a public key can help here,
>>> because the public key is by definition known to everybody, so also to
>>> the MITM, but then he can easily replace the encrypted message by his
>>> own message encrypted with the same public key --> bingo!
>>>
>>> Or, where is my lack of understanding here?
>>>
>>> Thanks for the info and links below, I'm going to study them.
>>>
>>
>> This is where you tell them to reply encrypted to your public key, inside
>> the encrypted message, and sign it. So they got a message from somebody
>> else? If they know you already, they'll see the signature failed. If they
>> don't, you'll be the one who notices the total lack of response, and
>> you'll
>> try again until you get one (which is signed).
>>
>
> This introduces signing, but in the wikipedia article I had quoted
> in the OP signing is not mentioned:
> https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange#Public_key
>
> If I might summarize:
>  Using DH protocol and adding to it the use of say RSA certificates
>  (for signing, enc, dec) will make the DH session MITM-secure,
>  for example for subsequently sending a new password (for something else)
>  over to the other side.
>
> Is that conclusion right?
>
> That would be what I need, ie. a safe way to send the other side a
> new/initial password (for a different purpose), but without any human
> interaction as the participants are devices or apps but which already
> have their own certificates.
>
>
>
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151206/00ffeeee/attachment.html>