ZAP 2: Use symmetric crypto for notifications

Discussion:
  https://chat.zulip.org/#narrow/channel/378-api-design/topic/E2EE.20-.20cryptography/near/2258007

Author: gnprice

zaps/0002-encrypt-push-notifications.md

@@ -118,10 +118,8 @@ class Account:
   # The client should be careful about case with this field, since
   # APNs at least is case-insensitive.
   last_acked_push_token: str
-  # Private part of the asymmetric key pair generated by the client.
-  push_private_key: PrivateKey
-  # Public key corresponding to push_private_key
-  push_public_key: PublicKey
+  # Key shared (or to be shared) with the server.
+  push_key: SymmetricKey
 ```
 
 The client is responsible for ensuring that these secrets are stored
@@ -162,8 +160,8 @@ class zerver.models.push_notifications.PushDevice:
     encrypted_push_registration: Ciphertext | None  
     # 64-bit random integer generated by client. Need not be globally unique.
     push_account_id: int
-    # Public part of the asymmetric key pair generated by the client.
-    push_public_key: PublicKey
+    # Key shared with the client.
+    push_key: SymmetricKey
     # Provided by client.
     token_kind: "apns" | "fcm"
     # The user on this server to whom this PushDevice belongs.
@@ -262,7 +260,7 @@ The steps are:
       prepare an FCM-style or an APNs-style payload.
 
    1. Encrypt the notification content to
-      `PushDevice.push_public_key`, as `encrypted_content`.
+      `PushDevice.push_key`, as `encrypted_content`.
 
    1. The result is a pair `(device_id, encrypted_content)`.
 
@@ -302,7 +300,7 @@ The steps are:
 
    1. Use `push_account_id` to look up the Account record.
 
-   1. Use `Account.push_private_key` to decrypt `encrypted_content`.
+   1. Use `Account.push_key` to decrypt `encrypted_content`.
 
    1. Process the resulting plaintext as a notification.
 
@@ -338,11 +336,11 @@ Some steps may happen repeatedly due to retries, as detailed below.
 
 2. On the client:
 
-   If `push_account_id`, `push_public_key`, and `push_private_key` are
+   If `push_account_id` and `push_key` are
    already set on the `Account` record, proceed to the next step.
 
    Otherwise, generate a random 64-bit integer `push_account_id` and
-   an asymmetric key pair `push_public_key` and `push_private_key`.
+   a symmetric key `push_key`.
    Store these on the `Account` record.
 
 3. On the client:
@@ -356,7 +354,7 @@ Some steps may happen repeatedly due to retries, as detailed below.
 
    3. Make an API request to the server with arguments `push_account_id`,
       `encrypted_push_registration`, `bouncer_public_key`,
-      `push_public_key`, and `token_kind`.
+      `push_key`, and `token_kind`.
 
       The request is authenticated with the user’s API key, in the
       same way as other requests the client makes to the server.