## 3 Analyzing Zoom's E2 EE Capabilities
### Analysis of Zoom's E2 EE Phase 1  
A Zoom meeting typically comprises a host, who initiates and manages the meeting, and participants who join the meeting. First, assume that [PERSON] (host) and [PERSON] (participant) understand the Client Key Management system of Zoom. Additionally, it is assumed that both entities possess a long-time signing key (\(ISK_{I}\)) and a long-time verification key (\(IVK_{I}\)). Based on the above conditions, the process of Zoom's Client Key Management system is illustrated in Figure 1[2]. We describe the progress of Figure 1 in terms of Algorithm 1:  
* When each client logs in to Zoom, the Zoom server generates a signature \((Sig_{Server}^{I}(IVK_{I}))\) for each client's verification key \((IVK_{I})\) (Algorithm 1, Line 1). * Each client generates a temporary encryption key pair, public key, and secret key \((pk_{I},\ sk_{I})\). Each client generates a signature \((Sig_{I})\) with the Edwards-curve Digital Signature Algorithm (EddSA), and after that uploads the public key \((pk_{I})\), signature \((Sig_{I})\), and signature for the verification key \((Sig_{Server}^{I}(IVK_{I}))\) to the bulletin board (Algorithm 1, Lines 2-6). * To generate a symmetric key \((K_{AB})\) for the encryption/decryption of the meeting key \((MK)\), the host ([PERSON]) performs the Diffie-Hellman method between the public key \((pk_{B})\) of the verified participant ([PERSON]) and its own private key \((sk_{A})\). Subsequently, these keys are used as inputs to the HMAC-based Key Derivation Function (HKDF). The participant ([PERSON]) uses his own private key \((sk_{B})\) and the host's public key \((pk_{A})\) to generate a symmetric key \((K_{AB})\) in a similar manner (Algorithm 1, Lines 8, 12). * The host generates a 32-byte shared meeting key \((MK)\) that is used to encrypt and decrypt the meeting data using AES-GCM. The meeting key is generated using a cryptographically secure random number generator (RNG). The host then encrypts it with the symmetric key \((K_{AB})\), uploads it to the bulletin board, decrypts the ciphertext with the symmetric key \((K_{AB})\), and obtains the meeting key \((MK)\) (Algorithm 1, Lines 9, 10, 13). Otherwise, if a new participant, [PERSON], joins the key management system as mentioned above, which includes [PERSON] and [PERSON], the following steps are additionally performed. It is assumed that [PERSON] possesses a long-time signing key \((ISK_{C})\) and a long-time verification key \((IVK_{C})\). * The Zoom server generates a signature \((Sig_{Server}^{C}(IVK_{C}))\) for [PERSON]'s verification key \((IVK_{C})\). After that, [PERSON] generates a temporary encryption key pair \((pk_{C},\ sk_{C})\) and a signature \((Sig_{C})\) with EdDSA. Then, [PERSON] uploads the public key \((pk_{C})\), signature \((Sig_{C})\), and signature for the verification key \((Sig_{Server}^{C}(IVK_{C}))\) to the bulletin board. * To generate a symmetric key \((K_{AC})\), [PERSON] performs the Diffie-Hellman method between the public key \((pk_{C})\) and its own private key \((sk_{A})\). [PERSON] uses his own  
Figure 1: Zoom’s end-to-end encryption key management process. private key (\(sk_{C}\)) and the [PERSON]'s public key (\(pk_{A}\)) to generate the symmetric key (\(K_{AC}\)), similarly. * [PERSON] generates a new 32-byte shared meeting key (\(MK^{*}\)). Then, [PERSON] encrypts it with each symmetric key (\(K_{AB}\), \(K_{AC}\)) and uploads it to the bulletin board. After that, [PERSON] and [PERSON] can decrypt the ciphertext with each symmetric key (\(K_{AB}\), \(K_{AC}\)), and obtain the meeting key (\(MK^{*}\)).