## 4 Proposed Protocol
### Receiving a Notification  
When [PERSON] receives a notification from [PERSON] through a device that is locked with a password or biometric measure, [PERSON]'s device executes the steps outlined in Algorithm 4 to retrieve the key used to encrypt [PERSON]'s name. ```
Input:\((\lambda,EPK_{[PERSON]}^{2},RK_{1},C_{0},C_{3})\) Output:\((C_{5},EPK_{[PERSON]}^{3})\)
1:\(DH_{1}\gets DH(ESK_{[PERSON]}^{1}EPK_{[PERSON]}^{2})\)
2:\((RK_{2},CK_{3})\gets HKDF(RK_{1},DH_{1})\)
3:\((K_{2},CK_{4})\gets HKDF(CK_{3},\textit{`constant value'})\)
4:\(Bundle\gets DEC(K_{2},C_{3})\)
5:\(Bob=DEC(C_{0},T_{key})\)
6:Display notification ([PERSON])
7:\(T_{key}=NT_{key}\)
8:\(\textbf{C_{4}}=ENC(T_{key},\textit{\"Bob\"})\)
9:\((EPK_{[PERSON]}^{3},ESK_{[PERSON]}^{3})\gets KeyGen(1^{\lambda})\)
```  
**Algorithm 4** Receiving a Notification  
### Receiving a Notification  
When [PERSON] receives a notification from [PERSON] through a device that is locked with a password or biometric measure, [PERSON]'s device executes the steps outlined in Algorithm 4 to retrieve the key used to encrypt [PERSON]'s name. ```
Input:\((\lambda,EPK_{[PERSON]}^{2},RK_{1},C_{0},C_{3})\) Output:\((C_{5},EPK_{[PERSON]}^{3})\)
1:\(DH_{1}\gets DH(ESK_{[PERSON]}^{1}EPK_{[PERSON]}^{2})\)
2:\((RK_{2},CK_{3})\gets HKDF(RK_{1},DH_{1})\)
3:\((K_{2},CK_{4})\gets HKDF(CK_{3},\textit{`constant value'})\)
4:\(Bundle\gets DEC(K_{2},C_{3})\)
5:\([PERSON]=DEC(C_{0},T_{key})\)
6:Display notification (Bob)
7:\(T_{key}=NT_{key}\)
8:\(\textbf{C_{4}}=ENC(T_{key},\textit{\"Bob\"})\)
9:\((EPK_{Alicer}^{3},ESK_{Alice}^{3})\gets KeyGen(1^{\lambda})\)
```  
**Algorithm 5** Sending a Notification  
```
Input:\((\lambda,EPK_{Bob}^{2},RK_{1},C_{0},C_{3})\) Output:\((C_{5},EPK_{Alice}^{3})\)
1:\(DH_{1}\gets DH(ESK_{Alicer}^{1}EPK_{Bob}^{2})\)
2:\((RK_{2},CK_{3})\gets HKDF(RK_{1},DH_{1})\)
3:\((K_{2},CK_{4})\gets HKDF(CK_{3},\textit{`constant value'})\)
4:\(Bundle\gets DEC(K_{2},C_{3})\)
5:\(Bob=DEC(C_{0},T_{key})\)
6:Display notification ([PERSON])
7:\(T_{key}=NT_{key}\)
8:
```
10:\(DH=DH(EPK_{[PERSON]}^{3},EPK_{[PERSON]}^{2})\)
11:\((RK_{3},CK_{5})\gets HKDF(RK_{2},DH_{1})\)
12:\((K_{3},CK_{6})\gets HKDF(CK_{5}\),constant value)
13:\(C_{5}=ENC(K_{3},T_{key})\)
```
**Algorithm 4**_Cont._

The ciphertext \(C_{0}\) corresponding to [PERSON]'s name is stored in [PERSON]'s database. The device retrieves the key \(T_{key}\) for the decryption of [PERSON]'s name and displays the name in the notification heading. The steps for retrieving the old key and generating a new one are given in Algorithm 4. After displaying the notification, the algorithm updates the key \(T_{key}\) to the new key \(NT_{key}\) and encrypts the name of [PERSON] with the new key. The algorithm replaces the old ciphertext \(C_{0}\) with the new ciphertext \(C_{4}\) in the database. Subsequently, it generates new ephemeral keys as input for the asymmetric ratchet and creates a new key for encrypting the key \(T_{key}\). It then sends the ciphertext corresponding to the plaintext to [PERSON] along with the public ephemeral key \(EPK_{Alice}^{3}\). Then it deletes the secret key \(T_{key}\) from [PERSON]'s device. In the receiving a notification algorithm, the implementation of the asymmetric ratchet, forward secrecy, and key removal from the data ensures confidentiality against offline attacks. Therefore, our support for the self-interactive decryption emphasizes enhancing the user experience by prioritizing intuitive interaction. This protocol is designed to notify users, ensuring that security processes are transparent yet unobtrusive. By allowing users to interact with decryption notifications, they can feel more in control and informed without being overwhelmed or frustrated by constant alerts. The protocol's user-centric design ensures that the decryption process complements the overall experience, maintaining the balance between security and usability.