[messaging] Can a pre-shared public key prevent MITM-attacks?
justin.king-lacroix at cs.ox.ac.uk
Mon Dec 7 07:00:38 PST 2015
True, I missed out TOFU. I would argue, though, that TOFU gives you a
weaker guarante: authentication *as long as the first message was not
(Also note that SSH and OTR end up using this approach in practise, but
they weren't designed to -- you're supposed to check the key fingerprint
before saying "yes".)
TOFU systems also require careful design to achieve the properties you
describe vis-a-vis MITM. In particular, while all encrypted messaging
systems require a way to roll over the key, they must not support a "set
session key to X" message, or similar, or the adversary can use it to
switch from active mode to passive mode. This is not as trivial as it
sounds -- I think SSL reauthentication lets you do exactly this.
Otherwise, I agree with what you've said.
On 7 Dec 2015 14:34, "Sam Lanning" <sam at samlanning.com> wrote:
> You are forgetting one other approach though TOFO (Trust on First Use),
> which is getting significantly more traction recently, for example in
> Signal, and OpenSSH actually uses this approach. And as long as on the
> first communication, you are only being passively attacked, and not
> actively (full MITM), after the keys have been exchanged and stored, a MITM
> cannot occur after that point. Further to this, it allows you to verify
> out-of-band later on that you have been communicating with the correct
> keys, which can then give you authentication for all previous messages.
> More specifically, a sustained attack on TOFU requires:
> 1) An active MITM attack on first communicaiton.
> 2) An active MITM for every communication thereafter (which is v.
> difficult in today's mobile world of networks anyway).
> 3) The two parties to never verify their keys out-of-band.
> Failing to do (1) will mean that the parties successfully set up
> communications, failing to do (2) or (3) will mean that the parties will be
> able to detect they have been being attacked up until now.
> On Mon, Dec 7, 2015 at 1:52 PM, Justin King-Lacroix <
> justin.king-lacroix at cs.ox.ac.uk> wrote:
>> 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.)
>> 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
>>>> 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
>>>> exchange will fail unless both parties knew the shared secret.
>>>> 2. If you and your partner have long-term public keys, and *each
>>>> knows the public key of the other*: you use the corresponding
>>>> keys to augment the key exchange. This one basically breaks down
>>>> into two
>>>> categories, depending on what kinds of long-term public keys you
>>>> 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
>>>> 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
>>>> know* each other's public keys, then you need someone to vouch for
>>>> 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
>>>> papers if you're interested. But those three are the 'classically
>>>> ones, and the ones that are the easiest to understand.
>>> 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?
>>> Messaging mailing list
>>> Messaging at moderncrypto.org
>> Messaging mailing list
>> Messaging at moderncrypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging