## 4 Proposed Protocol
### [PERSON]'s Session Setup  
For [PERSON]'s session setup, [PERSON] needs to provide [PERSON] with his Identity Public Key \(IDPK_{[PERSON]}\), a signature \(\sigma\) with his Sign Public Key \(SPK_{Bob}\) for verification, and a one-time pre-key \(OTPK_{Bob}\). In the proposed protocol, [PERSON] should securely upload these keys to the server. [PERSON] retrieves these keys from the server, verifies the signature using [PERSON]'s public key \(SPK_{[PERSON]}\), and performs the other steps outlined in Algorithm 1. ```
Input:\((\lambda,\sigma,IDPK_{[PERSON]},SPK_{[PERSON]},OTPK_{[PERSON]})\)\(\triangleright\) Inputs Algorithm 1 retrieved from the server Output:\((IDPK_{[PERSON]},EPK_{[PERSON]}^{0},EPK_{Alice}^{1},C_{1})\)
1:\((IDSK_{[PERSON]},IDK_{Alice})\gets KeyGen(1^{\lambda})\)\(\triangleright\) Alice Identity Public and Private Keys
2:\((EPK_{Alice}^{0},ESK_{Alice}^{0})\gets KeyGen(1^{\lambda})\)\(\triangleright\) Alice Ephemeral Public and Private Keys
3:\((EPK_{[PERSON]}^{1},ESK_{[PERSON]}^{1})\gets KeyGen(1^{\lambda})\)\(\triangleright\) Alice Ephemeral Public and Private Keys
4:\(DH_{1}\gets [PERSON](IDSK_{[PERSON]},SPK_{[PERSON]})\)\(\triangleright\) Secret 1 exchange through DH1
5:\(DH_{2}\gets DH(ESK_{[PERSON]}^{0},IDPK_{[PERSON]}))\)\(\triangleright\) Secret 2 exchange through DH2
6:\([PERSON]_{3}\gets DH(ESK_{[PERSON]}^{0},SPK_{[PERSON]})\)\(\triangleright\) Secret 3 exchange through DH3
7:\([PERSON]_{4}\gets DH(ESK_{[PERSON]}^{0},OTPK_{[PERSON]})\)\(\triangleright\) Secret 4 exchange through DH4
8:\(SK\gets KDF([PERSON]_{1}||DH_{2}||DH_{3}||DH_{4})\)\(\triangleright\) Secret Key generated through DH secrets
9:\((RK_{0},CK_{0})\gets HKDF(SK,WT)\)\(\triangleright\) Root Key and Chain Key
10:\(SK_{1}\gets DH(ESK_{Alice}^{1},SPK_{Bob})\)\(\triangleright\) Updated Secret Key through DH
11:\((RK_{1},CK_{1})\gets HKDF(RK_{0},SK_{1},WT)\)\(\triangleright\) Updated Root Key and Chain Key
12:\((K_{1},CK_{2})\gets KDF(CK_{1}||WT)\)\(\triangleright\) Secret Key for encrypting random key
13:\(T_{k}\gets RandKey(1^{\lambda})\)\(\triangleright\) Randomly generated key
14:\(C_{0}\gets ENC(Name,T_{k})\)\(\triangleright\) Ciphertext corresponding to the Plaintext \"Name\"
15:\(C_{1}\gets ENC(T_{k},K_{1})\)\(\triangleright\) Ciphertext corresponding to the Plaintext \"\(T_{k}\)\"
16:Delete \(T_{k}\)\(\triangleright\) Finally, delete the key \(T_{k}\)
```  
**Algorithm 1** [PERSON]'s Session Setup  
Algorithm 1 halts and returns nothing if verification of the signature fails. In the other case, it generates private and public identities and ephemeral keys for [PERSON]. The generated keys are then used in the extended Diffie-Hellman algorithm to establish the initial shared secret key between [PERSON] and [PERSON]. The aim of the extended Diffie-Hellman algorithm is to ensure authentication and forward secrecy. Additionally, for the generation of root key \(RK_{0}\) and chain key \(CK_{0}\), the double ratchet algorithm (DRA) [34] is employed, as described in [35]. The use of DRA in the proposed protocol guarantees forward secrecy, confidentiality, and non-repudiation. The DRA operation occurs after establishing the shared secret SK and takes it as input along with any constant value; we use the text WT = \"whisper-ratchet\" for demonstration to derive the keys \(RK_{0}\) and \(CK_{0}\). The details are illustrated in Figure 3.  
Additionally, in [PERSON]'s session setup, she generates new ephemeral key pairs. After the symmetric ratchet, she uses the new ephemeral keys and calculates a shared secret with [PERSON] using Diffie-Hellman (DH). Then she utilizes the shared secret as input for the symmetric ratchet. This process calculates the updated root key and chain key. The significance of this step lies in facilitating a swift recovery in case an attacker gains access to the encryption key. This step ensures that the attacker cannot predict future keys by using the knowledge of previous keys.