they arent miss-use resistant when it comes to mitm attacks

Neither Signal nor WhatsApp is MITM-able. Could you explain why you think they are?

(Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)

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.

there is a response here: https://articles.59.ca/doku.php?id=pgpfan:tpp

I’ve read this response before, and I don’t think it’s great: it makes claims about time-testedness and simplicity that on first glance apply to PGP, but in reality are either outright wrong (the results against MDC instead of true AEAD are in, and it’s a fail) or misleading in their conclusions (a “simple” packet structure that encourages EXPTIME parsing is not actually simple).

The assumption underlying much of the post is that PGP is only used in offline, stateless applications. This would make the arguments stronger, except that it isn’t true[1].

[1]: https://delta.chat/en/

>...the results against MDC instead of true AEAD are in, and it’s a fail...

It's really OCFB-MDC. It's only a authenticated mode when the two things are used together (like GCM). It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. I don't know what "true AEAD" means in this context. As a user I only care that the OCFB-MDC mode is actually secure. I am not interested in any philosophical aspects.

The stuff about offline stateless applications only adds to the argument. A version of OCFB-MDC could be used, for say, TLS and would be expected to be secure.

> It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for.

It isn't sensible to assert this, because people use OpenPGP in all kinds of crazy ways. One of the recurring headaches in applied cryptographic engineering is discovering that people do, in fact, attempt to use PGP for instant messaging (per above), as a TLS certificate delivery mechanism, etc. These are contexts where the use of an AEAD is frequently appropriate.

> As a user I only care that the OCFB-MDC mode is actually secure.

In practice, it has not been[1]. PGP's decision to use MDC instead of a real MAC is a classic example of home-rolled primitives being conceptually algebraically sound but broken in user settings. The solution here is simple: OpenPGP is not special, and should use a MAC or AEAD mode like everyone else does. It also shouldn't release the plaintext until the authentication tag is actually validated, which was another profound historic breakage with MDC.

[1]: https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw...

You posted a link to the email where Trevor Perrin acknowledged that the corrected specification was secure.

>PGP's decision to use MDC instead of a real MAC...

The MDC can be interpreted as a MAC. The hash is first seeded with a MAC key (the "random block"). So a boring old hash MAC. SHA-1 is vulnerable to length extension attacks but that is not an issue here as the attacker never gets access to the state of the hash (everything is encrypted). I guess this could be considered an advantage of MAC then encrypt. The only property the hash requires is that the MAC key will be propagated to the check value in such a way that it is indistinguishable from random. So SHA-1 is wild overkill here.