> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.

This is completely nonsense, most clients do in fact check signatures. All relays do as well.

> Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.

Author of Damus here. this is an analysis of an old version. This has since been fixed. In the early days we connected to a fixed relay list of trusted relays. These relays verified signatures. This was just a pragmatic tradeoff thing until we had an optimized work queue for verifying notes (this lead to nostrdb, a custom embedded nostr database built on lmdb. it's a sqlite but for nostr https://github.com/damus-io/nostrdb)

> DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.

not really true since the whole note is covered by a secp256k1 signature.

> The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).

you can turn off these, you can turn off images as well. people should run a VPN of course if they are worried about these things.

How does a VPN protect against flipping a URL to exfiltrate the message contents to an attacker-controlled server?

I don't think you can say "this is complete nonsense" and "this has since been fixed" in the same comment. Also: don't use ECC signatures as MACs. Signatures are not MACs.