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 tampered with*. (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. J On 7 Dec 2015 14:34, "Sam Lanning" <[email protected]> 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. > > Cheers, > Sam. > > On Mon, Dec 7, 2015 at 1:52 PM, Justin King-Lacroix < > [email protected]> 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.) >> >> Justin >> >> >> >> >> >> 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 >>> >> >> >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> >> >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
