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

[Justin King-Lacroix]

SSL (used by HTTPS) depends on PKI to solve this problem. PKI is about
having a trusted third party to vouch for the identity of at least one of
the participants involved. That trusted third party is the CA - VeriSign,
Thawte, Comodo, etc.

HTTPS is therefore secure against MITM as long as all of the (hundreds of)
CAs operate correctly -- that is, they aren't subverted by a malicious
party, and they don't lose their signing keys.



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

> 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
>>>
>>
>
> _______________________________________________
> 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/20151208/1eb83fce/attachment.html>