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

[U.Mutlu]

Justin King-Lacroix wrote on 12/07/2015 02:52 PM:
> No. Even in principle, this is essentially impossible -- two parties with
> no relationship basically can't communicate securely.
> 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.
> But in general, the problem you're describing has no solution.
>
> (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.)
>
> Justin

But this means for https in practice that:
NONE of the security protocols used in https is secure against MITM.
So, https is insecure whatever ciphers one uses, be it DH_RSA, DH_DSS,
DHE_RSA, DHE_DSS or any of the others possible in the security protocol settings.
That means, NSA & Co. can MITM all https communications.
Unless one exchanges with the site in advance (ie. manually) the certified
public keys of each other, but which in 99.9% of the cases surely not
happens because of the extra and manual work (and costs) needed.


> On 6 December 2015 at 23:43, U.Mutlu <for-gmane at mutluit.com> wrote:
>
>> Justin King-Lacroix wrote on 12/06/2015 03:23 PM:
>>
>>> 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
>>>
>>
>> Hello, thank you,
>> I'm interested in a practical and ultimate MITM-prevention method
>> to be used in computer communication using TCP.
>>
>> All the papers and examples I read on MITM-prevention do expect
>> that one already has safely (pre-) exchanged the public keys
>> of a signing algo like RSA for signing+enc+dec.
>>
>> And just that exactly is now the question I'm seeking an answer for,
>> ie. does there exist an algorithm for sending/exchanging the public keys
>> safely (that is guaranteed authentic) over the public internet,
>> w/o human interaction by the two parties?
>>
>> Said differently:
>> Public keys are by definition of course public, but there is the "little"
>> problem of authentically transmitting it to the other party, for example
>> the public key of an ephemeral RSA method to be used as nonce in session
>> creation with PFS: here Alice needs to be sure that Bob receives her
>> new pubkey, and not that of someone else in the middle (MITM).
>> Any algorithm known for solving this elementary problem of securely
>> exchanging the public keys?
>>
>> --
>> U.Mutlu