You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys.
You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys.
Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.
Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.
This is how it used to work; notifications can be encrypted now and Signal uses an extension to decrypt them.
A Signal developer 12 days ago said Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.[1]
[1] https://news.ycombinator.com/item?id=47723445
Ah, yes, they would be right. I feel like I had read that someone had migrated at some point, maybe it was WhatsApp or something.
Sending public keys through the notification system is an unnecessary complication.
Which clients?
Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works?
... and hold participants' private keys truly private, which you cannot verify without a rooted phone.
You don’t need a rooted phone. An open source OS with reproducible builds is enough. That way you can validate what the code does without giving up verified boot, or opening up another attack vector, etc.