3 ms·

The issue here is more complicated. A self-hosted Zulip server needs to send a push notification that reaches the Zulip mobile app on someone's device. For sec

The issue here is more complicated. A self-hosted Zulip server needs to send a push notification that reaches the Zulip mobile app on someone's device. 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.

stavros 4y ago
Hmm, I'm not sure I understand. Your first two paragraphs agree with what I said, but, in the third one, why does the client need to know the server's secret key? The communication happens the other way (server to client), no? 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.
- tabbott 4y ago
  Correct, it's server-to-client. The model I described above is a symmetric key cryptography design. A model where the client generates a public/private key pair and gives the server its public key when registering for mobile push notifications is also an option. 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 :).

stavros 4y ago

Hmm, I'm not sure I understand. Your first two paragraphs agree with what I said, but, in the third one, why does the client need to know the server's secret key? The communication happens the other way (server to client), no? 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.

tabbott 4y ago
Correct, it's server-to-client. The model I described above is a symmetric key cryptography design. A model where the client generates a public/private key pair and gives the server its public key when registering for mobile push notifications is also an option. 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 :).