My guess is that the term "MITM" is being overfit to include the basic problem of verifying that A's identity really belongs to A rather than M.

But you can verify the other end. Not wanting so so that ist Not a Problem of the App or protocol.

It's hard to prove the whole chain of possibly-tampered hardware and proprietary software hasn't gotten any malicious update to steal private keys at any point

If your threat actor is omnipotent, you’re going to have a very hard time designing a coherent threat model against them. Neither Signal nor PGP nor hiding under the bedsheets will protect you from an adversary capable of directly recording your screen.

(But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)

"communicating with the same identity you initiated with."

Is that not tofu, which is easy in many crypto systems?

Signal acts as a central key server and can present different identity keys to users, so signal itself can middle communications unless there is out-of-band verification of identity keys. This is described here https://www.ndss-symposium.org/wp-content/uploads/2017/09/09... (II. Background) and many other places.

This is conflating TOFU and (active) MITM. If you don’t check your peer’s security number in Signal, you are essentially trusting the key directory to be honest about its identity mapping. This is identical to trusting a PGP keyserver, except that Signal has empirically developed a more secure and private key directory than the PGP keyserver ecosystem.

In other words: you always need to perform OOB identity verification, regardless of your messaging system of choice. There is no way around this; it’s a fundamentally social and UX problem rather than a cryptographic one. But this doesn’t change the fact that, once you have a trusted identity, Signal’s MITM protections are significantly stronger than PGP’s (including forward secrecy, as noted before).

> In other words: you always need to perform OOB identity verification

Web-of-trust alleviates that, to some extent.

The WoT has been defunct in PGP for over 4 years at this point[1]. It was also never a particularly good solution to this problem, because it (1) was itself largely unauthenticated and blindly trusted by relying parties, much like a normal key directory, and (2) failed to encode what key holding parties were trusted for (the classic example being that I absolutely trust party A to do C for me, but this does not imply that I want to encourage networked party B to trust A for D). And of course the keyserver birthday attacks and DoS, as cherries on top :-)

(I think WoTs can solve these problems. But PGP's implementation has been so far the most ambitious tried by a semi-large audience, and it didn't hold up. We need a better starting point.)

[1]: https://inversegravity.net/2019/web-of-trust-dead/

I agree completely.

They are trivially MITM-able. Not long ago there was news posted here that telecom employees are selling SIM swaps. There's your MITM vulnerability. People can pay to impersonate others by taking over their phone numbers and consequently their messenger accounts.

This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.