# Secure and Efficient Deduplication for Cloud Storage with Dynamic Ownership Management
## 3 Preliminaries and Background
### Secure Data Sharing in Cloud (SeDaSC) Protocol  
[PERSON] et al. introduced the SeDaSC protocol, which aims to reduce client computational overhead when sharing data among authenticated clients in a cloud [5]. In the SeDaSC protocol, the client uploads plaintext data, and a cryptographic server (CS) is responsible for several key operations, while the client does not engage in encryption operations directly. However, it is crucial to fully trust the CS since it has access to plaintext data. The detailed process is outlined below:  
1. **Upload. ** The client uploads plaintext data. The CS generates an encryption key for the uploaded data. Using the encryption key, the CS encrypts the plaintext and stores the data's information and client's information in an access control list (\(ACL\)). The CS then splits the generated encryption key into two parts, securely storing one part and transmitting the other part to the client. To further enhance security, the CS overwrites and deletes the initial encryption key. The encrypted data are finally stored in the cloud. The purpose of storing client information in the \(ACL\) is to verify the legitimate ownership of data when a download request is made. Splitting the encryption key into two parts prevents any single entity from decrypting the data independently. If it is an initial upload, a key generation process is performed. * \(\text{KeyGen}(1^{\lambda},h)\). Given security parameters \(1^{\lambda}\) and a 256-bit cryptographic hash function \(h\) as input, a symmetric key \(K=h(\{0,1\}^{256})\) is produced. Encrypt\((m,SKA,K)\). Taking plaintext \(m\), symmetric key algorithms \(SKA\), and symmetric key \(K\) as input, it produces encrypted data \(C=SKA(K,m)\). * KeyGen for Client \(i\)\((K)\). Given symmetric key \(K\) as input, it generates the key of CS, \(K_{i}=\{0,1\}^{256}\), and the key of client \(i\), \(K_{i}^{{}^{\prime}}=K\oplus K_{i}\). 2. **Download. ** The client requests decryption of data stored in the cloud, sending the encrypted data to the CS. The CS uses the information stored in the \(ACL\), along with the symmetric key provided by the client, to recover the encryption key. Since each client has a different \((K_{i},K_{i}^{{}^{\prime}})\) pair, the impersonation of other clients is prevented. If the client sends the correct symmetric key to the CS, it can receive the decrypted data. Alternatively, the client can request the CS to perform both download and decryption. In this case, the client sends the group ID and symmetric key \(K_{i}^{{}^{\prime}}\) to the CS, which retrieves and decrypts the data from the cloud before transmitting them to the client. * \(\text{Decrypt}(C,K_{i},K_{i}^{{}^{\prime}},ACL,SKA)\). Given encrypted data \(C\), CS's key \(K_{i}\), client \(i\)'s key \(K_{i}^{{}^{\prime}}\), access control list \(ACL\), and symmetric key algorithms \(SKA\) as input, it recovers the encryption key \(K=K_{i}\oplus K_{i}^{{}^{\prime}}\) and decrypts the data to produce plaintext \(m=SKA(C,K)\). [PERSON] et al. used CE, which uses the hash value of plaintext data as an encryption key, to prevent the CS from accessing plaintext [7]. In CE, the CS generates a file key based on the hash value received from the client and the number of clients to share data and divides the file key into half with the client. The client encrypts the data and sends the received half key to the cloud. The proposed protocol prevents the CS from accessing plaintext through CE. In addition, it proposed a communication method that can be used universally compared to existing protocols that consider only authenticated clients. However, the amount of computation increases as the client performs encryption directly. When the CS generates a file key, it does not check the relationship between plaintext data and hash values. Therefore, the cloud cannot confirm the relationship between plaintext data and encrypted data.