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 <[email protected]> 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
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
