The clients already use some secret for authenticating to the server, no? Can you not use the same secret for encryption? Or are you using tokens that need refreshing?
For security model reasons, those push notifications need to be sent to Google/Apple via a server operating by Zulip itself. So your local Zulip server needs to share a secret with the Zulip mobile app on your device, and then it can encrypt the push notification's content so that only the destination mobile app can read it (and the intermediaries cannot).
It's a basic cryptography problem at a high level, but there's subtle details around what metadata can be safely encrypted (the client does need to know which Zulip server's secret key to use!), backwards-compatibility, library choice, etc., that make it not trivial, which is why we haven't managed to implement this yet.
Plus, the server already has a shared secret with the client (presumably), the API key. Backwards compatibility might be an issue, if you aren't storing the client version on the server, but that seems like a simple fix.
Can you explain a bit more what I'm missing here? I'm a bit confused.
I agree it's possible in theory to reuse the API key for end-to-end encryption, but I don't think that's the right design. This is in part because the encryption algorithm may, now or in the future, have different requirements for format, key size, etc. But more importantly, a cryptographic weakness in the encryption algorithm should not allow an attacker to stealing API keys.
It might be best to move this conversation to #backend in chat.zulip.org :).